The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от opennews (??) on 09-Апр-15, 21:25 
После десяти месяцев разработки доступен (http://list.zfsonlinux.org/pipermail/zfs-announce/2015-April...) релиз ZFSonLinux 0.6.4 (http://zfsonlinux.org/), реализации файловой системы ZFS, оформленной в виде модуля для ядра Linux. Готовые установочные пакеты подготовлены (http://zfsonlinux.org/) для основных дистрибутивов Linux, включая Debian, Ubuntu, Fedora, RHEL/CentOS. Кроме того, модуль ZFSonLinux уже входит в состав дистрибутивов Gentoo, Sabayon Linux и AltLinux.

В рамках ZFSonLinux подготовлена реализация компонентов ZFS, связанных как с работой файловой системы, так и с функционированием менеджера томов. В частности, реализованы компоненты: SPA (Storage Pool Allocator), DMU (Data Management Unit), ZVOL (ZFS Emulated Volume) и ZPL (ZFS POSIX Layer). Дополнительно проектом обеспечена возможность использования ZFS в качестве бэкенда для кластерной файловой системы Lustre. Наработки проекта основаны на оригинальном коде ZFS, импортированном из проекта OpenSolaris и расширенном улучшениями и исправлениями от сообщества Illumos. Реализованная в ZFSonLinux версия пула и файловой системы совместима с ZFS из состава Illumos и FreeBSD. Проект развивается при участии сотрудников Ливерморской национальной лаборатории по контракту с Министерством энергетики США.

Код распространяется под свободной лицензией CDDL, которая несовместима с GPLv2, что не позволяет добиться интеграции ZFSonLinux в состав основной ветки ядра Linux, так как смешивание кода под лицензиями GPLv2 и CDDL недопустимо. Для обхода данной лицензионной несовместимости было решено распространять продукт целиком под лицензией CDDL в виде отдельно загружаемого модуля, который поставляется отдельно от ядра. Стабильность кодовой базы ZFSonLinux оценивается как сопоставимая с другими ФС для Linux.

Основные изменения:


-  Обеспечение совместимости с ядром Linux 4.0;
-  Поддержка асинхронного ввода/вывода (AIO);
-  Режим сжатия метаданных с использованием алгоритма LZ4;

-  Реализация шести новых флагов подключаемой функциональности (feature flags (http://en.wikipedia.org/wiki/OpenZFS#Pool_versions_and_featu...)):


-  spacemap_histogram - позволяет хранить дополнительную информацию о размещении свободного пространства в пуле;

-  extensible_dataset - даёт возможность более гибко использовать внутренние структуры данных;

-  bookmarks - реализует возможности для пометки момента времени создания снапшота, необходимые для работы команды "zfs bookmark";

-  enabled_txg - включает запись групповых номеров транзакций;


-  hole_birth - увеличивает производительность операций инкрементальной отправки данных ("zfs send -i") и получения объектов, содержащих большое число пустых областей;

-  embedded_data - увеличивает производительность и экономит дисковое пространство при работе с хорошо сжимаемыми блоками, которые поддаются упаковке как минимум в 112 байт (содержимое встраивается в dnodes).

-  Возможность использования вызова fallocate() FALLOC_FL_PUNCH_HOLE для предварительного выделения места под пустые области в файлах;
-  Отображения дополнительных данных об уровне фрагментации в выводе 'zpool list';
-  Новое свойство "redundant_metadata", позволяющее управлять уровнем резервирования метаданных;
-  Новое свойство "overlay" для управления поведением для непустых точек монтирования;
-  В выводе 'zpool list -v' обеспечен показ ёмкости отдельных дисков;
-  Новый режим вывода 'zpool get -H', удобный для разбора скриптами;
-  Добавлена команда  'zpool create -t'  для создания пула с временным именем;
-  Из FreeNAS импортирован скрипт arc_summary.py (https://github.com/freenas/freenas/blob/master/gui/tools/arc...), осуществляющий вывод сводной статистики;
-  Поддержка контрольных точек для DTrace (DTRACE_PROBES);
-  В zdb добавлено отображение гистограмм сжатых блоков.

URL: http://list.zfsonlinux.org/pipermail/zfs-announce/2015-April...
Новость: http://www.opennet.dev/opennews/art.shtml?num=42012

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 09-Апр-15, 21:25 
Вопрос к тем, кто использует ZFS на линуксе - TRIM он уже поддерживает или все еще нет?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +4 +/
Сообщение от Капитан (??) on 09-Апр-15, 21:29 
Вот что говорят источники http://open-zfs.org/wiki/Features#TRIM_Support
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

102. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Anton email(??) on 22-Апр-15, 14:17 
В request для trim указан milestone 0.7.0, которая, вроде, следующая.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

9. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от Аноним (??) on 09-Апр-15, 23:33 
Четаяочкую:)
Если сторидж ляжет это за 75 vm-ок в продакшене умрёт ...
Посижу пока на соляре. Хотя на линуксах его я есть очень хотеть :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от iCat (ok) on 10-Апр-15, 05:17 
Уже давненько пользуюсь этим пакетом для работы со снятыми из серверов Nexenta дисками.
Или для подготовки томов для установки в серверы с Nexenta.
Дома вся мультимедия и архивные домашние фото лежат на ZFS.
Глюки были, но давненько и не критичные к утрате данных.
Весьма чувствительно к бэдблокам на железках, но это, как я понимаю - у множества FS так.
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

22. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от count0krsk (ok) on 10-Апр-15, 09:52 
Да как сказать... У меня на старом ноуте половина HDD - сплошные бэды. Отрезал их в отдельные разделы, 160 Гб превратились в 90, но работает. ext4. Раньше вис, когда hdd клинило на бэде.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

26. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +2 +/
Сообщение от Аноним (??) on 10-Апр-15, 11:38 
> Отрезал их в отдельные разделы,

Вот это я понимаю - из базуки по мухам :)

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

36. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от xPhoenix (ok) on 10-Апр-15, 12:26 
Ну так альтернатива - покупка нового HDD.
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

37. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +1 +/
Сообщение от правдоруб on 10-Апр-15, 12:55 
Если хватает 90 - лучше SSD.
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

38. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +1 +/
Сообщение от Аноним (??) on 10-Апр-15, 13:10 
Это не альтернамива, это - единственно верное решение.
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

44. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 10-Апр-15, 20:56 
> Ну так альтернатива - покупка нового HDD.

Во первых, если по граблям ну очень хочется попрыгать - лучше попробовать спровоцировать фирмваре на запись в сбойный сектор. При активированном remap. Тогда фирмваре переназначит сбойный сектор на резервный. Если сбойных секторов не очень много - номер катит и с точки зрения программ диск станет исправным. Man hdparm (внимание: безбашенное командование hdparm - опасно для данных на диске и самого диска) - им можно выполнить запись в сектор с конкретным номером. А если резерва не хватило - диск лучше отправить в мусорник, т.к. у него уже большие проблемы и он может склеить ласты в любой момент и будет терять данные дальше с высокой вероятностью. Я так починил один WD Green - у него 15 секторов выбилось, как оказалось. Так он с тех пор 2 года пашет, новые бэды так и не отрастил. Будет жить. Некоторое время. Или вон один хитач - сам 2 нестабильных сектора перенес за 6 лет работы.

Во вторых, если диск сильно сыпется - он и дальше будет данные терять. Отрезать сбоящую область разделом - достаточно креативно, но - достаточно спорное решение. В том плане что если винт осыпается на значительной площади, значит у него серьезные проблемы и надежность его работы - крайне низкая. И наверное не очень прикольно, если ноут в чистом поле вам сообщит: отдыхайте, сегодня работать не будем!

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

24. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от ДяДя on 10-Апр-15, 10:28 
> ZFSonLinux оценивается как сопоставимая с другими ФС для Linux.

Так даже у них степень стабильности не одинаковая.
Сказали бы конкретно, что он подразумевают :-)

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

33. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +2 +/
Сообщение от анон on 10-Апр-15, 12:08 
btrfs, скорее всего.
Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

10. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –2 +/
Сообщение от Аноним (??) on 10-Апр-15, 00:24 
А зачем desktop-ориентированому sabayon-у - эта zfs?
(хотя конечно приятен сам факт, ибо для меня пока нет лучшего дистра)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +1 +/
Сообщение от ананим.orig on 10-Апр-15, 01:29 
Унаследована от генту?
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

13. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от Sunderland93 (ok) on 10-Апр-15, 05:52 
Что предпочтительнее для десктопа - ZFS или Btrfs? Из этих двух.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +3 +/
Сообщение от Аноним (??) on 10-Апр-15, 07:09 
ZFS пригодно если у тебя в десктопе >4gb памяти ибо 2gb ZFS отожрет. BTRFS еще сырая.
Ну и по факту zfs,btrfs нужно тюнить под твои данные, это не универсальное хранилище.
А для дома EXT4 вот что тебе нужно.
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

17. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +1 +/
Сообщение от CSRedRat email(ok) on 10-Апр-15, 08:20 
А как же XFS?
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

18. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –2 +/
Сообщение от Аноним (??) on 10-Апр-15, 08:45 
Для дома? Первое апреля давно прошло...
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

20. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +1 +/
Сообщение от Ващенаглухо (ok) on 10-Апр-15, 08:50 
А что так удивляет? Дома использую raid5 из пяти 1Tb дисков под XFS. Храню фотки, фильмы итд.
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

23. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от count0krsk (ok) on 10-Апр-15, 09:54 
> А что так удивляет? Дома использую raid5 из пяти 1Tb дисков под
> XFS. Храню фотки, фильмы итд.

Не надо использовать raid5, поверьте тому, кто с ними за*пался. Пользуйте 6й или 10й. На край 50й, если дисков много.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

31. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –2 +/
Сообщение от Аноним (??) on 10-Апр-15, 11:47 
> А что так удивляет? Дома использую raid5 из пяти 1Tb дисков под
> XFS. Храню фотки, фильмы итд.

А когда какой-нибудь диск (или контроллер) вместо того чтобы умереть совсем начнет выдавать какое-то барахло - ты узнаешь много нового и интересного :-)

Если какой-нибудь btrfs например еще может понять какой из вариантов данных там правильный, ориентируясь на совпадение чексумм (ZFS скорее всего тоже нечто подобное реализует, если там не протупили), то обычный RAID5 понятия не имеет кто из дисков врет и поэтому запросто может отдать кривые данные.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

34. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –2 +/
Сообщение от maximnik0 on 10-Апр-15, 12:18 
> Если какой-нибудь btrfs например еще может понять какой из вариантов данных там
> правильный, ориентируясь на совпадение чексумм (ZFS скорее всего тоже нечто подобное
> реализует, если там не протупили), то обычный RAID5 понятия не имеет
> кто из дисков врет и поэтому запросто может отдать кривые данные.

У ZFS  самый пока надежный алгоритм контрольных сумм основанный на алгоритме хеширования MD5 .Кроме того (не знаю перенесли ли на этот выпуск эту опцию ) можно если тебе не жалко места и не важна скорость - задействовать алгоритм защиты аналогичный от блюрея -до 30 % инфы можно терять с возможностью приостановления .


Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

35. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от maximnik0 on 10-Апр-15, 12:22 
ОЙ извиняюсь
> % инфы можно терять с возможностью приостановления .

инфы можно терять с возможностью восстановления .

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

45. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 10-Апр-15, 21:04 
> У ZFS  самый пока надежный алгоритм контрольных сумм основанный на алгоритме
> хеширования MD5 .

Тут проблема скорее в том что RAID5 (а также всякие варианты зеркала) - в чистом виде не содержит никакой информации о корректности данных. Поэтому когда диск вместо того чтобы сразу и полностью околеть стал выдавать левые данные - RAID5 и зеркала по типу RAID1 не знают какой накопитель им соврал и где была верная копия данных. По этой причине RAID может не спасти от некоторых видов разрушения данных.

В случае когда файлуха хранила чексумм - можно опробовать все варианты. Когда чексум совпал - тогда и выбран правильный набор блоков.

Мэйсон в фэйсбуке уже хвастался что его btrfs уже отловил несколько контроллеров, выдававших фигню вместо данных :)

> важна скорость - задействовать алгоритм защиты аналогичный от блюрея -до 30
> % инфы можно терять с возможностью приостановления .

RAID5/6 и прочие - являются неким очень частным случаем подобных схем, с разнесением блоков по девайсам.

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

54. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –4 +/
Сообщение от Anonimous on 11-Апр-15, 02:54 
Ну по-man-ь что хотя бы zpool scrub делает :)
А потом уже концепцию. А то про просторы большого театра - запрасто, а про то что стоит тихонечко в продакшене и молотит - ни гу-гу :)
Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

73. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +1 +/
Сообщение от Аноним (??) on 12-Апр-15, 00:20 
> Ну по-man-ь что хотя бы zpool scrub делает :)

Я догадываюсь.

> А потом уже концепцию. А то про просторы большого театра - запрасто,
> а про то что стоит тихонечко в продакшене и молотит - ни гу-гу :)

Красивое гарцевание кульсисопа. Жаль что лишний раз подтверждает мнение о соотношении квалификации и ЧСВ тех кто по сановским технологиям прется.

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

64. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от maximnik0 on 11-Апр-15, 14:27 
>> А что так удивляет? Дома использую raid5 из пяти 1Tb дисков под
>> XFS. Храню фотки, фильмы итд.
> А когда какой-нибудь диск (или контроллер) вместо того чтобы умереть совсем начнет
> выдавать какое-то барахло - ты узнаешь много нового и интересного :-)

Кстати в новой версии XFS тоже должен быть проверка контрольных сумм //

http://www.opennet.dev/opennews/art.shtml?num=39788

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

89. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 13-Апр-15, 13:03 
> Кстати в новой версии XFS тоже должен быть проверка контрольных сумм //

Только для метаданных - не то.

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

58. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от aim (ok) on 11-Апр-15, 11:49 
для домашней файлопомойки - основа которой сериалы и кино - самое оно. да и фотаньки теперь такого размера что тоже неплохо на xfs укладываются.
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

19. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Ващенаглухо (ok) on 10-Апр-15, 08:47 
XFS тоже очень любит много памяти.
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

21. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от ryoken email on 10-Апр-15, 09:46 
> XFS тоже очень любит много памяти.

Подскажите, а как это померять? (у меня как раз вся мультимедия на 2-х 4Тб в XFS-е).

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

28. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +1 +/
Сообщение от Аноним (??) on 10-Апр-15, 11:42 
> XFS тоже очень любит много памяти.

Поскольку оно часть ядра - памятью оно управляет по человечески и в проблемы пользователя все это не отливается. Да и оно вполне нормально работает даже если памяти немного.

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

30. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Elhana (ok) on 10-Апр-15, 11:46 
Любая FS будет брать память для кеша, если она есть - это наоборот хорошо.
Просто ZFS не интегрирована с ядерным кешем, у ZFS свой ARC. Она совершенно нормально отдает память назад когда системе надо. У меня 16Gb, обычно занято болтается 14, если я запускаю пару virtualbox vm, которым выделено по 4GB, они нормально стартуют без свопа, без лагов.
Если у вас меньше чем 4Gb памяти, то уже нужно подумать, но работать оно все равно будет, просто медленнее. А вообще сейчас даже у ноутов по 8Gb памяти, она дешевая. Если проц AMD, то можно даже с ECC взять.
А что касается zfs vs ext4, тут вопрос вам шашечки или ехать - надежность или скорость?
Чексум, мгновенных снапшотов в ext4 нет и прозрачное сжатие в zfs очень даже полезно.
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

32. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 10-Апр-15, 11:53 
> совершенно нормально отдает память назад когда системе надо.

Кроме того что это никак не интегрировано с управлением памятью ядром и потому появляются лишние шансы что программы пообломаются на выделении памяти, ведь ядро не может пойти и жестко отобрать память когда она понадобилась.

> У меня 16Gb, обычно занято болтается 14,

А если на 128 так и вообще. Правда если эн гигз выделить за один присест - можно получить от ворот поворот. Хотя теоретически должно быть наоборот, т.к. они вроде как есть. В результате в такой системе программы могут заваливаться лишний раз на ровном месте. Это пофигу для файлсервера, но не слишком хорошо для всех остальных случаев.

> выделено по 4GB, они нормально стартуют без свопа, без лагов.

Зато программы пытающиеся выделить себе большой кус памяти - могут запросто получить фигу. Потому что этот, адаптивный, потом может и адаптируется. Но потом. А надо было "еще вчера". По поводу чего отсутствие интграции с управлением памяти кернела - не есть хорошо.

> Чексум, мгновенных снапшотов в ext4 нет и прозрачное сжатие в zfs очень
> даже полезно.

Если уж на то пошло - оно и в btrfs есть. И даже не страдает этими проблемами. Но там свежее ядро - мастхэв.

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

27. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 10-Апр-15, 11:40 
> А как же XFS?

Не умеет CoW и снапшоты. По поводу чего не является заменой. И нет, то уродство которое можно сколхозить через LVM - сами понимаете, не то.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

29. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –2 +/
Сообщение от maximnik0 on 10-Апр-15, 11:44 
> Что предпочтительнее для десктопа - ZFS или Btrfs? Из этих двух.

ZFS любит кушать  память  и крайне желательно 64 бит ядро .Зато возможностей конфигураций по томам и разделам - страшно делается ,кроме того к плюсам можно отнести такую вещь как автоматическое выявление дубликатов ,серьезный журнал контрольных сумм (мд5 алгоритм ).У Btrfs чуть ниже скорость работы ,но к плюсам можно отнести что можно конвертировать ext3/4 (даже некоторое время можно сделать  откат обратно ) и родная потдержка из ядра .Но обе файловые системы сложные - нужно понимать что делаешь ,снапшотами и не продуманными действиями (командами) можно убить и ZFS ,так и Btrfs .Также крайне желательно чтобы оставалось не менее 25% свободного места на разделах(е) .Но пока  Btrfs считается не доведенная ,на raid некоторых конфигураций ставить не рекомендуется  .А так c не особо  важной инфой и опциями autodefrag,compress=zlib,relatime работает достаточно нормально .Но старожилы пока не рекомендуют делать больше 3 снапшотов на раздел .А сжатие файлоа -обе потдерживают ,как и работу с флэш носителями .

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

40. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +1 +/
Сообщение от Аноним (??) on 10-Апр-15, 18:54 
maximnik0 ты походу в >|<оском продакшене ZFS не юзал. А йА юзал, юзаю и пока не виэе причин не юзать в будущем. Так вот - дедупликэйшен - ЗЛО. По крайней мере на нагруженных томах, и по крайней мере сейчас. Avoid this sheet as much as you can!

BRGDS, один одмен

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

48. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –2 +/
Сообщение от maximnik0 on 10-Апр-15, 22:18 
> maximnik0 ты походу в >|<оском продакшене ZFS не юзал. А йА юзал,
> юзаю и пока не виэе причин не юзать в будущем. Так
> вот - дедупликэйшен - ЗЛО. По крайней мере на нагруженных томах,
> и по крайней мере сейчас. Avoid this sheet as much as
> you can!

И что даже контролеры с аппаратной поддержкой подсчета и хеширования MD5 не помогает ?


Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

50. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 10-Апр-15, 23:57 
> И что даже контролеры с аппаратной поддержкой подсчета и хеширования MD5 не помогает ?

Помогает, помогает. Как помрет у тебя уникальный мегаконтроллер - так ты и узнаешь почем фунт лиха на этой планете, когда окажется что новый ждать пару недель минимум, а формат метаданных и прочая - никто не понимает, так что даже данные не вынешь.

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

55. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от Anonimous on 11-Апр-15, 03:03 
>> И что даже контролеры с аппаратной поддержкой подсчета и хеширования MD5 не помогает ?
> Помогает, помогает.

Тут такое дело мужики ... я не знаю, не было у меня таких. ВотЪ :)

> Как помрет у тебя уникальный мегаконтроллер - так ты и узнаешь почем фунт лиха

Для ZFS вообше надо простейшие из быстрейших HBA. Никаких рэйдов и прочего. Как то так :)

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

60. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от maximnik0 on 11-Апр-15, 12:29 
> Помогает, помогает. Как помрет у тебя уникальный мегаконтроллер - так ты и
> узнаешь почем фунт лиха на этой планете, когда окажется что новый

Это решается просто - берется сразу 2 штуки контролера :-)
И вроде в родной реализации (от Оракла )написано что проблему починили .

Ну и вообще-то в вопросе задавалось про домашнее применение ,исходя из вопроса я и ответил .

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

71. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +1 +/
Сообщение от Аноним (??) on 11-Апр-15, 18:16 
>> Помогает, помогает. Как помрет у тебя уникальный мегаконтроллер - так ты и
>> узнаешь почем фунт лиха на этой планете, когда окажется что новый
> Это решается просто - берется сразу 2 штуки контролера :-)

С учётом цены на _мега_контроллеры ... браво, чо там! :)
> И вроде в родной реализации (от Оракла )написано что проблему починили .

И как это можно решить? Сдаётся мне свистишь ты ... :)

> Ну и вообще-то в вопросе задавалось про домашнее применение ,исходя из вопроса я и ответил .

Для дома любое дорогое железо ... так а ты чей сын? А то вдруг мы тут с мажором говорим которому взять второй контроллер за полторы тыЩЩи зелени(!), про запас(!!), для дома(!!!) - папа оплатит. :)

Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

74. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 12-Апр-15, 00:22 
> Это решается просто - берется сразу 2 штуки контролера :-)

И _два_ чемодана денег, а не один. Да и превращаться в склад периферии "на всякий случай" тоже не совсем бесплатное удовольствие в общем случае.

> И вроде в родной реализации (от Оракла )написано что проблему починили .

Реализации чего? Оракл разве делает контроллеры? ZFS то заметит по несовпадению чексум. Как и btrfs. А вот прочие...

> Ну и вообще-то в вопросе задавалось про домашнее применение ,исходя из вопроса
> я и ответил .

Дома ZFS имхо на...й не упал. Слоупочный и память трескает.

Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

79. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от maximnik0 on 12-Апр-15, 12:25 
дной реализации (от Оракла )написано что проблему починили .

> Реализации чего? Оракл разве делает контроллеры? ZFS то заметит по несовпадению чексум.
> Как и btrfs. А вот прочие...

Функции выявление дубликатов - под нагрузкой тормозило и глючило .Применение контролеров с механизмом аппаратным реализации алгоритма MD5 ( используется в функции поиска дубликатов ) сглаживало проблему.Поскольку вопрос был про домашнее применение то я включение  дедублекейшена поставил в плюс ,вряд ли при домашнем применение будут дикие нагрузки .И читал в описаниях что в родной реализации от Оракла  проблему починили переделав  механизм выявление дубликатов на фоновый ,то есть сперва пишем а потом если выявили дубликат , удаляем файл с заменой на ссылку ,и что то еще упоминалось про переделанный механизм индексации ,я не понял что к чему относится .

Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

83. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 12-Апр-15, 19:17 
> дной реализации (от Оракла )написано что проблему починили .

Опечатка почти по фрейду. И кто и что починил?

> Функции выявление дубликатов - под нагрузкой тормозило и глючило .

Так это by design.

> дубликатов ) сглаживало проблему.

Оно переставало трескать память?

> будут дикие нагрузки .

Изен тут был. с его 20Мб/сек на 3 дисках. Вопил что ему достаточно. Правда я думаю что дело было не только в дедупе, как он рассказывал, но и в том что он СoW механику ушатал, забив пул в хламину.

> фоновый ,то есть сперва пишем а потом если выявили дубликат ,

Так и в btrfs можно, внезапно. Даже программы для этого есть. Поздравляем, теперь ZFSники тоже будут дедуплицировать "как в btrfs" :)

Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

25. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от Templar3d (ok) on 10-Апр-15, 11:27 
Ждемсь в Proxmox 4
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

39. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 10-Апр-15, 18:46 
вынимать диски из пула оно уже научилось, или нет? В блоге автора читал, что да, уже лет много назад. А результата всё не вижу.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

42. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 10-Апр-15, 20:33 
> В блоге автора читал,

Это где?

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

43. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от Аноним (??) on 10-Апр-15, 20:53 
> вынимать диски из пула оно уже научилось, или нет? В блоге автора
> читал, что да, уже лет много назад. А результата всё не вижу.

Попилили модеры мой ответ, ибо я там персонально по тебе прошелся. За дело прошелся, ну да ладно.

Скучный ответ:
из mirror - умело всегда.
из raidz - не умело, и не факт что это просто сделать.

Дальше был ответ не скучный, но что хотел сказать модер - я понел :)

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

46. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +1 +/
Сообщение от Аноним (??) on 10-Апр-15, 21:11 
> из mirror - умело всегда.

А радости? Проблема ZFS в том что пул может только увеличиваться. А уменьшить его, изъяв диски - ФИГВАМ. Билет в один конец.

> из raidz - не умело, и не факт что это просто сделать.

А вот архитект Крис Мэйсон делавший btrfs - о таких вещах подумал, в отличие от санок.
Поэтому:
1. Btrfs хранит back references, позволяющие просто и ненапряжно "убрать вот эти данные вот отсюда". Что позволяет прицельно расчистить "вот этот накопитель" по быстрому, да и вынуть его из пула (с сокращением free space доступного btrfs, разумеется).
2. А Мэйсон как-то не считал что hardcoded уровень райда хорошо и правильно, поэтому btrfs нормально относится к идее что будет произвольная смесь уровней. Не весь потенциал еще реализован. Но уж перестроить из одного уровня в другой на ходу - оно по любому может. В этот момент будут существовать минимум 2 типа chunks: в старой схеме храненияи в новй. А процесс конвертации будет по мере возможности перегоять chunks из старой схемы в новую.

Или к вопросу почему btrfs - на световые годы впереди этого саночного пепелаца...

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

47. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от csdoc (ok) on 10-Апр-15, 21:47 
> Или к вопросу почему btrfs - на световые годы впереди этого саночного пепелаца...

ZFS: https://rudd-o.com/linux-and-free-software/ways-in-which-zfs...

BTRFS: http://drdabbles.us/journal/2014/2/15/my-case-for-btrfs-over...

ZFS уже используется в production, а BTRFS еще нестабильная альфа-бета версия.
Сколько лет еще надо ждать, пока BTRFS станет пригодной для использования, 5? 10? 15? 20?

Если выбирать между вариантами "ZFS сейчас" или "идеальная BTRFS через 10-15 лет",
первый вариант нередко выглядит более предпочтительным, чем стабильные XFS или ext4

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

49. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 10-Апр-15, 23:55 
> ZFS уже используется в production, а BTRFS еще нестабильная альфа-бета версия.

Во первых, это дело наживное. Во вторых, всякие зюзи и оракли его уже начинают сватать. А Мэйсон так и вовсе в мордокниге его разворачивает.

> Сколько лет еще надо ждать, пока BTRFS станет пригодной для использования, 5?
> 10? 15? 20?

Я им пользуюсь уже сейчас в не слишком ответственных применениях. Ясен пень это или со свежим майнлайном или с всякими кастомными дистроядрами типа того как у оракла и зюзи.

Никаких там 15 лет не требуется - там из явно недопиленного разве что raid5/6, и тот - к 4.0 более-менее привели в чувство вроде. Но т.к. свежак - протестированность этих code paths ессно хуже всего остального.

> Если выбирать между вариантами "ZFS сейчас" или "идеальная BTRFS через 10-15 лет",
> первый вариант нередко выглядит более предпочтительным, чем стабильные XFS или ext4

ZFS ни сейчас ни в обозримой перспективе не может отключить CoW например. Даже если оно мешается БД или какому там еще софту с своим журналированием. И дефрага там нет и не планируется, хотя CoW городит выноски-фрагменты by design. И нормальное изъятие дисков из пула, с уменьшением - где? Не говоря о том что оно вообще не часть ядра и никогда таковой не будет - спасибо санкам за лицензию. Впрочем это к лучшему - btrfs передизайнили с учетом многих иных идей и имхо получилось достаточно интересно. Скажем мысль про RAID с пофайловой гранулярностью - мне кажется весьма перспективной. На мой вкус - круто придумано. Интегрировать RAID с ФС? Тогда логично этим пользоваться по полной, а не просто сделать очередной копипаст "в соляре не было менеджера томов - запихали его в ФС".

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

52. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от csdoc (ok) on 11-Апр-15, 00:32 
>> ZFS уже используется в production, а BTRFS еще нестабильная альфа-бета версия.
> Во первых, это дело наживное. Во вторых, всякие зюзи и оракли его
> уже начинают сватать. А Мэйсон так и вовсе в мордокниге его
> разворачивает.

Facebook will trial Btrfs in its "web tier" servers,
explaining that's the easiest tier to recover if necessary
- если упал какой-то сервер, его просто вытащили из кластера и заменили другим.
Базы данных и другую критически важную информацию на BTRFS еще никто не хранит.

>> Сколько лет еще надо ждать, пока BTRFS станет пригодной для использования, 5?
>> 10? 15? 20?
> Я им пользуюсь уже сейчас в не слишком ответственных применениях. Ясен пень
> это или со свежим майнлайном или с всякими кастомными дистроядрами типа
> того как у оракла и зюзи.

вопрос был про ответственные и слишком ответственные применения.
ZFS судя по всему, там использовать уже можно, а вот BTRFS - еще нет.

> Никаких там 15 лет не требуется - там из явно недопиленного разве
> что raid5/6, и тот - к 4.0 более-менее привели в чувство
> вроде. Но т.к. свежак - протестированность этих code paths ессно хуже
> всего остального.

RAID5? Это они зря, http://www.zdnet.com/article/why-raid-5-stops-working-in-2009/
RAID6 ситуация не лучше: http://www.zdnet.com/article/why-raid-6-stops-working-in-2019/

>> Если выбирать между вариантами "ZFS сейчас" или "идеальная BTRFS через 10-15 лет",
>> первый вариант нередко выглядит более предпочтительным, чем стабильные XFS или ext4
> ZFS ни сейчас ни в обозримой перспективе не может отключить CoW например.

А BTRFS разве может? Это ведь точно такая же CoW файловая система.
Кстати, с постепенным переходом на флеш CoW вообще перестанет быть проблемой.

> Даже если оно мешается БД или какому там еще софту с своим журналированием.

ZIL не мешает, а помогает делать запись более быстрой.
У BTRFS есть аналогичная feature, только тут она не вынесена на отдельный SSD,
так что толку от нее будет не много: https://en.wikipedia.org/wiki/Btrfs#Log_tree

Как и L2ARC - аналогичной возможности у BTRFS еще нет и даже не планируется...

> И дефрага там нет и не планируется, хотя CoW
> городит выноски-фрагменты by design.

Зачем дефраг на SSD накопителях?
ZFS - это 128-битная файловая система для будущего.

> И нормальное изъятие дисков из пула, с уменьшением - где?

В XFS кстати, тоже нет уменьшения раздела.
Неужели эта feature так сильно нужна на серверах?

> Не говоря о том что оно вообще не часть ядра
> и никогда таковой не будет - спасибо санкам за лицензию.

Oracle - владелец исходных текстов и вполне мог бы
перелицензировать при желании на GPL3 dual-license.
Но почему-то этого не делает. Наверное не хочет?

> Впрочем это к лучшему - btrfs передизайнили с учетом многих
> иных идей и имхо получилось достаточно интересно. Скажем мысль про RAID
> с пофайловой гранулярностью - мне кажется весьма перспективной.

А в ZFS сейчас разве не так?

Кстати, Object-level RAID 0, RAID 1, and RAID 10 в BTRFS
- это только планируют реализовать когда-то еще в будущем.

> На мой вкус - круто придумано. Интегрировать RAID с ФС?

Так это в ZFS и придумано было. И не только придумано, но и реализовано.

> Тогда логично этим пользоваться по полной, а не просто сделать
> очередной копипаст "в соляре не было менеджера томов - запихали его в ФС".

Этот менеджер томов можно использовать отдельно от файловой системы ZFS,
разместив там например, Lustre или ext4 или все что может понадобиться:
https://github.com/pavel-odintsov/OpenVZ_ZFS

В общем, кроме лицензии BTRFS ничем существенно не отличается в лучшую сторону от ZFS.

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

56. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Anonimous on 11-Апр-15, 03:19 
> Кстати, с постепенным переходом на флеш CoW вообще перестанет быть проблемой.
>> Даже если оно мешается БД или какому там еще софту с своим журналированием.
> ZIL не мешает, а помогает делать запись более быстрой.

Ну справедливости ради с базами получается дабл-буффер, для них рекомендованно ZVOL'ы делать.

>> И нормальное изъятие дисков из пула, с уменьшением - где?

А действительно где? :) Ну вот взять мегафичу - Linux LVM - научили уже или как?
> В XFS кстати, тоже нет уменьшения раздела.
> Неужели эта feature так сильно нужна на серверах?

Ну оно бы не помешало ... но не всё так однозначно, как дочь морского офицера говорю :)

>> Не говоря о том что оно вообще не часть ядра
>> и никогда таковой не будет - спасибо санкам за лицензию.

Never say "Never"!(C)
ZFS в составе линукс ведра ооооочччень хотят амские милитаристы ... У конторы бюджет over 500 миллиардов в год - думай.

> Oracle - владелец исходных текстов и вполне мог бы перелицензировать при желании на GPL3 dual-license.
> Но почему-то этого не делает. Наверное не хочет?

Ждут когда предложат цену. Торгаши-с.


>> На мой вкус - круто придумано. Интегрировать RAID с ФС?
> Так это в ZFS и придумано было. И не только придумано, но и реализовано.

Алё! Это все было придумано в Digital Equipment (да во времена динозавров), когда санки выглядели как очередной богленос :)
И на Dec Alpha почти всё это уже было скучной рутиной.

Как то так(С)

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

65. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от Аноним (??) on 11-Апр-15, 14:58 
> Ну справедливости ради с базами получается дабл-буффер,

Не дабл буфер, а умножение работы по журналированию.

> для них рекомендованно ZVOL'ы делать.

Ораклом будет рекомендовано btrfs использовать судя по всему ;].

> ZFS в составе линукс ведра ооооочччень хотят амские милитаристы ... У конторы
> бюджет over 500 миллиардов в год - думай.

Хотеть они могут что угодно. Но в майнлайн это не возьмут. И если милитаристы с их бюджетом еще как-нибудь заплатят за поддержку "внебрачного" ядра с левыми модулями, на которое в майнлайне смотрят волком, то вот насколько это готовы делать вы - совершенно отдельный вопрос.

> Ждут когда предложат цену. Торгаши-с.

Ну так они для своих баз в перспективе btrfs видят. А от саней им было надо клиентов, а вовсе не.

> И на Dec Alpha почти всё это уже было скучной рутиной.

А у них был пообъектный выбор уровней RAID?

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

94. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от АнонимныйСисадминАлкоголик on 22-Апр-15, 01:17 
> А у них был пообъектный выбор уровней RAID?

Вот на мой взгляд, это суровейшая антифича. Кому вообще в здравом уме может захотеться обслуживать такой бардак?
Кому нужно разный уровень резервирования для разных данных, те положат их на разные тома, каждый из которых находится на правильном raid'е (да, в zfs так нельзя). Но отдельный уровень рэида для каждого объекта фс? Да мой пах раньше поседеет, чем это начнёт работать стабильно. Про кейсы, когда это правда полезно я вообще молчу.

Короче, это из серии рекламной компании про 64-битные процессоры. Рекламируют фичу, которая _сама_по_себе_ пользы не приносит ни грамма.

И ещё хочется выматериться про отключение COW для объектов ФС. Это что, прощай мгновенные снапшоты? Или привет, потеря данных?
Зачем это вообще нужно? Чтобы было прикольно ходить по граблям?
ИМХО, фс должна работать однородно и предсказуемо. То, что написано выше про btrfs - пример как раз обратного.
ZFS может и не такая "фичастая", но так и должно быть. Это ФС, которая эффективна для ряда задач. Она не нужна везде и не стремится решать все проблемы.
Там есть COW, который гарантирует, что при исправном оборудовании ФС всегда будет находиться в консистентном состоянии. Там есть масса других технологий, которые позволяют эффективно и надёжно хранить данные.
А btrfs, как мне видится она, это такая попытка "стать всем", "фс будущего", но без идеи за спиной. Просто склеенные в одно большое нечто "фичи", которые только звучат круто, а по своей сути либо взаимопротиворечивы (cow/не cow) или просто бессмысленны или вредны (разные уровни RAID).

Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

95. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от csdoc (ok) on 22-Апр-15, 01:38 
> И ещё хочется выматериться про отключение COW для объектов ФС.
> Это что, прощай мгновенные снапшоты? Или привет, потеря данных?
> Зачем это вообще нужно? Чтобы было прикольно ходить по граблям?

Просто будет два способа записи данных в файл: CoW и не-CoW.
Вот в ext4 добавляют возможность пофайлово включать/выключать шифрование.

Код файловой системы усложняется, и больше времени надо потратить на отладку,
но может быть через какое-то время BTRFS и станет стабильной файловой системой.

В OpenZFS не смотря на ее почтенный возраст до сих пор полно проблем и глюков:
https://github.com/zfsonlinux/zfs/issues - да и для версии 0.6.4 список
исправленных ошибок тоже очень внушительный. Не очень-то она и надежная.

> А btrfs, как мне видится она, это такая попытка "стать всем", "фс
> будущего", но без идеи за спиной. Просто склеенные в одно большое
> нечто "фичи", которые только звучат круто, а по своей сути либо
> взаимопротиворечивы (cow/не cow) или просто бессмысленны
> или вредны (разные уровни RAID).

То же самое можно сказать и про Linux kernel - Linux является "всем",
как ядром для top500 суперкомпьютеров так и для мелких смартфонов,
носимых в кармане, включая также и десктопные компьютеры и сервера и кластера
и все что угодно. вот, даже роутеры делают на базе линукса - Mikrotik и т.п.

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

97. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 22-Апр-15, 04:35 
> но может быть через какое-то время BTRFS и станет стабильной файловой системой.

Не скажу за RAID5/6, а остальное вполне работает уже сейчас.

> В OpenZFS не смотря на ее почтенный возраст до сих пор полно проблем и глюков:

Внезапно, в любой достаточно большой программе есть достаточное количество багов. И никакой маркетинговый булшит от санок не может это изменить.

> То же самое можно сказать и про Linux kernel - Linux является "всем",

За что его и ценят. Reuse знаний - в самых разных ситуациях.

> и все что угодно. вот, даже роутеры делают на базе линукса - Mikrotik и т.п.

Если уж мы о софтороутерах, нынче ткни в каждый первый домашний роутер или точку доступа на полке магазина - и там с вероятностью 99% окажется пингвин.

Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

98. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от csdoc (ok) on 22-Апр-15, 04:57 
>> но может быть через какое-то время BTRFS и станет стабильной файловой системой.
> Не скажу за RAID5/6, а остальное вполне работает уже сейчас.

