LINUX.ORG.RU

Сетевые блочные файловые системы


0

0

на сайте Debian Administration опубликована небольшая статья о том как можно организовать работу с файловой системой по сети.

Актуально конечно не только для Debian, информация может пригодиться пользователям других дистрибутивов.

в приводимых примерах работа идет с образом хранящимся в отдельном файле, однако никто не мешает "расшарить" по сети скажем раздел жесткого диска.

>>> Подробности

Ответ на: комментарий от anonymous

>Поизучал тут ситуацию с поддержкой сетевых ФС в БЗД. Что тут сказать - печальная история. Поддержка Coda, похоже, заглохла 4 года назад; мэйл-лист freebsd-afs выглядит совершенно тоскливо. NFS и CIFS: было бы странно, если бы и эти тоже не работали.

Странно именно то, что на Linux-форумах из сетевых файловых систем почему-то в 99% случаев обсуждается SAMBA (SMB/CIFS), но не NFS. Ж)

iZEN ★★★★★
()
Ответ на: комментарий от lester

> fuse крутая штука :) она еще и nrg, mdf, iso, ntfs и другие умеет монтировать
Блин, покажи как может mdf смонтировать? а то только конверторы и видел. =(

Atlant ★★★★★
()

в свое время пришлось плотно поработать с IP storage (SAN over IP) под Linux. NBD никуда не годится, при создании софтверного рейда том сыпется при первой же попытке записи. Да и вообще зачем юзать пионерскую поделку, если есть ISCSI?

anonymous
()

Полезный сайт, добавил в закладки.

По теме - я юзаю NFS.

schakal
()
Ответ на: комментарий от anonymous

> в свое время пришлось плотно поработать с IP storage (SAN over IP) под Linux. NBD никуда не годится, при создании софтверного рейда том сыпется при первой же попытке записи. Да и вообще зачем юзать пионерскую поделку, если есть ISCSI?

Больше всего "порадовало" , что среди более 50 постов только один человек вспомнил про iscsi и задал правильный вопрос - а зачем это надо , когда есть iSCSI , полностью поддерживаемый SNIA как стандарт . Изобретать велосипед , непонятное поделие , чтобы вот сейчас взять и заткнуть текущюю задачу с помощью этой (весьма занимательной, надо сказать) програмки ? А потом иметь гемморой с расширяемостью , производительностью и так далее ?

ilyxa
()
Ответ на: комментарий от iZEN

iZEN> Если учесть, что к релизу 7.0 FreeBSD избавится от глобальных блокировок в ядре, почему нет?

Так и запишем: FreeBSD становится вендой :)

Quasar ★★★★★
()
Ответ на: комментарий от iZEN

>Странно именно то, что на Linux-форумах из сетевых файловых систем почему-то в 99% случаев обсуждается SAMBA (SMB/CIFS), но не NFS. Ж)

Вероятно, из-за того, что в этих 99% случаев нужно обеспечить возможность доступа к данным с вендовых компов? Хотя NFS, вообще говоря, в венде тоже поддерживается, несмотря на то, что поддержку надо ставить отдельно.

anonymous
()
Ответ на: комментарий от anonymous

> Вероятно, из-за того, что в этих 99% случаев нужно обеспечить возможность доступа к данным с вендовых компов? Хотя NFS, вообще говоря, в венде тоже поддерживается, несмотря на то, что поддержку надо ставить отдельно.

Сравнение скорости работы 1С/dbf на SAMBA и NFS на 5-10 клиентов есть? :)))

yyk ★★★★★
()
Ответ на: комментарий от iZEN

>Если учесть, что к релизу 7.0 FreeBSD избавится от глобальных блокировок в ядре, почему нет?

В Linux этих блокировок несколько лет как нету, но никто не спешит пихать туда разнобразные серверы. Почему? Тому есть целый ряд причин. Во-первых, безопасность. Удаленная уязвимость в любом из демонов, работающих в привилегированном режиме, даст в лучшем случае kernel panic (как венда вываливалась в синьку при применении эксплойта как раз для SMB), в худшем - выполнение кода с неограниченными привилегиями. Далее - проблемы с наличием нужной инфраструктуры в ядре. В общем случае туда нужно будет тащить нехилую часть glibc. Затем - неизвестно, что станет с масштабируемостью, хотя kthread_create() и kernel_thread() и предоставляют средства создания потоков. Ну, и конфигурирование демонов с помощью неких глобальных sysctl или sysfs тоже ясности и порядка не прибавляет. Ну, и еще некоторые ограничения, хотя принципиальная возможность реализовать демоны в ядре существует - но никто в здравом уме этого не делает.

