По непонятным мне причинам имеет место постоянное противопоставление двух протоколов. Одни ратуют за SMB, другие - за NFS. Но почему нельзя использовать их вместе?
[spoiler]Ведь никто не мешает администратору системы «расшарить» одни и те же каталоги по двум потоколам. Работы у него, конечно, немного прибавится. Но делается это всего один раз, поэтому пережить как-то можно.
Разумеется, при условии, когда вся архитектура заранее продумана и составлена «на бумаге». Но в серьезных предприятиях именно так и должны обстоять дела.
Существенный плюс «двухпротокольности» на мой взгляд в том, что при миграции на Linux не приходится срочно-обморочно менять один протокол на другой. Настройки на сервере остаются прежними, инструкция пользователю тоже не меняется. А это уже экономия времени.
Или есть какие-то соображения, о которых обычный журналист даже не догадывается?
SMB (CIFS) содержит в себе Windows-подход: каждый пользователь должен смонтировать шару себе (то есть никаких /home, а монтируем /home/USER, файлы блокируются обязательной блокировкой. Встроены различные алгоритмы кэширования, автоматически зависящие от режима разделения файла. В общем случае в CIFS нет сведений о unix permissions и uid и gid файла.
В итоге samba-сервер плохо интегрируется с Linux-системой (остаётся вещью в себе), SMB-шары в Linux можно использовать ограниченно (не со всеми возможностями), а с NFS в роли клиента плохо работает Windows (не представляю, как можно использовать NFS кроме файлопомойки).
В общем случае для Linux поддержка SMB-протокола реализована гораздо слабже и ещё недавно не была достаточна для промышленной эксплуатации (серьёзные баги, провалы производительности, несовместимость с файловыми блокировками POSIX). Сейчас, после длительной работы, ситуация гораздо лучше. Почти все наши разработки в этой области вошли в ядро Linux.
Сейчас мы "пробиваем" в ядро Linux поддержку открытия файлов с обязательным блокированием (SHARE_READ, SHARE_WRITE, SHARE_DELETE)), в этом же направлении улучшается связь samba с ядром Linux.