Работает, но пока что на уровне Technology Preview, не для production:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...

Даже Docker, который вроде бы считается уже стабильным - в Red Hat
не рекомендуют для использования в mission critical сервисах.
И как оказалось - совсем не зря, сравнительно недавно
там было найдено большое количество уязвимостей и глюков.

>> В OpenZFS не смотря на ее почтенный возраст до сих пор полно проблем и глюков:
> Внезапно, в любой достаточно большой программе есть достаточное количество багов.

То есть, по качеству кода Linux == Windows, или как это утверждение надо понимать?

> И никакой маркетинговый булшит от санок не может это изменить.

Из леса выходит обросший, одичавший партизан.
- Эй, бабка! Немцы в деревне есть?
- Да ты что, милок? Война уж 20 лет как кончилась!
- Иди ты?! А я все поезда под откос пускаю.

>> То же самое можно сказать и про Linux kernel - Linux является "всем",
> За что его и ценят. Reuse знаний - в самых разных ситуациях.

Не только и не столько за это. Каждый находит что-то свое,
и наиболее подходящий под свои задачи дистрибутив линукса.

>> и все что угодно. вот, даже роутеры делают на базе линукса - Mikrotik и т.п.
> Если уж мы о софтороутерах, нынче ткни в каждый первый домашний роутер
> или точку доступа на полке магазина - и там с вероятностью
> 99% окажется пингвин.

В результате:

http://www.opennet.dev/opennews/art.shtml?num=20918

http://www.securitylab.ru/news/438786.php

Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

96. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 22-Апр-15, 04:27 
> Вот на мой взгляд, это суровейшая антифича. Кому вообще в здравом уме
> может захотеться обслуживать такой бардак?

Файловой системе. Для админов все просто и логично - файлуха делает ровно то что надо здесь и сейчас. Так как это надо здесь и сейчас. Если текущее комбо девайсов на это вообще способно. Для админа как раз все бует просто и прозрачно - прикидываем "ценность" vs "затраты на хранение" и выбираем схему для тех или иных файлов или иерархий (субволумов). Это как раз предельно логичный подход. Позволяющий хранить и видео с корп. пьянки и рабочие документы на одном хранилище. Но не переплачивая за резервирование того что юзеры перезалить могут и не возясь с новыми хранилищами.

> Кому нужно разный уровень резервирования для разных данных, те положат их на
> разные тома, каждый из которых находится на правильном raid'е

Вот была охота разводить лишние хранилища, одни под корп. пьянки, другие под рабочие документы. Вот как раз таким админстративным практикам место на свалке истории.

В btrfs если захочется более четкое разделение - ну сделать 2 субволума, один "корп. пьянки" а второй "рабочие доки" например. Субволум - иерархия. Все что в нем будет по дефолту настроки иерархии использовать. Но вот если оказалось что 1-2 файлам надо оверрайднуть - кантовать эти файлы постоянно по иерархии выходом не является. Ну мало ли, допустим, пару лучших фото решили вывесить на сайт, в разделе "о компании", так что теперь проя..ывать конкретно вот эти 2 файла из 100 000 - более не хочется.

> (да, в zfs так нельзя). Но отдельный уровень рэида для каждого объекта фс?

Это самое логичное и ненапряжное в администрировании что можно придумать.

> Да мой пах раньше поседеет, чем это начнёт работать стабильно.

Де факто оно уже живет со смесями разных уровней RAID, когда на ходу конвертирует схему хранения. Вопрос в основном в реализации настроек и принятия решений о размещении и некоторой доделки. А так механика внутри себя к всему этому готова. Оно сразу с таким замахом сделано. Хороший архитект низко не летает.

> _сама_по_себе_ пользы не приносит ни грамма.

Приносит. Кроме всего прочего, есть минимум 2 пользы от 64 битов самих по себе:
1) Возможность ненапряжной адресации регионов более 2^32 == 4GiB без феерических костылей.
2) Возможность работы с 64 битной математикой во всех элементарных операциях. Там где раньше получалась этажерка поразрядной математики и жуткая гажка кучи регистров, вынуждающая лишний раз делать push/pop, теперь ОДНА ЛОБОВАЯ КОМАНДА. Учитывая что нынче даже просто адресация накопителей, файлов и прочая в 32 бита не укладывается...

А еще широкие регистры можно использовать как кучу узких, обмолачивая за 1 такт кучу простых операций. Доразвитие идеи называется SIMD, и там бывают регистры и на 128 и даже на 256 битов, что дает за раз скрушить допустим "RGBA" четверку компонентов пиксела, XYZW компоненты вектора в 3D и прочая. В результате производительность в 3D, операциях типа декодирования видео или постпроцессинга оказывается более другая. Порой отличия чуть ли не в разы.

> И ещё хочется выматериться про отключение COW для объектов ФС. Это что,
> прощай мгновенные снапшоты?

Только для конкретных, "known bad" объектов. Мгновенный снапшот БД, фигарящей по ACID семантике - штука очень ограниченной полезности, чреватая уймой грабель.

> Или привет, потеря данных?

У БД и CoW дисков виртуалок бывают свои понятия о версионировании, CoW, журналах и прочем.

Кроме того, снапшот - не есть предотвращение потерь данных. Выбивание блоков под снапшотом - разрушает всю цепочку снапшотов, референсившися на эти блоки. Поэтому снапшоты мягко говоря не замена резервных копий. Это зафиксированный во времени слепок состояния ФС. И отматывать таким манером БД может быть довольно чревато, поскольку ФС вообще понятия не имеет ни о том какому клиенту БД сказала что транзакция прошла, ни о том когда база консистентна, ни о том как базе после "жесткого" рестора в "абы какое" состояние форсануть валидацию/реплей журнала/....

> Зачем это вообще нужно? Чтобы было прикольно ходить по граблям?

В *никсах всегда можно было простреливать себе пятки, если это хочется сделать. Кто хочет безопасную песочницу где воспитатель отбирает даже водяной пистолетик - ему не к нам.

Дла упомянутых вещей админ должен предпринять явные действия. Если он хочет прострелить свои пятки - это не запрещено. Но придется захотеть это явно и снять пистолет с предохранителя.

> ИМХО, фс должна работать однородно и предсказуемо.

Она и будет работать однородно и предсказуемо - "так как надо здесь и сейчас". Без всего этого задолбавшего "на охоту ехать - собак кормить" в виде паразитных многочасовых конверсий уровней и пересборок огромных хранилищ, которые останутся в каменном веке отрасли.

> ZFS может и не такая "фичастая", но так и должно быть.

ZFS - выбор мамонтов, привыкших к горбатому управлению сторажами. Btrfs - для тех кто предпочтет привыкать к хорошему и делать так как удобно и логично, а не так как диктуют дурные ограничния конфигурации и ломовые затраты времени и сил на переконфигурирование.

> Это ФС, которая эффективна для ряда задач.

Единственное место где она годится - файлопомойки. И там ее ждут сюрпризы, из-за неумения назначать разную ценность разным файлам ни в какой разумной перспективе. А админить кучу разных сторажей лишь потому что "zfs не умеет разные схемы хранения для разных файлов" - удовольствие так себе, имхо. В этом плане у btrfs много интересных возможностей на перспективу.

> не стремится решать все проблемы.

Поэтому всякие бсдшники и солярщики кроме ZFS сидят с всяким шитом типа UFS, которому место на свалке истории.

> Там есть COW, который гарантирует, что при исправном оборудовании ФС всегда будет
> находиться в консистентном состоянии.

А еще он гарантирует истошные тормоза и оверхед при работе с CoW дисками виртуалок и БД, при том оракл с его БД очень хорошо в курсе всей этой фигни, по поводу чего видимо и спускает развитие ZFS на тормозах. Не забывая однако ж коммитить в btrfs кучкой своих сотрудников даже после ухода Мэйсона.

> А btrfs, как мне видится она, это такая попытка "стать всем", "фс
> будущего", но без идеи за спиной.

Там одна идея - стать именно тем что надо админу здесь и сейчас. А не клубком технических ограничений, оверхеда и длительных и интрузивных операций. Это стораж сделанный так как следовало это делать с самого начала, если не срезать углы и не халтурить, перенося проблемы програмеров на плечи админов и пользователей.

> взаимопротиворечивы (cow/не cow)

Там нет никакого противоречия. Есть настраиваемость. Только и всего.

> или просто бессмысленны или вредны (разные уровни RAID).

Вот лично мне это будет очень полезно. А вы можете и дальше колхозить кучи сторажей по причине "невозможно сконфигурировать разные области по разному", наслаждаться многочасовыми интрузивными операции конверсии уровней райдов вместо плавной/пообъектной миграции в периоды наименьших нагрузок и прочая.

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

57. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от maximnik0 on 11-Апр-15, 06:17 
> В XFS кстати, тоже нет уменьшения раздела.
> Неужели эта feature так сильно нужна на серверах?

Отмонтированный XFS можно было  уменьшить сторонними средствами ,правда про RAID не знаю .С LVM -тоже можно было уменьшать ,но там целое шаманство - и с новой версией XFS незнаю ,совместимо ли,потому что формат то поменялся ,а в руководстве говорилось  про : вручную блоки считать и смещения  .

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

63. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 11-Апр-15, 14:17 
> Facebook will trial Btrfs in its "web tier" servers,
> explaining that's the easiest tier to recover if necessary

Вообще-то уже давно запилили. И Мэйсон радовался тому что в процессе попались несколько контроллеров, выдававших протухшие или недостоверные данные.

> - если упал какой-то сервер, его просто вытащили из кластера и заменили другим.

А это вообще нормальный подход к построению больших отказоустойчивых структур.

> Базы данных и другую критически важную информацию на BTRFS еще никто не хранит.

Ну насчет "никто" так громко расписываться - а вы обошли всю планету и проверили? Понятно что лишнее тестирование до ответственных применений еще никому не вредило.

> вопрос был про ответственные и слишком ответственные применения.

А в ответственных - вы вообще готовы отвечать за какой-то левый побочный модуль ядра своей головой? Там поди еще и кернель потом будет tainted или около того, из-за лицензии модуля. Так что если будут какие-то проблемы - в майнлайне или где там еще могут просто послать в пешее эротическое: отвечать за глюки левого модуля никому не хочется.

> ZFS судя по всему, там использовать уже можно, а вот BTRFS - еще нет.

Судя по... чему? Если так навскидку, я как-то не особо хочу отвечать за ядро с левыми посторонними модулями. За лажу в майнлайновых - можно причастных в майнлайне пинать. А с таким ядром - в майнлайне могут потом послать. А творцы стороннего модуля врядли готовы поддерживать все кернелы с этим модулем на уровне майнлайновых разработчиков.

> RAID5? Это они зря, http://www.zdnet.com/article/why-raid-5-stops-working-in-2009/

Там есть несколько алгоритмов, на выбор. И возможность конверсии уровней на ходу. Если у кого всего 3-4 девайса - RAID5 будет оптимальнее по емкости чем зеркало и лучше по надежности чем отсутствие raid вообще. А если девайсов станет больше - можно потом и в raid6 переделать, например. Все это - на ходу, без остановки работы.

> RAID6 ситуация не лучше: http://www.zdnet.com/article/why-raid-6-stops-working-in-2019/

Авторитетный микрософтовский ресурс Зад Нет, вещающий про сферических коней в 2019 - это, конечно, круто. Но если что - btrfs на самом деле не очень принципиально, будет надо (==будет спрос) - прикрутят еще какую-нибудь схему аллокации. И перейти на нее можно будет на ходу.

> А BTRFS разве может? Это ведь точно такая же CoW файловая система.

Может. Пофайлово аж. Оракл был явно в курсе что CoW базам данных не друг, потому что идея журналить журнал и т.п. - дрянь. Поэтому видимо попросили (тогда еще своего) архитекта это учесть. И это было учтено. Так что обладатели всяких там БД имеющих свои понятия о журналировании/версионировании и виртуалок, имеющих свои понятия о CoW и снапшотах в своих виртуальных дисках - могут отключить CoW если он мешается.

> Кстати, с постепенным переходом на флеш CoW вообще перестанет быть проблемой.

Не перестанет. Если база пишет в журнал, а вы его CoW'аете, а потом еще и коммит в основную область отCoW'ать - получится жуткое месиво из фрагментов и метададанных, на SSD это конечно будет не так злобно тормозть. Но во первых ускорит протирание SSD ("write amplification" - на ровном месте), а во вторых - куча лишних операций и лопатинг кучи метаданных - медленнее при прочих равных.

Механика БД и дисков виртуалок подразумевает что файлуха просто патчит файл in place и на этом строятся все допущения о том как это будет работать. Эта механика плохо дружит с CoW, работая совместно работа умножится в несколько раз. Вот в этом случае CoW в btrfs можно отключить. Разумеется, при этом снапшоты и журналирование уже не совести такой программы. Но если программа хотела простую подложку, btrfs может стать таковой для вон тех файлов, если попросить.

> ZIL не мешает, а помогает делать запись более быстрой.

Я про механику в целом. ZIL - обычный костыль, при том саночники даже толком не могут сказать зачем они все это делали вот так и почему в целом получилось так наворочено, но при этом - довольно бестолково по параметрам. Мышление Мэйсона я еще более-менее могу понять - там хоть и встречаются костыли, но хоть какая-то логика прослеживается. И целеполагание далеко за пределы того во что целились саночники.

Намек был на то что если механика работы с файлом подразумевала простую не журналящую ФС, то CoW при этом может в целом оказать медвежью услугу.

> У BTRFS есть аналогичная feature, только тут она не вынесена на отдельный SSD,
> так что толку от нее будет не много: https://en.wikipedia.org/wiki/Btrfs#Log_tree

У btrfs есть возможность дать то чего база хотела: тонкую прослойку без журналирования между базой и диском. При этом CoW данных для такого файла будет выключен, ФС станет тонкой подложкой позволяющей in-place патчи. Снапшоты для такого файла разумеется не будут работать. Но мысль откатывать базу путем отката снапшота ФС - сцыкотная, ведь ФС вообще ничего не знает про консистентность базы и ее администрирование. А гордость про то что в случае ZFS можно как-то изъ...ться и все-таки закрутить гвоздь любимой отверткой... ну с этим не ко мне. Я то вижу что там уместнее молоток. Вот у Криса Мэйсона в ящике с инструментом есть и это. А у саней - только маркетинговый булшит и сказки про то как вбить адовы костыли.

> Как и L2ARC - аналогичной возможности у BTRFS еще нет и даже не планируется...

В линухе есть уже чуть не полдюжины решений для кэширования на ssd. Насколько это надо именно в ФС а не блочном уровне... ну если RAID на уровне ФС может дать выставление ПОФАЙЛОВЫХ уровней избыточности, возможность при восстановлении сверять чексум и делать вывод какая копия верна, etc, а для всего этого ФС должна и рулить девайсами и свободным местом на них, так что менеджмент томов и райд смотрятся логично, то вот что дает вынос кэша на уровень ФС из блочного уровня - мне сходу не очень очевидно, если честно. Что дает awareness файлухи о всем этом, чтобы это считалось достоинством? Может потому и не спешат?

> Зачем дефраг на SSD накопителях?

На SSD в нем меньше смысла. Но нужда разбирать 100500 выносков по разным закоулкам может создать оверхед и там. Если уж мы о них - в ZFS нормальных экстентов нет. И то что btrfs вфигачит одним экстентом, ZFS будет оформлять кучей операций с блоками. Нафига оно вот так - саночники тоже рассказать не могут. Блоки переменного размера - не проще в реализаци чем нормальные экстенты, но менее эффективны по оверхеду, ибо весь смысл экстента в том чтобы оформить за один присест достаточно большой регион. Санки образцовые корпорасы: сделали сложно и с неважными эксплуатационными параметрами - одновременно.

> ZFS - это 128-битная файловая система для будущего.

Будущего, ага. Без нормальных экстентов, с кучей костылей, невозможностью вынуть диск из пула и убавить пул, где нельзя отключить CoW, намного менее гибкая чем btrfs в вопросах размещения данных и без перспектив выбора схемы хранения ("уровня RAID") на ходу, etc.

Санки - истинные корпорасы. Поэтому они заткнули кучу технических проблем громким маркетинговым булшитом. А в линухе нам вот нет никаких причин себя обманывать: btrfs же не соляра, делается для себя, а не на продажу в чистом виде.

В общем поменьше обращайте внимание на маркетинговый булшит и побольше - на то что и как фактически устроено и нафига оно вот так. Или вам нравится снимать маркетинговую лапшу с ушей?

> В XFS кстати, тоже нет уменьшения раздела.

"А в америке негров линчуют" - IT Edition :)

> Неужели эта feature так сильно нужна на серверах?

Гибкость в управлении storage space - визитная карточка btrfs. Вплоть до того что btrfs может оформить ext4 который был до него как свой первый снапшот, пристроившись "вокруг" ext4. А вот то что ФС должна создавать админу головняк дурными ограничениями на ровном месте для меня - не факт. Вот btrfs был сделан таким, чтобы учесть большинство неприятных и сложных моментов системного администрирования и сделать так чтобы ФС помогала, а не мешалась. Мне это весьма симпатично. А кто и по какому поводу добавляет и удаляет диски из пула - это его дело! И не дело ФС строить админа как ему там должно быть удобно. Вот у btrfs это буквально так: добавили диск, +N свободного места. Убрали диск, -N свободного места. Я нахожу такую схему управления девайсами логиной.

> Oracle - владелец исходных текстов и вполне мог бы
> перелицензировать при желании на GPL3 dual-license.

Насколько все это надо ораклу - оракл продемонстрировал. Путем запиливания btrfs :). Где сразу, еще на фазе проектирования и ранней реализации учтены неудобства CoW для БД и он сделан отключаемым. Я думаю что Oracle не требуется ZFS - настоящий next gen был запилен в виде btrfs.

> Но почему-то этого не делает. Наверное не хочет?

А оно им зачем? Btrfs появился как-то так: около 2007, IBM, Oracle и прочие - провели некое совместное совещание и решили что им всем нужна next-gen файловая система, которая вберет в себя лучшие черты существующих. Мэйсон посмотрел на то что уже существовало и на проблемы которые у всего этого были. И постарался надергать лучшее из сушествовавших дизайнов (включая ZFS), оставив за бортом недостатки. Я склонен считать что это более-менее получилось (хоть и не идеально, разумеется).

Судя по тому что нынче и по сей день есть немало народа с @oracle.com которые коммитят в btrfs, а сам оракль сватает Unbreakable Linux - подозреваю что от саней было надо клиентуру, а не технологии. Ну не друг ZFS базам данных, как минимум без серьезной переделки. Оракл это понимает, в отличие от лохов накормленых санями маркетинговым булшитом. Они то в курсе что их базам удобнее (в идеале - raw раздел, но это ж админить неудобно).

>> с пофайловой гранулярностью - мне кажется весьма перспективной.
> А в ZFS сейчас разве не так?

Насколько я понял - там все более-менее обычно. ZFS такой какой он есть - потому что в соляре не было кэша, менеджера томов и чего там еще. Вот они и запилили все в ФС. А в лине все это уже было на момент создания btrfs. Что привело к тому что в btrfs если что-то делали у себя - то потому что это давало какие-то качественно новые возможности, а не просто "чтобы было".

Rampant layering violation в ZFS - потому что в соляре не было менеджера томов. А в btrfs - потому что так можно было просто и естественно сделать пофайловый RAID с возможностью конверсии в любой момент без остановки пула, на ходу. Немного разная мотивация, со всеми вытекающими :)

