Свежие комментарии
| Title | Comment |
|---|---|
| Мог. |
Мог. |
| Перераздача. |
Я это прочитал. |
| Только файлов не 5000, а 7349 |
Только файлов не 5000, а 7349. |
| Ходит, еще как ходит: |
Ходит, еще как ходит: Первый всплеск - первый заход в каталог. Второй - повторный заход. root@home-gw:/home/lexa # netstat -I ix0 1
|
| Автор запретил пере-раздачу |
Автор запретил пере-раздачу явно. |
| Мне кажется немного не |
Мне кажется немного не корректное сравнение :-). Диски-контроллер-iscsi-ntfs-каталог против диски-zfs-smb-каталог. Получается условно сравнение ntfs против zfs. Я тоже перезжал с iscsi на самбу и такой разницы не заметил. Мало того повторное открытие каталога на самбе, как по мне так мгновенно (правда каталог с 5000 файлами не нашёл). И ещё я сомневаюсь, что на самбе по сети при повторном открытии каталога кто-то сильно ходит. Хотя можно проверить :-). |
| Хотя, скорее всего, основным |
Хотя, скорее всего, основным эффектом станет увеличение размера серверного кеша :) |
| Есть другие. Opportunistic |
Есть другие. Opportunistic locks были придуманы для обеспечения когерентности клиентских кешей. Другое дело, что там получается адово сочетание режима открытия файла приложением и реализации на стороне клиентской ОС и сервера. Но отключение oplocks, которые, кажется, включены по умолчанию, может ситуацию изменить в сторону большей эксклюзивности клиента, так сказать. |
| RAW |
А оригиналов у Вас не осталось? |
| Гарантий чего? Если файловая |
Гарантий чего? Если файловая система послала flush на zvol, то zfs по семантике начнёт транзакцию и максимум, на что нарвётся внешняя файловая система - это на увеличенную задержку при получении ответа о завершении flush. Кстати не все файловые системы умеют работать с блочными устройствами с отложенной записью. Например ufs (gjournal не считается) не умеет, поэтому синхронный режим монтирования на блочном устройстве с отложенной записью это фикция :-). |
| Ну да. |
Ну да. Но если он один - то у SMB для этого нету флажочков. |
| И результат, заметим, на лице |
И результат, заметим, на лице. Один и тот же фолдер с ~5000 файлов, копии на iscsi и на SMB (на разных машинах), потому что iscsi подготовлен к разборке За то и любим |
| Вот и я о том же - мультиюзер |
Вот и я о том же - мультиюзер требует сложного и затратного протокола для согласования кэшей. А с iscsi этой проблемы вовсе нет. |
| Для файлового samba/smb |
Для файлового samba/smb-сервера согласование кэшей и достоверность данных наверное самое главное :-). Мой опыт подсказывает, что он с этим справляется, можно сказать, хорошо. Припоминаю только, что нарывался на проблемы, если небольшой файл обновлялся по ftp (по моему встроенным в explorer ftp клиентом), а у windows клиента продолжал читаться закешированный файл и требовалось сделать небольшие манипуляции для обновления. Я имел ввиду, что у каждого клиента есть своя оперативная память, клиент прочитал файл и его закэшировал. Также он закэшировался на сервере и получается двойное кэширование. Если клиент изменил файл, то смыл было кэшировать на сервере? Если закрыл и снова хочет открыть, то какая вероятность, что у клиента вымылся кэш, а у сервера он ещё остался в памяти? Особенно если клиент не один? |
| Вот все это хорошо, пока мы |
Вот все это хорошо, пока мы говорим про файловую систему. Но когда у нас в ней живет zvol, а в нем своя FS - проблема гарантий встает в полный рост, ибо не все данные одинаково полезны. |
| Покуда multi-channel не |
Покуда multi-channel не начинает данные корраптить :) |
| В zfs довольно затратная |
В zfs довольно затратная транзакция (правильнее группа транзакций). Нужно записать все блоки с данными и довольно объёмные метаданные (все указатели на записанные блоки, причём в зависимости от настроек их количество может быть отлично от 1, а на некоторые указатели всегда пишутся по 3 раза, все вышестоящие блоки в дереве должны быть обновлены/перезаписаны вплоть до uber-блока, который венчает завершение транзакции и должен быть записан 4 раза плюс может понадобиться перебалансировка всего дерева). Поэтому, как следствие для zfs предпочтительнее иметь большой recordsize и как можно больший объём записываемых данных в одной транзакции . Это входит в противоречие с потребителями данных (базы данных, клиент nfs, ...), которые часто хотят синхронизировать/записывать изменённые данные на диск и быть уверенным, что данные действительно находятся на диске. Получается можно нарваться на большую задержку :-). Для решения этой проблемы и придумали zil. Помоему сначала его и не было. Это компромиссное решение предназначено для обеспечения низкой задержки/латентности при частой синхронизации данных на диск, но оно увеличивает объём записываемых данных на диск :-(. На надёжность zfs zil никак не влияет. Он только обеспечивает, что данные пропадут не за последние 30 секунд (по-моему такая установка по умолчанию), а за меньшее время. Вот и весь выбор и соответственно выбор настроек:-). |
| Клиентов то может быть больше |
Клиентов то может быть больше одного :) |
| Потеря кэша не страшна ... |
А зачем тогда аккумуляторы к RAID-контроллерам прикручивают? ;-) |
| Ну а что делать с б/у SSD? |
Ну а что делать с б/у SSD? Сразу выкинуть? Потеря кэша не страшна же ZFS (ну кроме скорости), а вот будет ли толк в смысле скорости - вот и посмотрим. Если будет - не жалко и серверных купить потом, по мере выхода из строя. |
| Молодец. :-D |
Речь шла о людях, которые уже знают ответы на вопросы других спецов. И ещё пяток товарищей... Персоналочные б/ушные SSD СОЗНАТЕЛЬНО юзать под кэш, это даже не знаю как назвать... Упоминая ФАТ, я имел ввиду минимум возможностей в обмен на скорость записи. И среди очень умных людей встречаются желающие и рыбку и на ёлочку и ... |
| >> There are three different |
>> There are three different caches utilized by the client SMB network redirector if SMB 2.0 is the negotiated protocol Это кэши метаданных все же. С кэшами данных же сложнее, вот паттерн же: Откуда самбе знать, что этот файл надо мониторить на тему обновлений? Сходить проверить - сильно медленнее локальной RAM же. Ну и вообще - с большими каталогами, если он поменялся, то придется перечитывать метадату. В случае iscsi - монопольного доступа - никаких таких проблем нет, монопольный кэш на клиенте всегда актуален. |
| Вопрос в объеме же и |
Вопрос в объеме же и переживании перезагрузки. У меня сейчас сеть - быстрее (HDD-)дисков, и по latency и по bandwidth. Поэтому смысл в автоматически работающем SSD-кэше - просматривается, буду пробовать (понятно что их надо 3-4 штуки, чтобы 10G забить). |
| >> Спецы есть и в теме "NAS |
>> Спецы есть и в теме "NAS своими руками" Ну есть. Например, я. http://forum.ixbt.com/topic.cgi?id=109:256-12 |
| >> Уверен, FAT и EXT2 будут |
>> Уверен, FAT и EXT2 будут быстрее ZFS. Теплое с мягким? FAT/EXT2 работают с одним блочным устройством, ZFS - с большим количеством блочных устройств (да еще и для разного предназначенных). |
| >> Самба всегда была |
>> Самба всегда была медленнее ИСКАЗИ. 4-я самба и SMB3 - кисть дают! |
| samba (точнее протокол smb) |
samba (точнее протокол smb) позволяет и кэширует на стороне windows-клиента. В этом легко убедиться. Исходя из этого сразу возникает вопрос зачем кэшировать данные на стороне samba-сервера? |
| ИМХО |
Я не спец в этом вопросе, но даже я знаю, что чем меньше манипуляций с данными, тем меньше скорость чтения/записи. "Категорически не рекомендую связку аппаратный RAID+ZFS - спор вряд ли возникнет." (c) Андрей Космос Спецы есть и в теме "NAS своими руками" |
| в общем, явно какая-то херня |
в общем, явно какая-то херня имеет место быть. Потому что наоборот - люди включают sync=always для каких-то своих целей, а иначе 'zero ZIL traffic'. |
| неприятности в данном случае |
неприятности в данном случае - это асинхронная запись метаданных, в то время как винда уверена в синхронности. |
Pages
