В документации Perl 5.x говорится, что при реализации flock (..) будет использоваться один из следующих собственных вызовов, начиная с 1 и работая до 3, если он недоступен:
- стадо (2)
- Fcntl (2)
- lockf (3)
Все в порядке. Тем не менее, вы, возможно, заметили их заявление об отказе от использования flock (2) поверх NFS. В документе предлагается использовать флаг -Ud_flock, чтобы Perl использовал flock (2). Страница руководства flock (2) (на Redhat) содержит аналогичный отказ от проблем с NFS.
У меня вопрос, почему!?!? Кажется, я не могу найти подробную статью или объяснение, почему flock (2) небезопасен по сравнению с NFS.
Я написал несколько тестовых скриптов на C и Perl, как на Redhat (где используется flock (2)), так и на Solaris (где используется fcntl (2)). Я запустил strace / truss, чтобы убедиться, что Perl действительно использует flock (2) и fcntl (2) соответственно. Я не мог воспроизвести любые проблемы, когда блокировка не была выполнена! Что дает??
источник
Я почти уверен, что вы смотрите на проблемы прошлого. Напомним, что руководство по Perl5 было выпущено в 1994 году, и это было просто редактирование руководства по Perl4 с 1991 года. В те дни, вероятно, можно было сказать о часто называемой файловой системе Nightmare, что «не так хорошо, как медведь танцует, поражает, но то, что танцует вообще ".
NFS2 в эпоху 1991 года медленно выползал из Sun на другие платформы и был относительно сырым. Модель безопасности по существу не существовала (root на клиентском компьютере мог читать все содержимое монтирования NFS), и блокировка - через nfs.lockd - была этой стороной эксперимента. Было бы глупо ожидать, что семантика стада будет работать должным образом, если вообще существует между двумя различными, предположительно, совместимыми реализациями. Коаксиальный кабель был доминирующим PHY Ethernet в то время, когда многие пользователи сети никогда не испытывали недовольства по поводу использования (что вы имеете в виду, что забыли включить согласующий резистор 50𝛀?), Если это позволит вам лучше контролировать состояние интрасетей.
Ларри Уолл и его команда имели все основания делать пессимистичные предположения о правильности блокировок NFS в то время, и это своего рода защитное программирование, которое будущие сторонники кода не хотят удалять, поскольку доказать отсутствие дефекта так трудно удаление старого кода, который повторно вводится во взаимодействие с устаревшей системой, о которой вы даже не слышали.
С тех пор NFS значительно улучшилась, и lockd вовремя перешла на функцию ядра Linux 2.6. Для семейства систем 2003+ блокировке файлов NFS, вероятно, можно доверять, особенно если она хорошо протестирована в вашем приложении на многих платформах, на которых оно может работать.
Все вышеперечисленное было взято из памяти и, вероятно, может быть подтверждено исследованиями (например, http://nfs.sourceforge.net/ ), но доказательства, как они говорят, находятся в замке, и если вы его не проверяли Предполагается, что он сломан.
источник
Еще один, прямо из FAQ по Linux-NFS: nfs.sf.net
источник
flockне имеет, не делает и не будет блокировать через nfs монтирует.Это устарело сейчас. NFS4 поддерживает блокировку внутри протокола (не требуется демон lockd или механизм обратного вызова RPC), а
flock()метод Perl работает нормально - мы используем его в работе.Очень старые версии ядра реализованы
flock(системный вызов) как запрет на NFS, и другие вещи, такие как блокировка диапазона байтов, не поддерживаются должным образом. Вот откуда истерия.источник