> Кстати, Object-level RAID 0, RAID 1, and RAID 10 в BTRFS
> - это только планируют реализовать когда-то еще в будущем.

Да. Но дизайн структур все это позволяет уже сейчас. А когда оно конвертирует из одного уровня в другой - у пула одновременно есть 2 разных схемы хранения и все это при этом работает. Что и позволяет переделать уровень RAID на ходу: btrfs нормально относится к тому что половина chunks в такой схеме, а половина в этакой. Процесс конверсии просто берет chunk в старой схеме и переводит в новую. Все это может работать в фоне и ФС ни разу не смущается разными наборами chunks в разных схемах. Даже штатно там для данных и метаданных могут быть разные схемы хранения. Скажем на однодсковом пуле - для метаданных схема "dup", т.е. укладывание 2 копий метаданных в 2 разных региона по соображениям надежности. А для данных - схема "нифига".

> Так это в ZFS и придумано было. И не только придумано, но и реализовано.

Только они это придумали потому что в соляре не было менеджера томов. А в btrfs - потому что это дает новые возможности. Со всеми вытекающими отличиями.

> Этот менеджер томов можно использовать отдельно от файловой системы ZFS,

...что намекает на то, что это - тот самый менеджер томов, блочного уровня, которого не было в соляре. Всего лишь. А в линухе уже свой есть. Нафига еще один точно такой же надо? :)

А в btrfs RAID - интегрированная часть ФС, где за счет тесной интеграции ФС может пообъектно или как там еще выбирать схему хранения для конкретных файлов. Собственно из-за этого btrfs и имеет некоторые сложности с сообщением сколько осталось места. Ведь заранее неизвестно в какой схеме размещения будут новые файлы. Да и возможность размещения - зависит от девайсов и свободного места на них.

> разместив там например, Lustre или ext4 или все что может понадобиться:

У линуха уже есть LVM, нафиг ему еще и соляровый менеджмент томов сдался? Это функциональный дуп и по большому счету - лишний код. А в btrfs все это дает новые возможности - потому и не считается за дуп. Это не очередной менеджер томов, а пообъектный RAID в файлухе, интегрированная фича.

> В общем, кроме лицензии BTRFS ничем существенно не отличается в лучшую сторону от ZFS.

В общем, маркетинговый булшит маркетнговым булшитом, а продвинутые технологические решения свое возьмут, сколько их не поливай помоями. Потому что в линухе мы для начала заинтересованы в своем удобстве, а не в том чтобы всенепременно втюхать, как санки. Отсюда вытекают очень разные приоритеты. В технологиях и громкости битья себя пяткой в грудь.

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

72. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от csdoc (ok) on 11-Апр-15, 23:53 
>> ZFS судя по всему, там использовать уже можно, а вот BTRFS - еще нет.
> Судя по... чему?

Например,
http://www.phoronix.com/scan.php?page=news_item&px=CoreOS-Bt...
CoreOS Moves From Btrfs To EXT4 + OverlayFS

>> А BTRFS разве может? Это ведь точно такая же CoW файловая система.
> Может. Пофайлово аж. Оракл был явно в курсе что CoW базам данных
> не друг, потому что идея журналить журнал и т.п. - дрянь.

WAFL/CoW превращает рандомную запись в последовательную, уменьшая количество IOPS.
Если устройства хранения - HDD - для них это должно дать прирост производительности.

> Так что обладатели всяких там БД имеющих свои понятия
> о журналировании/версионировании и виртуалок, имеющих свои понятия
> о CoW и снапшотах в своих виртуальных дисках - могут отключить CoW если он мешается.

То есть, в BTRFS больше фич, значит BTRFS лучше за ZFS. Следуя такой логике, - Reiser4
будет еще лучше за BTRFS, потому что там можно писать свои плагины к файловой системе.
Подробнее об этом: http://habrahabr.ru/post/183230/ А в BRTFS нельзя. Тем более, что:

https://www.linux.org.ru/news/kernel/5041798
Эдуард Шишкин выступил с критикой Btrfs

>> ZIL не мешает, а помогает делать запись более быстрой.
> Я про механику в целом. ZIL - обычный костыль, при том саночники
> даже толком не могут сказать зачем они все это делали вот
> так и почему в целом получилось так наворочено, но при этом
> - довольно бестолково по параметрам.

Вроде бы все очевидно, зачем они это сделали. Да и объяснено уже не раз.

>> У BTRFS есть аналогичная feature, только тут она не вынесена на отдельный SSD,
>> так что толку от нее будет не много: https://en.wikipedia.org/wiki/Btrfs#Log_tree

Это точно такой же ZIL, только не вынесенный на отдельное блочное устройство.
Из-да чего этот Log_tree из BTRFS будет гораздо менее эффективным чем ZFS ZIL.

> Но мысль откатывать базу путем отката снапшота ФС - сцыкотная,
> ведь ФС вообще ничего не знает про консистентность базы и ее администрирование.

Для нормальных баз данных не должно быть проблемой создание снапшота файловой системы
в любой момент. Просто потому, что это будет эквивалентно резкому пропаданию 220V
в момент работы с базой данных.

Потом - база данных откатывает из лога транзакций незавершенные трензакции
и возвращается к полностью косистентному состоянию. В чем проблемы ? Не понимаю.

Тем более, что некоторые базы данных умеют FLUSH TABLES WITH READ LOCK
перед созданием снапшота и UNLOCK TABLES после создания оного - так еще лучше.
Подробности: https://www.lullabot.com/blog/article/mysql-backups-using-lv...

> там уместнее молоток. Вот у Криса Мэйсона в ящике с инструментом есть и это.

"Когда у тебя в руках молоток, все задачи кажутся гвоздями".

>> Как и L2ARC - аналогичной возможности у BTRFS еще нет и даже не планируется...
> В линухе есть уже чуть не полдюжины решений для кэширования на ssd.

Из нормальных - только LVM cache.

> Что дает awareness файлухи о всем этом, чтобы это считалось достоинством?

1) Проще и удобнее для пользователя сказать
# zpool add pool_0 cache c7t0d0 c7t1d0 c8t0d0 c8t1d0 c9t0d0 c9t1d0
в командной строке, чем играться с настройкой lvm cache.

2) ZFS умеет делать компрессию данных в L2ARC, увеличивая производительность кеша
http://wiki.illumos.org/display/illumos/L2ARC+Compression

3) запись в L2ARC происходит большими блоками, чтобы зря не изнашивать SSD

> Если уж мы о них - в ZFS нормальных экстентов нет.

и нет проблем с ними связанных. см. выше "Эдуард Шишкин выступил с критикой Btrfs".

> И то что btrfs вфигачит одним экстентом, ZFS будет оформлять кучей операций с блоками.

Каким образом BTRFS сделает CoW при этом? Будет копировать весь большой экстент?

> Нафига оно вот так - саночники тоже рассказать не могут.

Могут и рассказали: https://blogs.oracle.com/bonwick/entry/zfs_dedup

> Блоки переменного размера - не проще в реализаци чем нормальные экстенты, но менее
> эффективны по оверхеду, ибо весь смысл экстента в том чтобы оформить
> за один присест достаточно большой регион.

см. выше "Эдуард Шишкин выступил с критикой Btrfs".

>> ZFS - это 128-битная файловая система для будущего.
> Будущего, ага. Без нормальных экстентов, с кучей костылей

про какие костыли идет разговор?

> где нельзя отключить CoW

Если нужна файловая система без CoW - проще будет именно ее и взять, например, XFS.

>> В XFS кстати, тоже нет уменьшения раздела.
> "А в америке негров линчуют" - IT Edition :)

Нет, это просто к тому, насколько сильно такая фича кому-либо нужна.

> Гибкость в управлении storage space - визитная карточка btrfs.

Как и глюки, которые приводят к повреждению файловой системы.

> А вот то что ФС должна создавать админу головняк дурными ограничениями
> на ровном месте для меня - не факт.

Но ведь будет создавать, потому что для использования BTRFS на HDD + SSD для кеша
надо будет кроме BTRFS использовать еще и LVM и LVM Cache - приятного в этом мало.

> Они то в курсе что их базам удобнее
> (в идеале - raw раздел, но это ж админить неудобно).

Для BTRFS + LVM Cache приходится ведь использовать raw разделы и ничего, нормально.

> Rampant layering violation в ZFS

https://blogs.oracle.com/bonwick/en/entry/rampant_layering_v...
Rampant Layering Violation?

>> Так это в ZFS и придумано было. И не только придумано, но и реализовано.
> Только они это придумали потому что в соляре не было менеджера томов

Solaris Volume Manager

> У линуха уже есть LVM, нафиг ему еще и соляровый менеджмент томов сдался?

В таком случае - придется делить диск между LVM и BTRFS,
в том числе и размещая BTRFS на LVM разделах, что не добавит
ни производительности ни простоты/удобства работы с дисковой подсистемой.

> В общем, маркетинговый булшит маркетнговым булшитом

"маркетинг" - это вроде бы от слова "продажи".

а какие могут быть продажи, если OpenZFS - это open source софт?

> чтобы всенепременно втюхать, как санки

Какие санки? Новость вообще-то про http://en.wikipedia.org/wiki/OpenZFS

Подробнее про линуксовый вариант: http://zfsonlinux.org/faq.html

Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

76. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от Аноним (??) on 12-Апр-15, 03:05 
> CoreOS Moves From Btrfs To EXT4 + OverlayFS

Оно как бы да, но эти хипстеры - весьма узконишевая штука и никакой особой погоды на рынке не делают, как минимум пока. А тот факт что их устраивает overlayfs вместо btrfs - прозрачно намекает что они фичами btrfs пользовались процентов этак на 5. С другой стороны, Мэйсон на предъявы ответил, вкоммитив в 3.19 порцию фиксов, которые как раз и чинят большинство из упомянутых проблем.

> WAFL/CoW превращает рандомную запись в последовательную, уменьшая количество IOPS.

Да. И кроме того, у CoW как такового запись быстрая, почти со скоротью нежурналируемой ФС, при свойствах эквивалентных полному журналу. Собственно поэтому им столько внимания и уделяют в новых дизайнах.

Но за это воздается. Как вы понимаете, при рандомной ПЕРЕзаписи файл будет нещадно фрагментирован, плюс метаданных может стать довольно много. И если для обычной ФС операция перезаписи в середине файлов простая, дешевая и не ведет к проблемам по части метаданных, если файл например преаллоцирован, то для CoW это отдельные грабли - на каждую запись надо метаданные и выноски. Поэтому БД не особо дружат с CoW.

Бонусом скорость линейного чтения например - уйдет в плинтус из-за кучи фрагментов (оверхед по метаданным + для механических винчей еще постоянный seek).

> Если устройства хранения - HDD - для них это должно дать прирост
> производительности.

Зато когда наступит момент эти данные читать, нас будут ждать неприятные сюрпризы.

> То есть, в BTRFS больше фич, значит BTRFS лучше за ZFS. Следуя
> такой логике, - Reiser4 будет еще лучше за BTRFS, потому что там можно
> писать свои плагины к файловой системе.

Задумано оно может и неплохо, но из разработчиков там аж целый 1 Шишкин, что как-то не дофига. А если поделить объем работ на объем работничков - слушайте, мой высохший скелет как-нибудь обойдется без файловой системы. Нафиг мне файловая система через пару столетий?

Кроме того плагины это здорово, но некоторые фичи получаются намного лучше когда это интегральные части core-дизайна. Ну как CoW или пообъектный RAID. Плагином такое сложно сделать без перепиливания половины core, с утерей совместимости по дисковым структурам. Не те вещи которые можно донавесить на соплях, сбоку.

> Подробнее об этом: http://habrahabr.ru/post/183230/ А в BRTFS нельзя.

В архитектуре софта главное - знать меру и вовремя остановиться. Вот с этим у Reiser4 не задалось.

> Эдуард Шишкин выступил с критикой Btrfs

Эдуард Шишкин взял какой-то ушибленный юзкейс в виде ФС на 600 мегов и кучей мелких файлов, не вдавался как btrfs устроен и получил ... ну то что получил. А на более реалистичных сценариях соотношения более другие. Да и кое-что из критики оптимизнули. Если на то пошло - любую ФС можно забить файлами нулевого размера до состояния когда вроде своболное место ни на что не потрачено, но новый файл создать почему-то нельзя. У одних кончится место из-за метаданных, у других и вовсе ограниченное количество inodes.

На мое нескромное мнение, Шишкин лучше бы в своем болоте разбирался - там проблем намного больше, как то полное отсутствие разработчиков при огромном объеме работ. В btrfs коммитит толпа народа, по поводу чего он уже более-менее достиг юзабельного состояния. А у Шишкина крЮтой PoC и половинка землекопа - на все работы. Так что я просто не доживу до того как оно станет пригодно к использованию.

> Вроде бы все очевидно, зачем они это сделали. Да и объяснено уже не раз.

Ни разу не видел нормального объяснения зачем блоки переменного размера сделаны так горбато и почему нельзя было нормальные экстенты сделать.

> Это точно такой же ZIL, только не вынесенный на отдельное блочное устройство.

И то и другое - по большому счету костыли CoW под некие частные случаи в которых чистый CoW как оказалось работает медленно.

> Из-да чего этот Log_tree из BTRFS будет гораздо менее эффективным чем ZFS ZIL.

Что является проблемой только если ворклоад уперся в этот закоулок, что является проблемой только для сильно некоторых вещей.

А в случае с БД с nodatacow, btrfs вообще не будет журналить данные, раз БД или СoW-диск виртуалки сами с усами.

> Для нормальных баз данных не должно быть проблемой создание снапшота файловой системы
> в любой момент. Просто потому, что это будет эквивалентно резкому пропаданию 220V
> в момент работы с базой данных.

Не совсем. При пропадании 220V - процесс с БД будет перезапущен при старте системы или когда там оно надо, после чего БД делая стартовые проверки - заметит неконсистентность и прочая. Но при откате снапшота ФС - процессы базы по дефолту никто не перезапускает и что там получится - да Ктулху его знает. Вот вы на своих продакшеновых базах и проверяйте, если у вас стальные яйца.

> Потом - база данных откатывает из лога транзакций незавершенные трензакции
> и возвращается к полностью косистентному состоянию. В чем проблемы ? Не понимаю.

Например, в том что откат снапшота не обязывает случиться рестарт процессов. Базы не проверяют в деталях консистентность и не делают реплей журнала ПОСТОЯННО. То-есть это как минимум требует сложных кастомных автоматизаций, с шатдауном и рестартом процесов после того как база ВНЕЗАПНО стала совсем другой.

И это подразумевает готовность к массовой потере всей информации, что накрывает семантику ACID медным тазом. Вы только что сказали клиенту что все оки-доки. И .. снесли его транзакцию откатом снапшота?! Зашибись. А дальше что?

> перед созданием снапшота и UNLOCK TABLES после создания оного - так еще лучше.

Все становится намного интереснее, если мы подумаем о том что случится при откате снапшота и насколько это вообще логически корректно и какие допущения при этом отвалятся.

Нет, с какими-то оговорками это можно, но с учетом всех возможных проблем + нагрузки по метаданным/фрагментам это выглядит крайне дурной и очень граблеопасной затеей.

> "Когда у тебя в руках молоток, все задачи кажутся гвоздями".

Что однако не является поводом немедленно отбить себе все пальцы :)

> Из нормальных - только LVM cache.

Нельзя ли определение нормальности в студию?

> 1) Проще и удобнее для пользователя сказать
> # zpool add pool_0 cache c7t0d0 c7t1d0 c8t0d0 c8t1d0 c9t0d0 c9t1d0
> в командной строке, чем играться с настройкой lvm cache.

Честно говоря - не вижу чем эта команда такая уж прямо замечательная vs все остальное. В любом случае это вкусовщина. У саней оно вот так просто потому что у них как я понимаю системных кэшей вообще не было. Ну вот и вперли все чего не хватало в соляре в ZFS. В каком-нибудь линухе это было в системе и половина фич ZFS там просто на..й не уперлась.

> 2) ZFS умеет делать компрессию данных в L2ARC, увеличивая производительность кеша

Ну ок, конкретно вот это - неплохо придумано. Но ниоткуда не следует что это должно быть частью ФС.

> 3) запись в L2ARC происходит большими блоками, чтобы зря не изнашивать SSD

Тоже неплохо. С другой стороны все это по идее должно быть tunables. Мало ли какие там где носители и какие они будут в будущем.

>> Если уж мы о них - в ZFS нормальных экстентов нет.
> и нет проблем с ними связанных. см. выше "Эдуард Шишкин выступил с критикой Btrfs".

Зато есть другие. Экстенты используют потому что в типичных юзкейсах они ведут себя лучше чем другие решения. А то что какй-то Шишкин начнет изгаляться над 600Мб обрубком - btrfs малость не для этого делалась. По поводу чего ценность изысканий Шишкина актуальна для утонченных извращенцев. Вы впрочем в вашем праве разложить ZFS на 600Мб том и попробовать там поизвращаться а-ля Шишкин.

При сильном желании btrfs можно и на штуки типа sd-карты разложить, но там лучше использовать специфичные настройки (которые есть, как минимум - mixed block groups). По дефолту btrfs откусывает пространство накопителя довольно большими chunks, а chunk по дефолту приписан к конкретному варианту использования, т.е. для хранения данных. Или метаданных. На носителях малого объема где умещается всего несколько chunks - может выйти дисбаланс (в плане того что например невозможно записать данные, хотя свободное место как бы есть, но - в chunk для метаданных). Все это актуально для мелких носителей менее чем десяток-другой гигз размером, в более-менее типовых случаях все будет и по дефолту.

> Каким образом BTRFS сделает CoW при этом? Будет копировать весь большой экстент?

YOLO! Вы не поняли как CoW в ФСах обычно работает :).

CoW в ФС в общем виде делается как-то так: вы пишете изменение, допустим в середину файла. Классическая ФС записала бы это в середину файла (in place patching) и все этим закончилось бы. А CoW ФС выносит выносок с новыми данными куда-то вбок, в область свободного места. Старое содержимое файла - остается неизменным. Метаданные апдейтятся, чтобы текущая версия файла - строилась с заменой измененого куска на этот ваш новый выносок. В результате можно доступаться как к старому варианту файла, так и к новому - вопрос в интерпретации метаданных. Если взять старый вариант метаданных - можно получить старый файл. А новые метаданне = новый вариант файла. Btrfs делает CoW в том числе и для метаданных, что позволяет ему довольно легко проделывать такие фокусы.

Потом GC может при желании убить старый блок в середине файла, если старый вариант файла не требуется, освободив место в ФС (бесконечное хранение всех версий разумеется постепенно стрескает все место на стораже).

Как видите, копирование как таковое - не случается :). Точнее назвать это "неразрушающей записью". Но название устоялось, т.к. в некоторых реализациях таких алгоритмов запись идет in place, а копирование - старых данных, чтобы сохранить старый вариант. Но чаще оптимальнее если "копией" станет новый выносок, с новыми/измененными данными. А название вот осталось, потому что оптимизированный вариант той же идеи.

По этому поводу - CoW может делать снапшоты круто и быстро: для снапшота все уже есть на уровне дизайна. Остается только некую формальную пометку поставить, запрещающую GC чистить это - и снапшот готов. Фирменный caveat CoW: если безбашенно фигарить снапшоты, на стораже однажды кончится место, хотя суммарный объем файлов далек от объема стоража. Место уйдет на хранение "отличий от снапшота". По этому поводу снапшоты стоит переделывать/подтирать старые.