anonymous
()
Ответ на: комментарий от iZEN

Вообще если вести речь о хранилище (а в статье упор на удалённую работу с дисками), то правильный ответ - iSCSI.

//Loseki

anonymous
()
Ответ на: комментарий от anonymous

О, вот и в каментах написали.

//Loseki

anonymous
()
Ответ на: комментарий от anonymous

>Вообще если вести речь о хранилище (а в статье упор на удалённую работу с дисками), то правильный ответ - iSCSI

Ну, или AoE.

anonymous
()
Ответ на: комментарий от anonymous

и какая же файловая система будет на iSCSI, поддерживающая блокировки? или ты будешь раздавать target'ы просто так, всем желающим? ню-ню

ps а gfs уже похоронили?

npanop
()
Ответ на: комментарий от npanop

> и какая же файловая система будет на iSCSI, поддерживающая блокировки? или ты будешь раздавать target'ы просто так, всем желающим? ню-ню

да какую нужно . вопросы касательно метаданных и вообще фс - при чем тут iscsi ? есть блочные устройства , поверх них - что хотите - точнее - что нужно .

по вопросам "раздавать кому попало" - было бы неплохо ознакомится со стандартом iscsi ? в общем случае , по умолчанию - да , кому попало . так и в сети хранения кого попало быть не должно .

ilyxa
()
Ответ на: комментарий от anonymous

> в свое время пришлось плотно поработать с IP storage (SAN over IP) под Linux. NBD никуда не годится, при создании софтверного рейда том сыпется при первой же попытке записи. Да и вообще зачем юзать пионерскую поделку, если есть ISCSI?

Ну например Linux умеет через NBD монтировать swap. Очень удобно для загружаемых по сети железок (в паре с NFS-mounted /).

Через iSCSI такое можно сделать? Если да, то можно ссылку на описание?

execve
()
Ответ на: комментарий от anonymous

>> fuse крутая штука :) она еще и nrg, mdf, iso, ntfs и другие умеет монтировать

>Всю жизнь монтировал iso без fuse. Я что--то пропустил в этой жизни?

nrg тоже можно монтировать без фуза.

anonymous
()
Ответ на: комментарий от ilyxa

вдогонку, без комментариев:

http://www.opennet.ru/base/sys/dbd_vs_iscsi.txt.html

В драйвере NBD обработки ошибок нет как класса. При отвале сервера он тормозит
очередь запросов и не растормаживает ее никогда. Серверной части нормальной
нет, написана хрен знает когда и хрен знает как.

ENBD лучше, активно развивается, содержит ядреную и юзерспейс части, но
мне не понравился.

GNBD из комплекта GFS сильно заточен на работу именно с GFS и ейным
lock management'ом и требует обвязки (fencing, нечетного количества
узлов для стабильной версии etc). Ходят непроверенные слухи, что ребята,
занимающиеся GFS в RedHat, усиленно смотрят в сторону iSCSI в качестве
замены для GNBD.

iSCSI меня заинтересовал гораздо больше. Связка initiator'a от CISCO
(http://linux-iscsi.sf.net) + iSCSI enterprise target (http://iscsitarget.sf.net)
ведет себя вполне пристойно после чтения mail-list'ов и помахивания
рашпилем.

filin ★★
()
Ответ на: комментарий от anonymous

> Кстати, как сечас лучше расшаривать данные по сети? По какому протоколу? Самый такие линуксовые способы?

у меня на линукс -- по NFS, на offtop -- samba

vadiml ★★★★★
()
Ответ на: комментарий от execve

>Ну например Linux умеет через NBD монтировать swap. Очень удобно для загружаемых по сети железок (в паре с NFS-mounted /). Через iSCSI такое можно сделать? Если да, то можно ссылку на описание?

Конечно можно. В случае iSCSI рассматривайте полученное блочное устройство как полный аналог SCSI устройства. Через ISCSI подключаются спокойно даже ленточные накопители, дисковые библиотеки и прочая номенклатура SCSI устройств.

anonymous
()
Ответ на: комментарий от iZEN

Почему - почему .... потому что ты идиот, и это вне зависимости от OS! :-E

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.