Вообще, есть ряд выводков технологий которые очень похожи и по сути разновидность одной идеи. Как несложно заметить, то что делает CoW можно рассмотреть как "бесконечный журнал", занимающий весь стораж (области данных просто нет). А реплей журнала до энного состояния - дает энное состояние файла. Новое состояние - строится дозаписью журнала. Commit в область данных отсутствует, откуда и профит в скорости записи: двукратной записи - нет, а журнал - есть. По этому поводу можно повстречать "log-structured" ФС/БД/чтотамеще.

А поскольку такие технологии имеют потенциал для хранения нескольких версий файла (записи БД, ...) - можно повстречать это и под названием "версионник".

Реально у тех или иных вариантов могут быть те или иные детали реализации, но общий смысл всех вариантов такой что при записи возникает как старая версия, а запись не разрушает (сразу) старое состояние и оно останется доступно (некоторое время).

> Могут и рассказали: https://blogs.oracle.com/bonwick/entry/zfs_dedup

Ога, тут весь форум забит радостями от аппетитов дедупа :)

> см. выше "Эдуард Шишкин выступил с критикой Btrfs".

Пусть он имхо лучше свою ФС до ума доводит чем страдает извращениями с 600Мб томом btrfs. Если кто еще не понял - положить на лопатки извращениями с краевыми условиями можно вообще любую ФС. Поэтому ценность изысканий Шишкина невелика: вопрос то скорее в том как ФС работает в более-менее обычных, часто встречающихся задачах, а btrfs на мизерном томе - это скорее экзотика. Btrfs достаточно нормально работает на томе человеческого размера, в грязь лицом так уж откровенно не падает. CoW имеет некие отличия от "классических" ФС по свойствам, но если их понимать - все оки-доки.

>> Будущего, ага. Без нормальных экстентов, с кучей костылей
> про какие костыли идет разговор?

Про все. Как они например диск из пула вынимать собираются? Они таки будут хранить backrefs? И что там насчет совместимости?

> Если нужна файловая система без CoW - проще будет именно ее и взять, например, XFS.

Бывает так что все файлы кроме 1-2 (ну там БД какая-нибудь) - нормально относятся к CoW. Вот в btrfs можно адресно отключить CoW для файлов где это создает проблемы и пользоваться преимуществами CoW на всем остальном. Гибкость ФС это хорошо. А метаться с ФС на ФС по причине "два файла не очень дружат с CoW" - как-то глупо. Вот оракл довел это до сведения своего архитекта и тот это весьма качественно учел. И вот такой подход мне как-то сильно более симпатичен чем ваши юления ужа на сковородке. Вот это - лицом к админам, а не тыловой частью.

> Нет, это просто к тому, насколько сильно такая фича кому-либо нужна.

А вы прямо так пошли и опросили всю планету - какие кому фичи нужны?

> Как и глюки, которые приводят к повреждению файловой системы.

Хз. На компьютере с которого я это пишу, btrfs является root FS (да, я не боюсь кушать то что нахваливаю). Вот уже полгода как оно работает а данные все в наличии. Хотя и питание некорректно слетало, и кернель я пару раз вешал наглухо экспериментами, и что там еще. Понятно что баги есть везде, но как видим - в целом вполне работает. Но да, лучше использовать максимальное свежее ядро.

> Но ведь будет создавать, потому что для использования BTRFS на HDD + SSD для кеша
> надо будет кроме BTRFS использовать еще и LVM и LVM Cache - приятного в этом мало.

Для меня это не видится большой проблемой, не говоря о том что для линуха решений по кэшированию - чуть не полдюжины. ИМХО я лучше буду иметь дело с btrfs чем с древним дизайном "ни два ни полтора", где нормальные экстенты - не смогли, изъятие диска - навороты и круть, которая будет доступна как-нибудь потом, дефрага - нет, переделать на ходу уровни RAID - фигушки, равно как и отключить CoW если мешается. А на все вопросы - ответ цитатами маркетингового булшита от санок. Мне такое не надо, спасиб. Зачем мне себя обманывать?

>> (в идеале - raw раздел, но это ж админить неудобно).
> Для BTRFS + LVM Cache приходится ведь использовать raw разделы и ничего, нормально.

Одно дело какой-то там кэш и другое - БД так админить.

> Rampant Layering Violation?

Он самый. Только в ZFS он "потому что в соляре ничего не было", а в btrfs - "потому что при таком дизайне лучше работало и стали доступны новые возможности и перспективы". С точки зрения линуха, половина кода ZFS нафиг не упало - у линуха свое это уже было. И менеджер томов, и управление памятью кэша, и что там еще.

> Solaris Volume Manager

IIRC, ZFS делался достаточно давно и вот тогда у них как раз и не было ни кэша, ни управления томами. Что отлилось в ряд странных подсистем в ZFS, которые не имеют большого смысла где-то еще.

> В таком случае - придется делить диск между LVM и BTRFS,
> в том числе и размещая BTRFS на LVM разделах, что не добавит
> ни производительности ни простоты/удобства работы с дисковой подсистемой.

При чем тут btrfs? У btrfs свои, очень кастомные понятия о том что такое RAID. А у ZFS - более-менее обычные.

> "маркетинг" - это вроде бы от слова "продажи".
> а какие могут быть продажи, если OpenZFS - это open source софт?

Ну вот такие - то что вы тут вещаете это пересказ саночного маркетингового булшита, появившегося несколько ранее полной открытости и с тех пор уже несколько навязшего на зубах.

> Какие санки? Новость вообще-то про http://en.wikipedia.org/wiki/OpenZFS

Вот такие: вы тут тыкаете ссылками и пересказами на тот маркетинговый булшит который сани втирали еще в эпоху втюхивания соляры, до того как они ораклу продались. Суперкомпетентное комьюнити очковтирателей от соляры подхватило и побежало пересказывать. Ну, типа вас, которого не понимает как CoW в файлухах работает, но уже имеющего ценное мнение. И постоянно пытающегося мне показать ссылки (которые я сто лет как видел до вас). Пфффффф. Такое соотношение апломба и неумения думать и понимать системные процессы - это suxx, мистер.

> Подробнее про линуксовый вариант: http://zfsonlinux.org/faq.html

Поверьте, я в состоянии найти FAQ на ZFS. Только вот солярщики вообще и фаны ZFS-а исторически зарекомендовали себя редкостными спиди-гонщиками. Компенсирующими технологические продолбы и упущения громкими маркетинговыми слоганами, по поводу чего объективность сведений зачастую очень хромает. А вот лично вы - попались на том что имея мнение и давая ценные указания - ни в зуб ногой как CoW в ФС работает. Ну, знаете ли, мне кажется что до того как рассуждать о преимуществах и недостатках - надо более-менее понять что вообще происходит и почему, а? По каким-то таким причинам - я совершенно не горю желанием иметь какие дела с солярой и ZFS. Комьюнити вокруг всего этого - "не очень", скажем так. В плане апломб vs квалификация.

Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

80. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от csdoc (ok) on 12-Апр-15, 14:04 
> Как вы понимаете, при рандомной ПЕРЕзаписи файл будет нещадно фрагментирован

При этом наиболее часто запрашиваемые блоки данных будут находиться
или в ARC в памяти или в L2ARC на SSD, где эта фрагментированность проблем не создает.

А ZIL значительно ускоряет sync writes, что обычно является проблемой для других FS.

>> Если устройства хранения - HDD - для них это должно дать прирост производительности.
> Зато когда наступит момент эти данные читать, нас будут ждать неприятные сюрпризы.

Вас - да, потому что в BTRFS нет L2ARC. Но в общем случае, если данные пишутся рандомно,
они потом и читаются тоже рандомно, так что фрагментация файла на это сильно не влияет.

> В архитектуре софта главное - знать меру и вовремя остановиться.
> Вот с этим у Reiser4 не задалось.

Да и с BTRFS тоже не все так однозначно.
Файловая система получилась система сложнее чем ZFS.

> и почему нельзя было нормальные экстенты сделать.

В BTRFS сделали экстенты и это привело к большому количеству сложных проблем.

>> Для нормальных баз данных не должно быть проблемой создание снапшота файловой системы
>> в любой момент. Просто потому, что это будет эквивалентно резкому пропаданию 220V
>> в момент работы с базой данных.
> Не совсем. При пропадании 220V - процесс с БД будет перезапущен
> при старте системы или когда там оно надо, после чего БД делая
> стартовые проверки - заметит неконсистентность и прочая. Но при откате снапшота
> ФС - процессы базы по дефолту никто не перезапускает и что там получится

Снапшот - это бекап. Если "откате снапшота процессы базы по дефолту
никто не перезапускает" - Вы не понимаете как работает база данных.

>>> Если уж мы о них - в ZFS нормальных экстентов нет.
>> и нет проблем с ними связанных. см. выше "Эдуард Шишкин выступил с критикой Btrfs".
> Зато есть другие. Экстенты используют потому что в типичных юзкейсах они ведут
> себя лучше чем другие решения.

Лучше они себя ведут в ext4 и XFS, где нет CoW и можно переписывать данные in-place.

В BTRFS экстенты выглядят как попытка скрестить ужа и ежа,
в результате чего - получается три метра колючей проволки.

>> Каким образом BTRFS сделает CoW при этом? Будет копировать весь большой экстент?
> YOLO! Вы не поняли как CoW в ФСах обычно работает :).

Нет, я спрашиваю как CoW будет работать в конкретной FS
по имени BTRFS при использовании там экстентов большого размера.

Чтобы вопрос был более понятным: экстент - это такой достаточно большой блок данных,
который адресуется одним куском. Например, в ext4 экстенты имеют размер до 128 мегабайт.
Но в ext4 нет CoW. А что будет делать BTRFS в случае если надо переписать
небольшой блок внутри большого экстента - копировать весь экстент?

> CoW в ФС в общем виде делается как-то так: вы пишете изменение,
> допустим в середину файла. Классическая ФС записала бы это в середину
> файла (in place patching) и все этим закончилось бы. А CoW
> ФС выносит выносок с новыми данными куда-то вбок, в область свободного
> места. Старое содержимое файла - остается неизменным. Метаданные апдейтятся,
> чтобы текущая версия файла - строилась с заменой измененого куска на этот
> ваш новый выносок.

Замечательно.
А в метаданных у BTRFS всего одна ссылка на экстент размером в 128 мегабайт.
Каким образом в такой ситуации BTRFS сделает CoW операцию модификации блока?

Будет делать перебалансировку дерева и начнет разбивать один большой экстент
на несколько мелких? Тогда понятно почему при обычной записи данных там вдруг
начинают расти в объеме и метаданные и все это в конечном итоге очень сильно тормозит.

> А новые метаданне = новый вариант файла. Btrfs делает CoW в том числе и
> для метаданных, что позволяет ему довольно легко проделывать такие фокусы.

Создали файл с экстентами 128 мегабайт, потом сделали снапшот, после чего
этот файл модифицировали, переписав всего один блок внутри файла.

В результате - имеем громадный оверхед или по данным, если копируется весь экстент
или по метаданным, если BTRFS начинает разбивать один экстент на несколько более
мелких и модифицировать метаданные, перебалансировать дерево и т.п. - при этом
придется хранить две копии метаданных, которые достаточно сильно отличаются,
для снапшота и для модифицированного файла.

> Как видите, копирование как таковое - не случается :)

Если экстент не копируется - тогда будет очень много возни с метаданными.
На всего лишь одну операцию модификации одного блока данных. Неоптимально.

Зачем же они это сделали в BTRFS ? В ZFS экстентов нет, и нет большого количества
проблем с ними связанных, так что ZFS выглядит как более простая и более надежная FS.

>> Могут и рассказали: https://blogs.oracle.com/bonwick/entry/zfs_dedup
> Ога, тут весь форум забит радостями от аппетитов дедупа :)

Если в компе мало памяти или слабый процессор - тогда zfs_dedup будет тормозить.
Я ж говорю, ZFS - это система из будущего. На мощных сановских серверах это будущее
уже наступило и там zfs_dedup работает наиболее оптимальным способом. Для массового
использования - компы у пользователей еще не достаточно мощные, чтобы zfs_dedup работал.

Для дедупликации 1 терабайта данных необходимо всего 1 гигабайт памяти. И процесор.
Учитывая, что скорость процессора и объемы памяти растут быстрее, чем скорость
ввода/вывода - вполне логичным было по максимуму использовать быстрорастущие
ресурсы и не делать лишних операций дискового ввода/вывода.

> Гибкость ФС это хорошо.

Даже если это делается путем переусложнения кода
и как разультат - наличия трудноуловимых багов ?

Насколько я понимаю, главная задача файловой системы - это надежное хранение данных,
и с этим ZFS справляется очень хорошо. В BTRFS - акцент смещен в сторону добавления
большого количества различных возможностей, из-за чего надежность хранения страдает.

>> Rampant Layering Violation?
> Он самый. Только в ZFS он "потому что в соляре ничего не
> было", а в btrfs - "потому что при таком дизайне лучше
> работало и стали доступны новые возможности и перспективы".

А в ZFS стало хуже работать и новые возможности стали недоступны?

> IIRC, ZFS делался достаточно давно и вот тогда у них как раз
> и не было ни кэша, ни управления томами. Что отлилось в
> ряд странных подсистем в ZFS, которые не имеют большого смысла где-то
> еще.

ZFS начали делать в 2001 году, менеджер томов появился в SunOS в 1991 году.

>> В таком случае - придется делить диск между LVM и BTRFS,
>> в том числе и размещая BTRFS на LVM разделах, что не добавит
>> ни производительности ни простоты/удобства работы с дисковой подсистемой.
> При чем тут btrfs?

При том что там нет L2ARC и придется использовать сторонние решения, например, LVM Cache.

> У btrfs свои, очень кастомные понятия о том
> что такое RAID. А у ZFS - более-менее обычные.

Все с точностью до наоборот.

В ZFS используется RAID-Z: http://www.stableit.ru/2010/08/raid-z.html

В BTRFS используется обычный RAID5/6: https://btrfs.wiki.kernel.org/index.php/RAID56

Ключевое отличие ZFS от BTRFS - это наличие/отсутствие уязвимости "write hole".

В результате, используя BTRFS и RAID 5/6 - невозможно получить надежное хранение данных.

Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

81. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 12-Апр-15, 16:53 
> При этом наиболее часто запрашиваемые блоки данных будут находиться или в ARC в памяти

Внезапно, в линухе тоже есть дисковый кэш. И он тоже кэширует. Хоть и не часть ФС.

> или в L2ARC на SSD, где эта фрагментированность проблем не создает.

Внезапно, это - костыли тормозной файлухе. И какие-то кастомные применения. С туевой хучей допущений (что SSD - есть, что доступ к данным - существенно неравномерный, что SSD не протрется в 2 счета, etc).

А от ФС более-менее общего назначения хотелось бы чтобы она прилично работала и без столь феерического костылирования. Намного лучше когда администрирование не превращается в истошную борьбу с костылированием технических дефектов и слабых мест ФС, а применение ФС не требует ...цать пунктов в допущениях.

Например: у меня на ноуте - нет дюжины дисков и сотен рамы, их там просто некуда пристроить. Но это не значит что сжатие, снапшоты и т.п. мне там не пригодятся, например. Btrfs там если что - смотрится не сильно хуже EXT4 в общем виде.

> А ZIL значительно ускоряет sync writes, что обычно является проблемой для других FS.

Опять же - это не "фича", а всего лишь костыль, поскольку CoW в чистом виде оказывается тормознее классических ФС.

>> Зато когда наступит момент эти данные читать, нас будут ждать неприятные сюрпризы.
> Вас - да, потому что в BTRFS нет L2ARC.

А какие-то законы природы обязывают чтение всегда попадать в кэш? Обычно кэши сильно меньше чем стораж в целом (по причине дороговизны этого начинания) и поэтому половина операций всяко будет мимо кэша. И вот там мы знакомимся с нативной непрокостыленной скорстью ФС. И вот тут ZFS совершенно нечего нам показать. Достаточно посмотреть бенчмарки хоть против доисторической версии btrfs 4+ летней древности, чтобы понять WTF. С тех пор btrfs сильно оптимизнули, если что.

А так то да, теоретически можно собрать стораж из одних SSD а лучше оперативы. Он будет быстрый как ракета. И стоить будет тоже как ракета...

> Но в общем случае, если данные пишутся рандомно,
> они потом и читаются тоже рандомно, так что фрагментация файла
> на это сильно не влияет.

Фокус в том что они будут читаться "рандомно" даже при линейном чтении (e.g. бэкап базы). Поэтому в вашем случае - линейное чтение вообще никогда не наступает. Здорово придумано.

>> Вот с этим у Reiser4 не задалось.
> Да и с BTRFS тоже не все так однозначно.

Вот сановских фанатов ZFS забыли про однозначность спросить. Поэтому они нам тут вещают какую-то лапшу на уши, полученную от экспертов Шишкиных. Пользуйтесь ФС от эксперта Шишкина тогда, раз вам он такой авторитет ФСостроения. И затыкайте технические недостатки маркетинговым булшитом, как сани завещали. А мне почему-то так не нравится. И хочется универсальную ФС с приличными свойствами, чтоб не надо было адово костылить все продолбы архитектов постоянно, да еще с кучей левых допущений, зарубающих половину сценриев использования.

> Файловая система получилась система сложнее чем ZFS.

Где-то сложнее. Где-то проще. Мэйсон посмотрел на то как делают другие и выбрал свой набор решений и компромиссов, учтя типовые проблемы. Мне в целом его ход мыслей понравился. Он пытается сделать настоящий next gen, где типовые грабли администрирования - превратятся в простые, удобные и логичные процессы. Это очень хорошее мышление архитекта. Это не какие-то абстрактные 128 битов, "потому что маркетологи сказли что 128 лучше чем 64", которые мне в обозримое время некуда прикрутить. А фичи и перспективы которые мне пригодятся и которые я понимаю как и где применить. И понимаю что то что раньше было гемором с разбором пула и тасованием терабайтов данных - теперь будет тривиальным простым процессом. Без остановки работы завязанных на это систем вообще. Возможность плавной, фоновой реконфигурации более-менее большой хранилки на ходу, без остановки - это круто и актуально, будь то добавление или изъятие девайса, изменение схемы хранения или что там еще. Я имею наглость полагать что Мэйсон в курсе основных проблем администрировния таких вещей и изволил учесть наиболее назойливые проблемы, в отличие от остальных.

> В BTRFS сделали экстенты и это привело к большому количеству сложных проблем.

Вот что-что а по линии экстентов - никаких чрезмерных проблем там не было вроде. Да и в целом - проблем там не больше чем у всех остальных. А производительность при прочих равных заметно втыкает ZFS'у. Потому что меньше операций с метаданными в ряде случаев. На то и экстент чтобы одним махом адресовать большой регион как хотелось, а не колупать его отдельными мелкими блоками. При более-менее типовых сценариях экстенты ощутимо втыкают блочным аллокаторам. По поводу чего все новые дизайны ими и пользуются. Несомненно, можно подобрать краевые случаи, когда экстентная механика будет работать плохо. Но это обычно чистая синтетика. Синтетическими извратами можно поставить в позу любую ФС.

> Снапшот - это бекап.

У, как все запущено. Снапшот - это ни в одном глазу не бэкап. Это совсем иная технология (в плане рабочей механики) и кроме всего прочего - НИ РАЗУ НЕ ЗАМЕНА БЭКАПА.

> Если "откате снапшота процессы базы по дефолту
> никто не перезапускает" - Вы не понимаете как работает база данных.

Я понимаю как работают снапшоты. И в курсе что руление снапшотами само по себе вообще никак не связано с базами, ФС сильно пофигу: базы там или что-то еще. И что снапшоты не бэкапы и ни разу не замена бэкапов - я тоже в курсе. В отличие от некоторых. Которые кажется не понимают базовые основы всей этой механики и достаточно глупы чтобы считать снапшот бэкапом. Которым он ни разу не является.

Если кто не понял: при повреждении по той или иной причине блоков на диске, снапшот может чудесно развалиться. Вместе с файлом-оригиналом. И другими снапшотами. Развалится все что совместно использовало порушенные блоки, вся цепочка. По этой причине снапшоты не являются заменой бэкапов ни в одном глазу - это доступ к множественым состояниям ("истории") ФС. Снапшоты и "оригинал" от которого они произошли совместно юзают ряд блоков. Разрушение shared блоков сделает бесполезной всю цепочку. А дедуп, если что - всего лишь очень частный случай этой механики с множесвенным референсом блоков. Поскольку оно по любому есть для того чтобы снапшоты делать, до кучи можно "почти халявно" дедупликацию прикрутить (вся механика для этого уже есть, остается только обнаруживать дупы и заменять их ссылками, точно так же как снапшоты референсятся на неизменные блоки по нескольку раз).

> Лучше они себя ведут в ext4 и XFS, где нет CoW и можно переписывать данные in-place.

В случае перезаписи in place в классике - аллокатор по идее не делает чуть менее чем ничего: размещение файла вообще не меняется.

> В BTRFS экстенты выглядят как попытка скрестить ужа и ежа,
> в результате чего - получается три метра колючей проволки.

В btrfs во первых, экстенты делают что и должны - позволяют адресовать большой регион компактной записью в метаданных. Что как и обычно повышает скорость работы ФС при прочих равных в более-менее типовых условиях. Так что когда ZFS проcacывает на очередном бенчмарке в одинаковой конфигурации - это является одной из причин.

Во вторых, если CoW какой-то из нагрузок мешает жить - его можно выключить и получить этот самый in-place patching. Базы данных будут рады. И приветы ZFS, ага :)

>> YOLO! Вы не поняли как CoW в ФСах обычно работает :).
> Нет, я спрашиваю как CoW будет работать в конкретной FS
> по имени BTRFS при использовании там экстентов большого размера.

Именно так как это было бы логично и ожидаемо. Нет, КОПИРОВАНИЯ большого блока там не будет.

> Чтобы вопрос был более понятным: экстент - это такой достаточно большой блок данных,
> который адресуется одним куском.

Спасибо, капитан.

> если надо переписать небольшой блок внутри большого экстента - копировать весь экстент?

Зачем? CoW может делать то же что и обычно: вписать *изменения* в область *свободного места*. И поправить *метаданные* описывающие все это. Так, чтобы новый вид файла - строится с учетом того что вон ту часть теперь надо брать в вон том новом месте, а не где-нибудь еще. В каком месте тут должна быть bulk-операция с данными? И кто сказал что старый вид файла (и экстент который вы хотите порушить) перестал требоваться? Это весьма зависит от наличия снапшотов и чего там еще и по умолчанию в CoW нет такого понятия как "переписать конкретный экстент/блок" в том плане что это внутреннее дело ФС и может референситься несколько раз (из разных снапшотов или чего там еще) и поэтому у вас логическая ошибка сразу на старте - в некорректной формулировке пожелания. Вы не хотите переписать экстент. Вы хотите переписать эн данных в файле таком-то по смещению такому-то. Для CoW это сигнал: сделай выносок размером эн и поправь метаданные так чтобы текущий вид файла строился с учетом этого выноска.

Сишники которые любят механику с указателями и эффектные фокусы типа перекидывания указателей с zero copy - должны бы заметить что идея подменить работу с блоками/экстентами на манипуляцию метаданными им что-то напоминает и является подвидом той же оптимизации, непонятной более высокоуровневым существам. Внезапно, вместо кантовки дофига данных можно исправить лишь описание адресации :)

> А в метаданных у BTRFS всего одна ссылка на экстент размером в
> 128 мегабайт. Каким образом в такой ситуации BTRFS сделает CoW операцию модификации блока?

По логике вещей запишет изменения в пустое место и отапдейтит метаданные так что новый вариант файла будет браться с учетом этого выноска. При этом есть только операции с метаданными, но никакие уймы данных не лопатятся. И в общем случае все это очень прилично работает. Но как и у любого дизайна ФС есть некоторые частности когда все это работает не очень хорошо. Базы данных и СoW диски виртуалок, имеющие свои понятия о журналах и желающие видеть in-place patching - один из таких частных случаев.

> Будет делать перебалансировку дерева и начнет разбивать один большой экстент
> на несколько мелких? Тогда понятно почему при обычной записи данных там вдруг
> начинают расти в объеме и метаданные и все это в конечном итоге очень сильно тормозит.

Поздравляю, вы наконец начинаете понимать tradeoff стоящий за алгоритмами на основе CoW. У CoW всегда растут метаданные при перезаписях. Выносков становится больше, описание этих выносков неизбежно занимает место. Получается избыточный оверхед + фрагментация. Поэтому CoW как дизайн и не дружит с нагрузками ориентированными на частый быстрый in-place patching типа БД и CoW-дисков виртуалок.

А блочные аллокаторы, если что, тормозят вообще всегда из-за колупания с блоками вообще независимо от того как идет аллокация. Они всегда колупаются с всеми затронутыми блоками. А экстенты - вариант как "сжулить" и отметить большой регион более компактно и быстро, не помечая вообще каждый блок региона. При очень большом числе очень мелких фрагментов экстентную механику можно ушатать до уровня блочного аллокатора, а может и хуже. Но чаще всего оно работает сильно лучше.

И да, в btrfs на случай неудачных ворклоадов есть отключение CoW. В отличие от ZFS. Где такой ворклоад получит свой in place patching, просто и быстро, а ФС не будет давиться кучей выносков. Оракл не зря БД занимается и явно попросил архитекта учесть проблему, наевшись счастья с ZFS. Тот учел.

> В результате - имеем громадный оверхед или по данным, если копируется весь экстент

Не вижу смысла копировать весь экстент. Это зачем? Он и так уже есть и на него можно референситься. Более того - на него может уповать какой-нибудь снапшот, etc.

> придется хранить две копии метаданных, которые достаточно сильно отличаются,
> для снапшота и для модифицированного файла.

Если это частая интенсивная операция, как в БД и дисках виртуалок - CoW в btrfs отключаем, пофайлово. У CoW есть неудобные ворклоады. Куча выносков - это в любом случае плохо по оверхеду и скорости. Ну вот оракл и попросил. А в ZFS такой рукоятки нет.

Так понятнее почему оракль скорее всего пошлет ZFS в пешее эротическое? Не друг оно их базам, на уровне дизайна, за что и пострадает ;).

> Если экстент не копируется - тогда будет очень много возни с метаданными.

Вы начинаете догадываться о том что любой tradeoff имеет сильные и слабые стороны. CoW плохо относится к нагрузкам типа БД, это в любом случае куча выносков и их описание. Если выносков огромное количество - работать все это будет не ахти.

Сани... рассказали что в пул надо вовремя дотыкать диски (когда пул занят на >80%, CoW механика может откровенно сколлапсировать, не имея возможноть размещать выноски непрерывно и испытывая чуть ли не экспоненциальный рост числа фрагментов). Без возможности вынуть диски, хе-хе. А деградацию производительности от кучи выносков при долговременной эксплуатации - замяли тихой сапой, предпочтя ничего не говорить про это.

Был тут кадр - Изен. Он догнал свой ZFSный пул до 20Мб/сек с 3 дисков путем забития в ноль. Ну то-есть около 6Мб/сек на диск. Что довольно х..во даже для ноутбучных дисков которые он взял.

В btrfs - сделали дефрагер который может попытаться линеаризовать размещение (а потом можно и адресацию оптимизировать, линейные регионы адресовать легко).

Вот как-то так и получается что саночники подло молчат о невкусностях дизайна. А Мэйсон вместо впаривания фуфла тихой сапой - идет и решает сложные инженерные проблемы. Даже если для этого и надо попахать. Мне так больше нравится.

> На всего лишь одну операцию модификации одного блока данных. Неоптимально.

CoW вообще неоптимален для нагрузок хотевших in place patching. И оракл похоже очень хорошо это понимает, в отличие от фанов впаривающих ZFS лохам.

> и нет большого количества проблем с ними связанных,

Ога, конечно, там все инженерные проблемы компенсируют громким маркетинговым булшитом. Сперва маркетологи, потом подхватившие волну фанаты марки. Ну а вот лично я - не понимаю зачем бы мне себя обманывать относительно свойств дизайна.

> так что ZFS выглядит как более простая и более надежная FS.

ZFS выглядит как ФС где по жизни вместо решения сложных инженерных проблем (типа деградации от фрагментации при долговременном использовании) - лишь громкий маркетинговый булшит. И можно или долго прыгать, пытаясь обкостылить проблемный дизайн до состояния когда он сносно работает или получить результат а-ля изен, если не париться, после чего истошно убеждать себя что "мне хватает!" :)

>> Ога, тут весь форум забит радостями от аппетитов дедупа :)
> Если в компе мало памяти или слабый процессор - тогда zfs_dedup будет тормозить.

Спасибо, капитан.

> Я ж говорю, ZFS - это система из будущего.

ZFS - это первая серьезная попытка сделать CoW-based. В процессе наломали немало дров и сделали довольно спорный пепелац. Будущее у такого дизайна - на кладбище космических кораблей, имхо.

> На мощных сановских серверах это будущее уже наступило

Маркетинговый булшит - это как-то так :). Не говоря о том что фирмы Сан уже несколько лет как нет с нами.

> и там zfs_dedup работает наиболее оптимальным способом.

Вы случайно не маркетолог из сана? :)

> Для дедупликации 1 терабайта данных необходимо всего 1 гигабайт памяти. И процесор.

Ога. Всего. Если это файлсервер - может куда ни шло. И то - многие вырубают фичу, т.к. выигрыш не компенсируется потреблением ресурсов. А для остальных применений...

> быстрее, чем скорость ввода/вывода

Расскажете это вон тем NVM Express-ам, да? ;)

> Даже если это делается путем переусложнения кода
> и как разультат - наличия трудноуловимых багов ?

А санки просто положили на ряд сложных инженерных проблем. Сделав из проблем инженеров проблемы пользователя. А мне это надо? Сановские врунишки так забавно юлят на вопросы о деградации производительности при долговременной работе пула, стесняясь уточнить что в их кульной ФС просто нет решения этой проблемы и это - проблемы обладателя пула, влопавшегося в это :)

> и с этим ZFS справляется очень хорошо.

Понятия о хорошем - бывают разные. По большому счету ZFS - файлуха для выделенных файлопомоек. Для всего остального она выглядит довольно субоптимально.

> В BTRFS - акцент смещен в сторону добавления
> большого количества различных возможностей, из-за чего надежность хранения страдает.

В btrfs акцент смещен на то чтобы это была универсальная ФС с более-менее адекватными параметрами. Не перепихивающая сложные инженерные проблемы с програмеров на админов.

> А в ZFS стало хуже работать и новые возможности стали недоступны?

Появился duplicate (для многих систем) код, а новые возможности ... какие там новые возможности по части RAID? Весь традиционный гимор с нуждой все разбирать и конвертить пул целиком вроде никуда не делась. А вот у Мэйсона вся архитектура заточена на плавный фоновый майнтенанс, который можно делать без ущерба всему остальному и не превращая это в гемор для администратора.

> ZFS начали делать в 2001 году, менеджер томов появился в SunOS в 1991 году.

Тогда еще менее понятно в чем пойнт. А что этот встроеный менеджер собственно такого уникального дает, чего нельзя было сделать системным? В btrfs понимаю что - пообъектные уровни RAID в перспективе, разные уровни RAID для данных и метаданных уже сейчас, гибкость в конверсии уровней и конверсия на ходу.

> При том что там нет L2ARC и придется использовать сторонние решения, например, LVM Cache.

Не вижу очевидных технических недостатков этого решения. Если оставить субъективизм за бортом - вроде решение как решение.

> Все с точностью до наоборот.
> В ZFS используется RAID-Z: http://www.stableit.ru/2010/08/raid-z.html
> В BTRFS используется обычный RAID5/6: https://btrfs.wiki.kernel.org/index.php/RAID56

В btrfs в принципе можно использовать любые схемы хранения. И со временем скорее всего сделают и иные. И нет, они не "обычные". Например, ширина stripe (в плане количества затронутых девайсов) как таковая там не обязана быть фиксированной. Это "variable-width RAID".

Например, место на некоторых девайсах может кончиться раньше чем на остальных. А кто сказал что все девайсы одинаковой емкости? Это опять какое-то левое допущение? К которому вы привыкли с эпохи царя гороха? А можно ведь сузить группу stripe-ов и записать очередную группу блоков на менее широкий набор девайсов. У btrfs есть потенциал рациональнее использовать доступное свободное место, когда носители - разного объема. И вообще не фачить админу мозг дурными ограничениями вида "все девайсы одного размера".

Скажем если есть 2 диска по 1Тб и 1 диск на 2Тб - btrfs может это рассмотреть как зеркало на 2Тб. У всех блоков будет по дополнительной копии на другом диске, но дискам совершенно не обязательно выравниваться друг на друга - btrfs плевать на все это хотел.

Btrfs не использует упрощенный маппинг 1 в 1 и hardcoded решения о том какой это будет уровень RAID. Вместо этого используя chunks и run-time решение о том как размещать вот эти данные. С архитектурной точки зрения - это совсем иной подход. Когда есть девайсы и свободное место на них. И есть запрошенная схема размещения. Если есть достаточно девайсов с свободным местом - происходит запись с запрошенной схемой хранения.

Пока не все из этого сделано полностью. Но вот это - выглядит как настоящий next gen в организации RAID. И вот в этом случае я еще могу понять зачем надо менеджер томов в ФС - выигрыш говорит за себя сам. А "просто очередную схему хранения" можно и в системный менеджер томов прикрутить, если что.

> Ключевое отличие ZFS от BTRFS - это наличие/отсутствие уязвимости "write hole".

Ключевое отличие ZFS от BTRFS - это громкий маркетинговый булшит, с игнорированием технической составляющей и перспектив дизайна.

> В результате, используя BTRFS и RAID 5/6 - невозможно получить надежное хранение данных.

Это откуда такой вывод? oO

Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

82. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от csdoc (ok) on 12-Апр-15, 18:41 
>> Файловая система [BTRFS] получилась сложнее чем ZFS.
> Где-то сложнее. Где-то проще.

В чем проще?

> Это не какие-то абстрактные 128 битов, "потому что маркетологи сказли что 128 лучше чем 64"

Лучше, вот IPv4 - 32 бита, а IPv6 сделали 128 бит, а не 64 как можно было бы предположить.

>> Снапшот - это бекап.
> У, как все запущено. Снапшот - это ни в одном глазу не бэкап.
> Это совсем иная технология (в плане рабочей механики) и кроме
> всего прочего - НИ РАЗУ НЕ ЗАМЕНА БЭКАПА.
>> Если "откате снапшота процессы базы по дефолту
>> никто не перезапускает" - Вы не понимаете как работает база данных.
> Я понимаю как работают снапшоты.

Откат снапшота == восстановление предыдущей версии базы данных из бекапа.

Надо ли при восстановлении базы из бекапа останавливать сервер баз данных?

Вот точно так же надо останавливать базу данных и в случае отката снапшота.

> У CoW всегда растут метаданные при перезаписях.

Не всегда.

> А экстенты - вариант как "сжулить" и отметить большой регион более компактно и быстро,
> не помечая вообще каждый блок региона. При очень большом числе очень мелких фрагментов
> экстентную механику можно ушатать до уровня блочного аллокатора, а может и хуже.
> Но чаще всего оно работает сильно лучше.

Только при включении transparent compression - все сваливается опять до уровня
"The compression processes ranges of a file of maximum size 128 KiB" - как и в ZFS.

> Так понятнее почему оракль скорее всего пошлет ZFS в пешее эротическое?

Они портируют BTRFS из линукса в солярис и полнсотью откажутся от использования ZFS ?

>> Я ж говорю, ZFS - это система из будущего.
> ZFS - это первая серьезная попытка сделать CoW-based

Вообще-то вторая. Первая — WAFL: http://habrahabr.ru/company/netapp/blog/99832/
Потом часть инженеров перешла на работу из NetApp в Sun и там они сделали ZFS.
После чего NetApp еще долго судилась с Sun по поводу нарушенных патентов...

> В процессе наломали немало дров и сделали довольно спорный пепелац.

Сделай лучше.

>> и там zfs_dedup работает наиболее оптимальным способом.
> Вы случайно не маркетолог из сана? :)

Нет.

>> А в ZFS стало хуже работать и новые возможности стали недоступны?
> какие там новые возможности по части RAID?

RIAD-Z

>> При том что там нет L2ARC и придется использовать сторонние решения, например, LVM Cache.
> Не вижу очевидных технических недостатков этого решения.

Если LVM Cache - тогда SSD будет быстрее изнашиваться, чем в случае использования L2ARC.

>> Все с точностью до наоборот.
>> В ZFS используется RAID-Z: http://www.stableit.ru/2010/08/raid-z.html
>> В BTRFS используется обычный RAID5/6: https://btrfs.wiki.kernel.org/index.php/RAID56
> В btrfs в принципе можно использовать любые схемы хранения.

В теории то оно разумеется да, наши корабли бороздят просторы большого театра и все такое.
Но на практике - там самый обычный RAID5/6 со всеми известными старыми проблемами.

> И нет, они не "обычные".

btrfs wiki нам врет?

>> Ключевое отличие ZFS от BTRFS - это наличие/отсутствие уязвимости "write hole".
> Ключевое отличие ZFS от BTRFS - это громкий маркетинговый булшит,
> с игнорированием технической составляющей и перспектив дизайна.

Да уж, я вижу. Потому что "write hole" - это как раз и есть техническая составляющая.

>> В результате, используя BTRFS и RAID 5/6 - невозможно получить надежное хранение данных.
> Это откуда такой вывод? oO

1) https://btrfs.wiki.kernel.org/index.php/RAID56

2) https://blogs.oracle.com/bonwick/entry/raid_z

BTRFS реализация RAID5/6 подвержена уязвимости "write hole"
и может приводить к silent data corruption. У ZFS такой уязвимости нет.

Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

84. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от чтозафигня (ok) on 13-Апр-15, 01:39 
> В чем проще?

Хоть в тех же экстентах. Блоки переменного размера - это не блоки фиксированного размера и работать с ними сложнее. А эффекта меньше чем от больших экстентов. Занафига оно такое?

> Лучше, вот IPv4 - 32 бита, а IPv6 сделали 128 бит, а
> не 64 как можно было бы предположить.

Там это дает некие преимущества. Например, можно рандомно выбирать адрес с риском коллизий около ноля. А для ФС что это дает на практике, кроме увеличения размера всей математики до величин превышающих регистры более-менее типовых процов? Лично у меня в обозримое время не ожидается сторажей превышающих 2^64, а если через ...цать лет что-то подобное наметится, большой вопрос какая там будет память и какие там ФС будут удобны. Мягко говоря совсем не факт что ZFS будет хорошо во все это вписываться.

> Откат снапшота == восстановление предыдущей версии базы данных из бекапа.

Это, мягко говоря, не так. И очень зависит от причин по которым делается откат. Если это сбой приложения и надо вернуть базу в вид как было - вариант. Если это какой либо системный или аппаратный сбой, приведший к некорректному содержимому тех или иных блоков, откат снапшота не обязан это исправлять. Не говоря о том что все это разные вещи с точки зрения файловых и административных операций.

> Надо ли при восстановлении базы из бекапа останавливать сервер баз данных?

На самом деле все очень зависит от используемых серверов и технологий бэкапа. Попытка все вот так под одну гребенку - попахивает ламерством, чтоли. Особенно с учетом игнорирования довольно фундаментальных отличий. Восстановление из бэкапа - полное восстановление, которое можно сделать на чистый стораж или в условиях повреждения блоков. Снапшот поможет только от ошибок уровня приложения.

> Вот точно так же надо останавливать базу данных и в случае отката снапшота.

Я не знаю почему вы ставите в 1 ряд 2 совсем разных действа.

>> У CoW всегда растут метаданные при перезаписях.
> Не всегда.

Простите? Чтобы старое состояние не разрушилось, надо делать новый выносок. Как вы себе представляете создание этого выноска без метаданных, которые описывают что это вообще такое и к чему это относится?

> "The compression processes ranges of a file of maximum size 128 KiB" - как и в ZFS.

А compression там, между прочим, тоже включается-выключается с пофайловой гранулярностью. Это не какое-то мегарешение раз и навсегда. А желаемый дефолт и желаемые оверрайды по месту. Очень хорошо сделано.

> Они портируют BTRFS из линукса в солярис и полнсотью откажутся от использования ZFS ?

Они будут сватать свои базы в паре с Unbreakable Linux, имхо. Ну и поддерживать btrfs. А ZFS и соляра им как таковые врядли нужны. А нафига еще они всякие там dtrace бэкпортируют на линух? Кому это надо кроме бывших солярщиков?

>> ZFS - это первая серьезная попытка сделать CoW-based
> Вообще-то вторая. Первая — WAFL: http://habrahabr.ru/company/netapp/blog/99832/

Там наверное и еще кто-нибудь найдется - идеи CoW появились не вчера и применяется подобное много где (и не только в ФС). А сани были первыми кто сделал это в виде когда оно относительно массово применяться стало.

Это как с лампочкой накаливания: идея витала в воздухе. Множество инженеров-изобретателей опробовали самые разные варианты. Но у них у всех были те или иные проблемы. А удачным и массовым оказался в результате один - тот который сделал Эдисон. Которого и запомнили в результате как создателя первой практически значимой лампочки накаливания. Ну а сани сделали то же самое с CoW ФС.

А так NILFS вон довольно древний вроде (в недрах Nippon Telegraph он хзсколько был до того как его выложили). А его название намекает что до этого были другие. Сам по себе CoW как идея - довольно фундаментально и древне.

> они сделали ZFS.

Подозреваю что они на тот момент были далеко не едиственными кто пользовался CoW. Но одно дело кто-то где-то пользовался узкой группой лиц и городил прототипы и другое - сделали нечто более-менее массово доступное.

>> В процессе наломали немало дров и сделали довольно спорный пепелац.
> Сделай лучше.

Это такое спервадобейся? А зачем? Мэйсон уже сделал, он это может лучше меня - мне нравится что я вижу, у него полет мысли повыше чем у санок будет. Таким и должен быть настоящий архитект next gen, имхо. А я что, мне просто нравится копаться в разных алгоритмах и разбираться как это устроено. Это не значит что я могу выйти и переплюнуть Мэйсона - у него весьма удачные tradeoff и большие перспективы.

>> Вы случайно не маркетолог из сана? :)
> Нет.

А похожи. Все время какие-то рекламные слоганы и жареные факты вместо технических материалов и анализа алгоритмов.

>> какие там новые возможности по части RAID?
> RIAD-Z

Теперь всем надо резко падать ниц при очередном громком маркетинговом заклинании? Я вполне допускаю что там есть некие более удачные tradeoffs, но на мое имхо это не идет ни в какое сравнение c уходом от выравнивания и блочного уровня к file-based RAID.

У саней "всего лишь очередной алгоритм RAID". Может быть хорошй. Но не меняющий взгляды на RAID принципиально. У мэйсона - фундаментальное изменение того как мы в принципе будем работать в будущем с RAID-ами вообще (иррелевантно конкретного алгоритма). В его подходе есть девайсы и свободное место. Никаких выравниваний, и намного меньше потерь свободного места на накопителях разного объема. Мэйсон понимает что самое логичное - воткнуть в пул те девайсы какие есть и получить прибавку места в пуле. Без чрезмерного поимения мозга одинаковым размером девайсов и прочими недостатками традиционного hardcoded блочного страйпинга.

>> Не вижу очевидных технических недостатков этого решения.
> Если LVM Cache - тогда SSD будет быстрее изнашиваться, чем в случае использования L2ARC.

Это на самом деле очень зависит от. Некоторые контроллеры SSD сами например жмут данные внутри SSD - в этом случае сжатие снаружи не повлияет на срок жизни SSD, т.к. с точки зрения чипов флеша объем данных вообще не изменится (встроенное сжатие не сможет сжать уже сжатые данные). Да и вообще, флеш - крупноблочные девайсы и там все сложно. Уменьшение объема записи - далеко не синоним уменьшения циклирования флэша, потому что есть еще write amplification. Но об этом имеет смысл рассуждать только если вы понимаете как работает флеш, что такое ERASE и PROGRAM, в чем проблема с erase blocks и прочая.

>> В btrfs в принципе можно использовать любые схемы хранения.
> В теории то оно разумеется да, наши корабли бороздят просторы большого театра

Без некоей базы в core части ФС не получится никаких космических кораблей. Ну то-есть вообще совсем. Донавесить "всего лишь очередной алгоритм RAID" к btrfs - не такая уж огромная работа и скорее вопрос приоритетов и спроса на все это. А вот сделать core которое нормально относится к черти-какой смеси RAID и может на лету работать с смесью таковых и в принципе принимать решение на уровне конкретных файлов, subvolume ("часть иерархии") и прочая - это да, чувствуется полет мысли архитекта.

>> И нет, они не "обычные".
> btrfs wiki нам врет?

Оно не "врет". Но там довольно специфичная реализация, на специфичной ФС.

> Да уж, я вижу. Потому что "write hole" - это как раз
> и есть техническая составляющая.

А core способное переваривать смесь RAID и выбирать схему размещения в рантайм - вовсе даже и не шаг вперед над hardcoded райдами, навязшими на зубах своей дубовой непереконфигурируемостью без большого геморроя. Знаете в чем забойный плюс btrfs? Ее можно перенастраивать без двиганий терабайтов данных куда-то еще и мегаразборок-пересборок. И это - очень серьезный шаг вперед в вопросах администрирования всего этого. Всего лишь очередной алгоритм RAID не идет ни в какое сравнение с настолько фундаментальным измеением подходов, имхо.

>> Это откуда такой вывод? oO
> 1) https://btrfs.wiki.kernel.org/index.php/RAID56

Ок, уболтали - умение читать маны наконец сослужило вам дельную службу. Но я не вижу что помешает это пролечить на манер RAID-Z. В том плане что у CoW-based btrfs - свои понятия о том что такое "update", да и RAID как таковой там не fixed width, by design. Это еще не сейчас, увы. Там код рекавери то для RAID5/6 только вкоммитили.

> BTRFS реализация RAID5/6 подвержена уязвимости "write hole"
> и может приводить к silent data corruption. У ZFS такой уязвимости нет.

Silent как я понимаю не получится из-за чексум. Но вы правы в том что потенциал для такой проблемы пока есть. Но насколько я понимаю он не является неотъемлимым свойством дизайна в случае btrfs, в отличие от классических hardcoded райдов.

Впрочем, говоря за себя - я бы пока не стал сильно уповать на RAID5/6, поскольку коду рекавери вообще без году неделя. С другой стороны - я нормально отношусь к сборке автомобиля во время гонки. Это и есть опенсорс.

Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

86. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от csdoc (ok) on 13-Апр-15, 04:06 
>> В чем проще?
> Хоть в тех же экстентах.

Из-за того, что в файловую систему добавили новую сущность
- ее код от этого проще не становится, а только лишь наоборот.

> Блоки переменного размера - это не блоки фиксированного размера
> и работать с ними сложнее.

Разница только в том, сколько места на диске и в памяти будет занимать такой блок.

> А эффекта меньше чем от больших экстентов.
> Занафига оно такое?

Для transparent compression и дедупликации. С экстентами это не работает.

>> Откат снапшота == восстановление предыдущей версии базы данных из бекапа.
> Это, мягко говоря, не так.

С точки зрения базы данных - это так.

>> Надо ли при восстановлении базы из бекапа останавливать сервер баз данных?
> На самом деле все очень зависит от используемых серверов и технологий бэкапа.

бекап файлов базы данных.

> Попытка все вот так под одну гребенку - попахивает ламерством, чтоли.
>> Вот точно так же надо останавливать базу данных и в случае отката снапшота.
> Я не знаю почему вы ставите в 1 ряд 2 совсем разных действа.

пытаюсь уже в который раз на пальцах объяснить, что если делать снапшоты
живой базы данных - консистенность не должна при этом нарушиться.

начало здесь:

http://www.opennet.dev/openforum/vsluhforumID3/101997.html#63

>>> ...мысль откатывать базу путем отката снапшота ФС - сцыкотная,
>>> ведь ФС вообще ничего не знает про консистентность базы и ее администрирование.
>>> А гордость про то что в случае ZFS можно как-то изъ...ться и все-таки закрутить

продолжение здесь:

http://www.opennet.dev/openforum/vsluhforumID3/101997.html#72

>> Для нормальных баз данных не должно быть проблемой создание снапшота файловой системы
>> в любой момент. Просто потому, что это будет эквивалентно резкому пропаданию 220V
>> в момент работы с базой данных.
>> Потом - база данных откатывает из лога транзакций незавершенные трензакции
>> и возвращается к полностью косистентному состоянию. В чем проблемы ? Не понимаю.

=====================================================

>>> У CoW всегда растут метаданные при перезаписях.
>> Не всегда.
> Простите? Чтобы старое состояние не разрушилось, надо делать новый выносок. Как вы
> себе представляете создание этого выноска без метаданных, которые описывают что это
> вообще такое и к чему это относится?

Например, если нет снапшотов - метаданные файловой системы просто меняются но не растут.
нет необходимости и смысла хранить где-либо старое и никому не нужное значение метаданных.

>> "The compression processes ranges of a file of maximum size 128 KiB" - как и в ZFS.
> А compression там, между прочим, тоже включается-выключается с пофайловой гранулярностью.
> Это не какое-то мегарешение раз и навсегда. А желаемый дефолт и
> желаемые оверрайды по месту. Очень хорошо сделано.

И там точно так же получаются в результате компрессии блоки переменной длины,
как и в ZFS, насколько я понимаю, потому что разные данные могут по разному сжиматься.

>> Они портируют BTRFS из линукса в солярис и полнсотью откажутся от использования ZFS ?
> Они будут сватать свои базы в паре с Unbreakable Linux, имхо.

Не потянут интеловские процессоры таких нагрузок, которые могут понянуть спарки.
и по количеству процессоров на один сервер и по количеству памяти на один сервер,
- это разного класса машины, примерно как многотонный белаз и грузовая газель.

Да и какой смысл ораклу уничтожать подразделение, которое приносит прибыль
и позволяет более-менее конкурировать с IBM`овскими серверами на рынке ?

> Ну и поддерживать btrfs. А ZFS и соляра им как таковые врядли нужны.

А ничего иного кроме соляры они на своих SPARC`овых серверах запустить не могут.

> А нафига еще они всякие там dtrace бэкпортируют на линух?
> Кому это надо кроме бывших солярщиков?

Ораклу и надо. Для создания vendor lock-in и видимых преимуществ перед RHEL,
у DTrace ведь лицензия такая, что запрещает включение этого кода в ядро линукса.

>>> В процессе наломали немало дров и сделали довольно спорный пепелац.
>> Сделай лучше.
> Это такое спервадобейся? А зачем?

Самый лучший способ доказать, что что-то было сделано плохо - это взять и сделать лучше.
вот как например, Линус Торвальдс доказал что Minix имеет проблемы в архитектуре
и вообще это не очень удачная реализация. Вместо того чтобы спорить на форумах.

> Мэйсон уже сделал, он это может лучше
> меня - мне нравится что я вижу, у него полет мысли
> повыше чем у санок будет. Таким и должен быть настоящий архитект
> next gen, имхо. А я что, мне просто нравится копаться в
> разных алгоритмах и разбираться как это устроено. Это не значит что
> я могу выйти и переплюнуть Мэйсона - у него весьма удачные
> tradeoff и большие перспективы.

Мэйсон еще не сделал, а только в процессе делания.
Кстати, до того Chris Mason работал в Namesys вместе с Шишкиным
над RaizerFS/Raizer4, и достаточно много идей в BTRFS утащил оттуда.

>[оверквотинг удален]
>> Если LVM Cache - тогда SSD будет быстрее изнашиваться, чем в случае использования L2ARC.
> Это на самом деле очень зависит от. Некоторые контроллеры SSD сами например
> жмут данные внутри SSD - в этом случае сжатие снаружи не
> повлияет на срок жизни SSD, т.к. с точки зрения чипов флеша
> объем данных вообще не изменится (встроенное сжатие не сможет сжать уже
> сжатые данные). Да и вообще, флеш - крупноблочные девайсы и там
> все сложно. Уменьшение объема записи - далеко не синоним уменьшения циклирования
> флэша, потому что есть еще write amplification. Но об этом имеет
> смысл рассуждать только если вы понимаете как работает флеш, что такое
> ERASE и PROGRAM, в чем проблема с erase blocks и прочая.

К чему такое большое количество слов и англоязычных терминов?

Если достаточно просто взять и посмотреть технические детали,
как устроен LVM Cache и как устроен L2ARC - тогда будет совсем
уже очевидно, какой из вариантов больше изнашивает SSD.

L2ARC хранит метаданные в памяти, LVM Cache - на диске.
Причем, LVM Cache будет апдейтить мелкие-мелкие блоки
в метаданных, так что write amplification будет в полный рост.

> А вот сделать core которое нормально относится к черти-какой смеси RAID
> и может на лету работать с смесью таковых и в принципе принимать решение
> на уровне конкретных файлов, subvolume ("часть иерархии") и прочая -
> это да, чувствуется полет мысли архитекта.

скорее уж опыт. как свой, так и учет опыта других файловых систем.
полет мысли на пустом месте редко бывает удачным.

> С другой стороны - я нормально отношусь к сборке автомобиля во время гонки.
> Это и есть опенсорс.

Бывают ситуации, когда нет возможности заниматься отладкой опенсорса
и хочется что-то более стабильное, и более надежное, CentOS, XFS, ZFS.

А BTRFS как появится в CentOS в полностью стабильном
виде - тогда и можно будет начинать им пользоваться.

Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

99. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 22-Апр-15, 06:15 
> Из-за того, что в файловую систему добавили новую сущность
> - ее код от этого проще не становится, а только лишь наоборот.

Не "новую". А лишь "сделали по другому". Сущность "аллокатор" есть в ФС по любому. А то что он будет экстенты делать вместо колупания блоков и будет заканчивать свою работу в большинстве случаев быстрее - так поэтому у всех новых ФС аллокаторы и делают на основе экстентов. Блочные аллокаторы - архаика, новые дизайны все как один на экстентах.

> Разница только в том, сколько места на диске и в памяти будет занимать такой блок.

С блоками именно жестко фиксированного размера возможен ряд упрощений математики и оптимизаций, типа какого-нибудь быстрого и лобового вычисления смещений без смотрения на кучу других вещей по типу "а какого размера был блок?". А с блоками переменного размера такой номер уже не прокатит. В результате у саней получилась какая-то буита "ни два ни полтора". Оно одновременно и достаточно сложное и параметрами не блещет, так что от бенчмарков btrfs ZFS сцaли кипятком на опеннете еще 5 лет назад. А с тех пор btrfs еще оптимизировали...

> Для transparent compression и дедупликации. С экстентами это не работает.

Вообще-то как видим на примере brfs - работает. Хоть и с некоторыми оговорками. А чем экстент фундаментально отличается от блока переменного размера, с очень большим максимальным размером? У zfs трабл в этом самом размере, что обрекает их ворочать немало метаданных даже в случае когда можно было бы просто вкатить все одним регионом, с компактным и быстрым описанием. Наверное поэтому оно так и выглядит в бенчах vs btrfs. Блочные аллокаторы проcacывают экстентным. За что и стали мамонтами ФСостроения.

> бекап файлов базы данных.

Что - бекап? Простое копирование файла БД вообще не ведет к консистентному бэкапу! ФС меняет файл на ходу и в бэкап в общем случае без спецмер попадет труха.

Базу надо или останавлвать, чтобы файлы не менялись, но это даунтайм. Или использовать собственный интерфейс выгрузки, через который выгрузится заведомо консистентный набор данных, но это - базоспецифично. А можно вот как-то на уровне ФС сжульничать с чем-то типа снапшотов, freeze/thaw и прочая, чтобы избавиться от постоянной записи в бэкапируемый файл. Но если это без явного подыгрыша со стороны БД, вы все-равно получите базу и журналы в состоянии "как было". Т.е. запросто на середине какой-то транзакции в процессе. Это не консистентная копия БД. Если такой бэкап БД подсунуть, БД должна сделать аварийное восстановление с реплеем журнала и откатом/докатом транзакций, как после краха системы. В общем это интрузивные и граблеопасные действия и наобум ворочать это снапшотной механикой файлухи - весьма спорное развлечение.

> пытаюсь уже в который раз на пальцах объяснить, что если делать снапшоты
> живой базы данных - консистенность не должна при этом нарушиться.

А как ФС и БД согласуют консистетность внутренних состояний между собой? Ах, никак? Ну тогда и консистентность БД из снапшота будет random(). Ничему не противоречит что снапшот случится прямо в тот момент, когда некая транзакция - in flight, или что там еще. ФС и ее снапшоты про это ничего не знают. Консистентность БД при этом вилами по воде писана. Такому "бэкапу" в общем случае надо будет как минимум реплей журнала как после жесткого краха.

> http://www.opennet.dev/openforum/vsluhforumID3/101997.html#72

Нельзя ли поконкретнее, без виляний? И с пониманием что ваш оппонент умеет такие развлечения и уже двно обпрыгал все подобные грабли.

> Например, если нет снапшотов - метаданные файловой системы просто меняются но не растут.

А, вы кажется начинаете догадываться почему в btrfs сделали CoW отключаемым, но с акцентом на данные. Потому что там все то же самое, только еще хуже (в нормальной ситуации в ФС в основном все-таки данные а не метаданные).

> нет необходимости и смысла хранить где-либо старое и никому не нужное значение метаданных.

Ну то-есть вы мне тут решили рассказать почему оракль попросил Мэйсона запилить nodatacow? Спасибки, я и без вас в курсе :)

> И там точно так же получаются в результате компрессии блоки переменной длины,
> как и в ZFS, насколько я понимаю, потому что разные данные могут по разному сжиматься.

Экстенты если уж на то пошло - тоже "блоки переменной длины". Просто у них большой максимальный размер, а аллокатор оптимизирован на то чтобы пытаться адресовать запрошенный регион компактной структурой которая целиком опишет запрошенную опеацию как один "блок". Ну так, в идеале. Реально конечно так получается не всегда. При недостатке места или сильно некоторых ворклоадах эта механика может завалиться в сильный рост фрагментации и оверхеда, в клиническом случае оно может стать даже хуже чисто-блочного аллокатора, но в типовых случаях оно наоборот лучше. А неудачные краевые случаи есть у всех.

С компрессией проблема в том что если вы компреснете 100500 мегабайтов за раз - вам потом придется неизбежно грузить все 100500 в память. И долго декомпрессовать все это. Все это может привести к длительным клинам и высокому потреблению памяти. Поэтому логично что т.к. сжатые данные нельзя рандомно адресовать как несжатые, придется лимитировать размер сжатого блока какой-то относительно безопасной для здоровья большинства систем величиной.

> Не потянут интеловские процессоры таких нагрузок, которые могут понянуть спарки.

Очередной громкий маркетинговый булшит имени сана :)

> - это разного класса машины, примерно как многотонный белаз и грузовая газель.

Если кто не заметил - интел давно научился штамповать белазы всех мастей.

> Да и какой смысл ораклу уничтожать подразделение, которое приносит прибыль

Прибыль ораклу приносят в основном их мега-базы. Остальное для них так, побочные технические подложки под все это. Ну да, базам надо какое-то железо и ОС чтобы работать. Это не самоцель, а "неизбежное зло". В идеале они б вообще на raw разделах гоняли, да и от ОС наверное бы избавились, если могли, но админы на г-но изойдут т.к. админить этот суперкастом станет очень неудобно.

> и позволяет более-менее конкурировать с IBM`овскими серверами на рынке ?

Что характерно, Оракл и IBM, являясь заклятыми друзьями, нашли точки соприкосновения по части баз, в том плане что в 2007 они как-то очень дружно согласились что ФС нового поколения в линухе им нужна обоим. И откуда бы такое единодушие у акул бизнеса? Может быть дело в том, что их базам нужна ФС которая сможет быть как удбной админу так и выступит при нужде тонкой подложкой под БД, которая будет не очень сильно мешаться штатной механике БД? :)

> А ничего иного кроме соляры они на своих SPARC`овых серверах запустить не могут.

По поводу чего я бы не поставил на перспективы этого вашего "спарцо". Маркетинговый булшит от санок с бла-бла о крути технологий - одно. А что оракл и почему делает - уже другое. Судя по активному развитию Unbreakable Linux - оракл оказался как-то совсем не против барыжить и линухом на х86. А все эти спарки и ZFS - легаси идущее бонусом к саночной клиентуре, ради которой все это видимо и затевалось. Ну еще патенты, но с ними не выгорело, как видим.

> Ораклу и надо. Для создания vendor lock-in и видимых преимуществ перед RHEL,

А я то наивно думал что для более-менее плавной миграции их солярной клиентуры на unbreakable linux. В линухе оно никому нафиг не упало под черти-какими лицензиями и только у одного оракла - ценность таких знаний для линуксоидов оказывается невысокой. Но все меняется, если посмотреть на саночную клиентуру, они то этим всю жизнь в соляре пользовались, и им разучивать новые инструментарии - лишний showstopper на пути миграции на Unbreakable.

> у DTrace ведь лицензия такая, что запрещает включение этого кода в ядро линукса.

По поводу чего большинству линуксоидов все это нафиг не надо. А оракл сам себе как-нибудь разрешит. И это в основном имхо чтобы пересадить сановых клиентов на линь, скинув с себя бремя единоличной разработки ОС и ФС, обтяпав это без большого churn в рядах клиентуры.

Для меня это выглядит так: соляру и zfs пустили в режим вяло текущего майнтенанса, прозрачно намекая клиентам что долговременные перспективы - в unbreakable linux, который для них постараются сделать немного более привычным поначалу. А потом часть мамонтов вымрет, часть переучится - можно будет вообще спустить разработку на тормозах и больше не тратить на это свои ресурсы. В линухе вон сколько народа систему пилит. А в соляре только сам оракл. Им это сильно надо? Мне как-то кажется что не очень, капиталисты - жадные.

> Самый лучший способ доказать, что что-то было сделано плохо - это взять
> и сделать лучше.

Ну так Мэйсон и сделал. Я его не переплюну с наскока, а тратить 20 лет жизни с неочевидным результатом я как-то не готов, и вообще, велосипедить на ровном месте - манера проприетарщиков. Я лучше посчитаю что мне тоже надо btrfs и буду не конкурировать, а коллаборировать. Как-то сильно более оптимально по ресурсы/результат, чего хронически не могут усвоить лица с саночным проприетарным бэкграундом, которым всю их жизнь вдалбливали что лучшие только местечковые велы от сана. А то что сварены из водопроводных труб - сейчас маркетологи баллон с краской притащат и об этом никто не догадается :)

> вот как например, Линус Торвальдс доказал что Minix имеет проблемы в архитектуре
> и вообще это не очень удачная реализация. Вместо того чтобы спорить на форумах.

Линус Торвальдс доказал что умение управлять проектом и расставлять приоритеты - решают. Вот в миниксе приоритет - погоня за кульными концепциями и эстетикой, в ущерб рабочим качествам. Оказалось что большинство людей хотело видеть другие приоритеты и на других условиях. И присоединились к Торвальдсу а не Таненбауму.

Архитектура у линукса далеко не лучшая. Но от операцоинки всем надо не супер-архитектуру. Моделька транформатора в кабинете физики лучше выглядит чем вон тот многотонный кусок металла. Но моделька годится только для демонстрации принципа, а тот многотонный - полрайона снабжает. Этим они и отличаются. Вот миникс годится только для показа студентам как (не)надо писать ОС :)

> Мэйсон еще не сделал, а только в процессе делания.

Линукс тоже не сделан. Он в процессе делания. Если вам надо что-то сделанное - возьмите DOS и FAT12. Их сделали. И трогать уже не будут. Можно относить на полочку музея политехники.

> Кстати, до того Chris Mason работал в Namesys вместе с Шишкиным
> над RaizerFS/Raizer4, и достаточно много идей в BTRFS утащил оттуда.

Вот только в отличие от Шишкина он сможет сделать нечто весьма интересное за какие-то разумные сроки, т.к. умеет более-менее балансировать приоритеты. И поставил первым приоритетом эксплуатационные свойства а не убер-мега-концепции. Ну как Торвальдс vs Таненбаум собственно.

> К чему такое большое количество слов и англоязычных терминов?

К том что махания какими-то преимуществами без понимания того как работают SSD - ни о чем и выглядит глуповато. Базовые свойства SSD определяются в основном свойствами флэша как типа памяти, некие поправки может внести контроллер и его кастомные умения.

> уже очевидно, какой из вариантов больше изнашивает SSD.

Все это бла-бла подтверждается какой-то статистикой циклирования по конкретным накопителям? Или как обычно у саночников - громкий маркетинговый булшит, который ничем кроме собственного апломба не подкреплен?

> Причем, LVM Cache будет апдейтить мелкие-мелкие блоки
> в метаданных, так что write amplification будет в полный рост.

Для тех кто тормоз - еще раз: во первых для линукса есть несколько вариантов кэшей. Во вторых что там реально будет происходить и как это отмаппится в фактические erase/program - очень сложный вопрос, точно просчитать это вообще невозможно. Можно лишь грубо прикинуть на основе знаний как работает флэш и что ему удобно, но все-равно остается много неизвестных в уравнении и делать громкие заявления на песке - это так по сановски...

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

> скорее уж опыт. как свой, так и учет опыта других файловых систем.
> полет мысли на пустом месте редко бывает удачным.

...но ничто так не нагибает результат, как отсутствие амбиций. Мэйсон попробовал сделать стораж таким как это и должно было быть с самого начала. Разумеется учтя типовые проблемы других дизайнов. Умные люди учатся на чужих ошибках.

> и хочется что-то более стабильное, и более надежное, CentOS, XFS, ZFS.

MSDOS, FAT12, CP/M, Multics. Стабильнее некуда - через 20 лет оно останется таким же как и сегодна.

> А BTRFS как появится в CentOS в полностью стабильном
> виде - тогда и можно будет начинать им пользоваться.

Мне вот можно уже сегодня :). Не всегда и не везде. Но я не собираюсь ждать пока последний извозчик перекуется в таксисты...

Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

103. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от csdoc (ok) on 22-Апр-15, 14:47 
> А чем экстент фундаментально отличается от блока переменного размера,
> с очень большим максимальным размером? У zfs трабл в этом самом размере,
> что обрекает их ворочать немало метаданных даже в случае когда можно
> было бы просто вкатить все одним регионом, с компактным и быстрым
> описанием. Наверное поэтому оно так и выглядит в бенчах vs btrfs.

CoW и экстенты плохо совместимы между собой.

У ZFS - более простой и надежный код в этом месте,
ценой некоторого уменьшения производительности.

У BTRFS - попытка сделать файловую систему и максимально фичастой
и максимально производительной, что ведет к усложнению алгоритмов и кода.
А если код сложный - в нем может быть больше нетривиальных ошибок и глюков.

Если надо "ехать" - тогда ZFS выглядит более привлекательно,
Если нужны "шашечки" - тогда более привлекательно выглядит BTRFS.

> А можно вот как-то на уровне ФС сжульничать с чем-то типа снапшотов,
> freeze/thaw и прочая, чтобы избавиться от постоянной записи в бэкапируемый файл.
> Но если это без явного подыгрыша со стороны БД, вы все-равно получите базу
> и журналы в состоянии "как было". Т.е. запросто на середине какой-то транзакции
> в процессе. Это не консистентная копия БД. Если такой бэкап БД подсунуть,
> БД должна сделать аварийное восстановление с реплеем журнала и откатом/докатом
> транзакций, как после краха системы.

Правильно. После чего база данных переходит в консистентное состяние.

> В общем это интрузивные и граблеопасные действия
> и наобум ворочать это снапшотной механикой файлухи - весьма спорное развлечение.

В чем именно "граблеопасность" ?

> Такому "бэкапу" в общем случае надо будет как
> минимум реплей журнала как после жесткого краха.

База данных это сделает самостоятельно.

=========================================

>>>>> У CoW всегда растут метаданные при перезаписях.
>>>> Не всегда.
>>> Простите? Чтобы старое состояние не разрушилось, надо делать новый выносок. Как вы
>>> себе представляете создание этого выноска без метаданных, которые описывают что это
>>> вообще такое и к чему это относится?

=========================================

>> Например, если нет снапшотов - метаданные файловой системы просто меняются но не растут.
> А, вы кажется начинаете догадываться почему в btrfs сделали CoW отключаемым

Нет, я говорю о том, что ваше утверждение
"У CoW всегда растут метаданные при перезаписях"
ошибочно и не соответствует действительности.

> Судя по активному развитию Unbreakable Linux - оракл оказался
> как-то совсем не против барыжить и линухом на х86.

Нет никакого "активного развития Unbreakable Linux" - оракл просто ворует результаты
работы Red Hat и пытаются заработать, продавая техническую поддержку к чужому продукту.

> долговременные перспективы - в unbreakable linux

нет никакого "unbreakable linux", это на 100% маркетинг и обман.

> В линухе вон сколько народа систему пилит. А в соляре только сам оракл.
> Им это сильно надо? Мне как-то кажется что не очень, капиталисты - жадные.

Странно, почему ж тогда майкрософт не откроет исходники виндовса под лицензией GPL ?

> Архитектура у линукса далеко не лучшая.
> Но от операцоинки всем надо не супер-архитектуру.

ошибки в архитектуре очень дорого обходятся. например:
http://habrahabr.ru/post/53048/
http://habrahabr.ru/post/179333/

>> Причем, LVM Cache будет апдейтить мелкие-мелкие блоки
>> в метаданных, так что write amplification будет в полный рост.
> во первых для линукса есть несколько вариантов кэшей.

ладно, какой из этих вариантов лучше всего подходит для использования с BTRFS ?

из стабильных в RHEL есть всего один вариант, - это LVM Cache.

> Во вторых что там реально будет происходить и как это отмаппится в фактические
> erase/program - очень сложный вопрос, точно просчитать это вообще невозможно.
> Можно лишь грубо прикинуть на основе знаний как работает флэш и что ему удобно,
> но все-равно остается много неизвестных в уравнении и делать громкие заявления
> на песке - это так по сановски...

еще раз:

LVM Cache хранит на SSD как данные кеша, так и метаданные.
метаданные - это мелкие блоки информации.

L2ARC хранит на SSD только данные, а метаданные хранятся в памяти.

еще не очевидно какой из двух вариантов кешей будет меньше
изнашивать SSD и давать большую скорость работы с кешем ?

Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

104. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от csdoc (ok) on 11-Июн-15, 15:07 
> Вообще-то как видим на примере brfs - работает.

http://www.ilsistemista.net/index.php/virtualization/47-zfs-...

и вывод:

http://www.ilsistemista.net/index.php/virtualization/47-zfs-...

For VMs storage, stay well away from BTRFS: not only it is marked a “Tech Preview” from RedHat (read: not 100% production ready), but it is very slow when used as a VM images store.

Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

53. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от zfs (??) on 11-Апр-15, 01:05 
Никто не спорит, что btrfs задумана быть крутой, полезной и лучше, чем zfs.
Но, хотеть - это одно, а быть - это другое.
Пока в btrfs не доведены до ума raid5,6, противопоставлять эти ФС ещё рановато.
Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

66. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от Аноним (??) on 11-Апр-15, 14:59 
> Пока в btrfs не доведены до ума raid5,6, противопоставлять эти ФС ещё рановато.

К 3.19 с формальной точки зрения код написан. То что он менее протестирован чем остальное - ну, логично :).

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

75. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +1 +/
Сообщение от Аноним (??) on 12-Апр-15, 02:35 
> То что он менее протестирован чем остальное - ну, логично

Еще менее чем остальное? Как говорится, "но тут снизу постучали"

Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

78. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 12-Апр-15, 03:09 
> Еще менее чем остальное? Как говорится, "но тут снизу постучали"

Залогинься, днuщe :)

Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

61. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от Аноним (??) on 11-Апр-15, 13:16 
> Проблема ZFS в том что пул может только увеличиваться. А уменьшить его, изъяв диски - ФИГВАМ. Билет в один конец.

На последней ZFS-конфе прошлым летом уже был доклад с демонстрацией уменьшения пула. Осталось только дождаться когда этот код заматереет и попадет в основную ветку

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

62. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от Аноним (??) on 11-Апр-15, 13:23 
>> Проблема ZFS в том что пул может только увеличиваться. А уменьшить его, изъяв диски - ФИГВАМ. Билет в один конец.
> На последней ZFS-конфе прошлым летом уже был доклад с демонстрацией уменьшения пула.
> Осталось только дождаться когда этот код заматереет и попадет в основную
> ветку

Тьфу. Не летом, а в ноябре :-)

В общем, смотреть здесь: http://open-zfs.org/wiki/OpenZFS_Developer_Summit

Презентация называется "Device Removal", http://open-zfs.org/w/images/b/b4/Device_Removal-Alex_Reece_...

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

67. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 11-Апр-15, 15:01 
> На последней ZFS-конфе прошлым летом уже был доклад с демонстрацией уменьшения пула.

А в сырой и недопиленной btrfs - все это уже как несколько лет работает. По поводу чего возникает вопрос: у кого там будет более сырой и менее протестированный код, собственно? :)

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

68. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +1 +/
Сообщение от Аноним (??) on 11-Апр-15, 15:46 
> А в сырой и недопиленной btrfs - все это уже как несколько лет работает. По поводу чего возникает вопрос: у кого там будет более сырой и менее протестированный код, собственно? :)

Это главная проблема btrfs: реализованы второстепенные фичи - удаление девайсов, дефрагментация, fsck, но не реализована первоочередная без которой все второстепенные - бессмысленны - надежное хранение данных,

Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

77. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 12-Апр-15, 03:08 
> - надежное хранение данных,

Хз, у меня пока из данных ничего не пропало :).

Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

93. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от zfs (??) on 20-Апр-15, 14:37 
>> - надежное хранение данных,
> Хз, у меня пока из данных ничего не пропало :).

Очень репрезентативная выборка, однако :)

Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

100. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +1 +/
Сообщение от Аноним (??) on 22-Апр-15, 07:34 
> Очень репрезентативная выборка, однако :)

Вы так говорите, как будто в ZFS багов нет :)

Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

51. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 10-Апр-15, 23:59 
> вынимать диски из пула оно уже научилось, или нет? В блоге автора
> читал, что да, уже лет много назад. А результата всё не вижу.

Для того чтобы ненапряжно вынимать диски - надо было ЗАРАНЕЕ ставить рояль в кустах в виде back references, позволяющих быстро понять как удвинуть данные с того или иного девайса и что будет затронуто. Это не получится сделать задним числом просто и быстро. Мэйсон об этом подумал, посмотрев на сановские грабли. А сани - ну, первый блин комом...

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

85. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от iCat (ok) on 13-Апр-15, 04:05 
А вот интересно: почему в каждой теме про ZFSonLinux так свирепствуют любители BTRFS?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

88. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от Аноним (??) on 13-Апр-15, 11:47 
> А вот интересно: почему в каждой теме про ZFSonLinux так свирепствуют любители BTRFS?

Правильно сказать свирепствует. Обычно в этих ветках воюет один сектант - user294. Но он очень уперт и производителен

Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

101. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 22-Апр-15, 07:37 
> А вот интересно: почему в каждой теме про ZFSonLinux так свирепствуют любители BTRFS?

Наверное потому что
1) В любую новость с btrfs прутся ZFSники.
2) Саночные сектанты уже достали своим маркетинговым булшитом, скидками и подтасовками.

Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

87. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Ононим on 13-Апр-15, 09:42 
Сломано на ядрах 3.18 и 3.19
https://github.com/zfsonlinux/zfs/issues/3257
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

90. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  –1 +/
Сообщение от Аноним (??) on 13-Апр-15, 18:58 
Собрал FreeBSD из ветки current, как изменить recordsize на 16мб?
zfs set recordsize=16MB zroot/ROOT
cannot set property for 'zroot/ROOT': 'recordsize' must be power of 2 from 512B to 128KB
В видео где-то на 17-й минуте говорят про возможность использовать блоки 16мб.
https://events.yandex.ru/lib/talks/2694/
ЧЯДНТ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

91. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +1 +/
Сообщение от Аноним (??) on 13-Апр-15, 23:55 
> ЧЯДНТ?

Не куришь исходники, ибо они Ъ

Искомые константы находятся в файле /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa.h называются SPA_OLD_MAXBLOCKSHIFT и SPA_MAXBLOCKSHIFT
Но прежде чем ковырять далее, рекомендуется прочитать каменты к ним, вдуматься в значение выражений "larger IO" и "the cost of COWing a giant block to modify one byte" и со спокойной душой оставить дальнейшие телодвижения в этом направлении:
/*
* We currently support block sizes from 512 bytes to 16MB.
* The benefits of larger blocks, and thus larger IO, need to be weighed
* against the cost of COWing a giant block to modify one byte, and the
* large latency of reading or writing a large block.
*
* Note that although blocks up to 16MB are supported, the recordsize
* property can not be set larger than zfs_max_recordsize (default 1MB).
* See the comment near zfs_max_recordsize in dsl_dataset.c for details.

Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

92. "Выпуск ZFSonLinux 0.6.4, реализации ZFS для ядра Linux "  +/
Сообщение от Аноним (??) on 14-Апр-15, 19:04 
Спасибо за информацию.
Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру