Хостинг-оператор Anchor опубликовал (http://www.anchor.com.au/blog/2013/04/the-btrfs-backup-exper.../) отчёт о тестовом внедрении файловой системы Btrfs на нескольких серверах, обеспечивающих работу системы резервного копирования. В итоге сделан вывод о том, что несмотря на обилие интересных возможностей и прогресс в развитии Btrfs, данная ФС ещё не готова для промышленного использования из-за наличия некоторых подводных камней и нерешённых проблем. Тем не менее для ознакомительного использования не на критически важных системах, таких как рабочие станции или персональные серверы, Btrfs уже можно использовать. Компания Anchor вернула на Ext4 системы, на которых был произведён переход на Btrfs, но указала на то, что будет отслеживать состояние разработки ZFS и Btrfs для перехода на одну из данных ФС в будущем.
В процессе эксперимента отсутствовали инциденты с потерей данных, успешно создавались тысячи снапшотов, средствами Btrfs было выявлено повреждение одного бита информации в RAID-массиве. Из проблем отмечалось блокирование ввода/вывода в пики создания разом большого числа резервных копий данных разных клиентов. Ошибка в коде с реализацией системы квот qgroups приводит к мягким зависаниям CPU, c восстановлением только после перезагрузки. Перезагрузка приводит к необходимости перестроения некоторых служебных структур из-за повреждения кэша свободных блоков. Перестроение достаточно длительный процесс, для 16TB раздела длящийся более часа. Ещё одна серьёзная проблема связана с непредсказуемостью переполнения Btrfs-раздела и связанным с исчерпанием свободного места замедлением работы. Неаккуратный запуск rsync настолько замедил работу с ФС, что с ней невозможно было работать.URL: http://www.anchor.com.au/blog/2013/04/the-btrfs-backup-exper.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=36803
это вам не похороникс сравнил убунту и федору...
>Ещё одна серьёзная проблема связана с непредсказуемостью переполнения Btrfs-раздела и связанным с исчерпанием свободного места замедлением работы.Превед от Шишкина =)
> Превед от Шишкина =)А что, разве хоть одна из выявленных проблем совпадает с критикой Шишкина?
Нет, разумеется. Потому что у эксплуатационщиков в отличие от теоретиков хватает ума не заниматься извращениями типа "том на 600Мб, забитый мелкими файлами" ("фантомас в очках на аэроплане").
> Нет, разумеется. Потому что у эксплуатационщиков в отличие от теоретиков хватает ума
> не заниматься извращениями типа "том на 600Мб, забитый мелкими файлами" ("фантомас
> в очках на аэроплане").Скорее, хватает ума понять, что метаданные - неотъемлемая часть ФС, и требовать 100% использования места под данные бессмысленно.
> Нет, разумеется. Потому что у эксплуатационщиков в отличие от теоретиков хватает ума
> не заниматься извращениями типа "том на 600Мб, забитый мелкими файлами" ("фантомас
> в очках на аэроплане")."том на 600Мб" -- 10 лет нвзад
"забитый мелкими файлами" -- Maildirs
Во-первых, не 10, а 15. Во-вторых, с учетом скорости развития IT это звучит примерно как жалоба на то, что современный пулемет за минуту тратит патронов больше чем, чем полтора века назад батальон с винтовками за неделю.
Что характерно, общая сложность задач возросла может быть в разы, но не на порядки же.
> А что, разве хоть одна из выявленных проблем совпадает с критикой Шишкина?Маловероятно. Одно дело - пригорание седалища у отдельно взятого разработчика, другое дело - опыт практической эксплуатации.
Критика Шишкина, напомню, касалась 'разноса' ФС при определённых условиях, когда из-за непонимания 'практиками' выбранных ими алгоритмов происходила жуткая внутренняя фрагментация метеданных, съедающая ощутимую часть места на диске. И т.к. это дефект на уровне алгоритмов, значит в корне не лечится по определению, только костыли и подпорки.Вообщем, enjoy your practice, dear permanent beta-testers =)
Шишкин, перелогиньтесь.
> метеданных, съедающая ощутимую часть места на диске.Любую ФС можно загнать в ситуацию когда ее КПД равен нулю. Создаем до упора файлы нулевого размера - и все, вуаля: на томе 0 байтов данных и весь том забит до отказа метаданными. Катит на совершенно любой ФС. Приветы Шишкину и прочим идеалистам :).
>Создаем до упора файлы нулевого размера
>Приветы Шишкину и прочим идеалистамПриятно видеть человека, который пытается думать, даже несмотря на то, что у него это довольно плохо получается
Ещё раз повторюсь: речь не о том, что метаданные занимают какое-то место, т.к. предложенным выше способом можно 'повалить' любую ФС
Речь о том, что при определённых условиях B-Tree в BTRFS _вырождается_, когда балансировка уходит не в ту сторону, т.е. появляется множество неоптимально заполненных узлов и само дерево соотв. аномально растёт. Т.е. место тратится не непосредственно полезными (мета)данными - место просто уходит В НИКУДА.
Превед двоченикам, прогуливавшим фундаментальные алгоритмы и структуры данных, ну и оболваненым monkey-тестерам =)
> Речь о том, что при определённых условиях B-Tree в BTRFS _вырождается_, когда
> балансировка уходит не в ту сторону, т.е. появляется множество неоптимально заполненных
> узлов и само дерево соотв. аномально растёт. Т.е. место тратится не
> непосредственно полезными (мета)данными - место просто уходит В НИКУДА.А подробности можно услышать? Где именно вырождается, как это влияет на размер дерева(в коэффициентах, абсолютных значениях или попугаях, плиз), при каких именно условиях. Воспроизводимость, шаблон?
> Превед двоченикам, прогуливавшим фундаментальные алгоритмы и структуры данных, ну и оболваненым
> monkey-тестерам =)Ну, автор поста, похоже, не прогуливал? И сейчас даст всем прикурить.
>А подробности можно услышать? Где именно вырождается, как это влияет на размер дерева(в коэффициентах, абсолютных значениях или попугаях, плиз), при каких именно условиях. Воспроизводимость, шаблон?
Хорошо сказал, между прочим:>If you decide to base your file system on some algorithms then please
use the original ones from proper academic papers. DO NOT modify the
algorithms in solitude: this is very fragile thing! All such
modifications must be reviewed by specialists in the theory of
algorithms. Such review can be done in various scientific magazines of
proper level.Перевожу на русский: если вы решили создать вашу файловую систему на каких-то алгоритмах - тогда пожалуйста используйте оригинальные из соотв. научных работ. НЕ МОДИФИЦИРУЙТЕ алгоритмы самостоятельно: это очень хрупкая вещь! Все подобные модификации должны быть рассмотрены специалистами в теории алгоритмов. Подобные обзоры могут быть (уже) сделаны в различных научных журналах соотв. уровня
Перевожу на понятный для школьников русский: не понимаешь, как работает что-то сложное - не пытайся что-либо в этом менять, чтобы не было фейлов уровня дебиановского openssl
> Перевожу на понятный для школьников русский: не понимаешь, как работает что-то сложное
> - не пытайся что-либо в этом менять, чтобы не было фейлов
> уровня дебиановского opensslТам другое, авто-проверки ругнулись на непонятные им данные, инициализцию и екнули.
Таки да, не двоечник и сам должен понять суть :) Вопрос-то теперь академический.
>>А подробности можно услышать? Где именно вырождается, как это влияет на размер дерева(в коэффициентах, абсолютных значениях или попугаях, плиз), при каких именно условиях. Воспроизводимость, шаблон?
> https://lkml.org/lkml/2010/6/18/144Мде, пруф искать лень, что-то там про 640 килобайт тоже было, не 3 года, конечно, но... :)
>> # for i in $(seq 1000000); \
>> do dd if=/dev/zero of=/mnt/file_$i bs=2048 count=1; done
>> (terminated after getting "No space left on device" reports).
>>
>> # ls /mnt | wc -l
>> 59480Воспроизвел, правда, 1М на 100К поменял
for i in $(seq 100000); do dd if=/dev/zero of=/mnt/0/file_$i bs=2048 count=1; doneFilesystem 1K-blocks Used Available Use% Mounted on
/dev/loop1 674816 450664 220064 68% /mnt/0System: total=4.00MB, used=8.00KB
Data+Metadata: total=655.00MB, used=440.09MB691011584 Apr 27 16:33 btrfs.img
Сорри, забыл
ls /mnt/0/ | wc -l
100003
>[оверквотинг удален]
>>> 59480
> Воспроизвел, правда, 1М на 100К поменял
> for i in $(seq 100000); do dd if=/dev/zero of=/mnt/0/file_$i bs=2048 count=1; done
> Filesystem 1K-blocks Used Available Use% Mounted
> on
> /dev/loop1 674816 450664
> 220064 68% /mnt/0
> System: total=4.00MB, used=8.00KB
> Data+Metadata: total=655.00MB, used=440.09MB
> 691011584 Apr 27 16:33 btrfs.imgИ что не нравится ? Трата места на метаданные ? Повторите этот же тест с разделом в 100 раз больше и сравните результаты.
> И что не нравится ? Трата места на метаданные ? Повторите этот
> же тест с разделом в 100 раз больше и сравните результаты.Я, как-бы, защитник btrfs :) Потрудитесь почитать линк, на который я отвечал.
> Речь о том, что при определённых условиях B-Tree в BTRFS _вырождается_, когда
> балансировка уходит не в ту сторону, т.е. появляется множество неоптимально заполненных
> узлов и само дерево соотв. аномально растёт.И чем это так уж отличается от иных вырожденных случаев, типа забития тома нулевыми файлами? Где оценки масштаба эффекта в реальных применениях? Том на 600 метров забитый мелочью - откровенная синтетика. Я даже предложил доразвитие идеи до логичного финала :)
в дискуссии, вообще-то, ссылку приводили. отличается это тем, что авторы btrfs при помощи кувалды и некоей матери напрочь поломали b-tree, начав пихать туда что попало разных размеров. этого с b-tree делать *нельзя*. от слова «вообще». b-tree от этого деградирует с дурной скоростью, напрочь убивая смысл использования сей няшной структуры.и если бы это было единственное, что они решили «улучшить»… на вскидку — использование crc как хэш-функции: это тоже очень круто. настолько круто, что просто обнять и плакать.
> на вскидку — использование crc как хэш-функции: это тоже очень круто. настолько круто, что просто обнять и плакать.А что тут такого нехорошего?
>> на вскидку — использование crc как хэш-функции: это тоже очень круто. настолько круто, что просто обнять и плакать.
> А что тут такого нехорошего?просто никогда не пиши реализацию хэш-таблиц, хорошо? воспользуйся готовой из стандартной библиотеки какого-нибудь языка: с вероятностью, близкой к 100%, она будет лучше того, что ты напишешь. потому что пользоваться гуглем — судя по этому вопросу — ты не способен.
больше заискивающих смайликов, больше.
> больше заискивающих смайликов, больше.Сдаётся мне, это опять демагог debugger. Порешил.
> в дискуссии, вообще-то, ссылку приводили. отличается это тем, что авторы btrfs при
> помощи кувалды и некоей матери напрочь поломали b-tree, начав пихать туда
> что попало разных размеров. этого с b-tree делать *нельзя*.Если уж на то пошло, у очень многих алгоритмов применяемых нынче в софте "средний" случай и "наихучший" очень сильно варьируются. Можно вспомнить например волну атак на хэш таблицы где подбором данных можно выпасть далеко за пределы O(1) который они обеспечивают "в среднем" :).
> от слова «вообще». b-tree от этого деградирует с дурной скоростью, напрочь убивая смысл
> использования сей няшной структуры.Ну и где анализ типового поведения их модифицированных деревьев? Шишкин лицо предвзятое и юзкейс выдернул крайне синтетический для показательной порки.
> и если бы это было единственное, что они решили «улучшить»… на вскидку
> — использование crc как хэш-функции: это тоже очень круто. настолько круто,
> что просто обнять и плакать.Да вообще-то это обычная практика. А то что особо хитрый хакер может специальным образом файлы создавать - так я тебе твой же пример с хакером и солонками в столовой и приведу, хренли ты хотел? Прикольно же долбануть Кэпа его собственным вооружением в качестве легкого сарказма :)
> Ну и где анализ типового поведения их модифицированных деревьев? Шишкин лицо предвзятое и юзкейс выдернул крайне синтетический для показательной порки.В новостях пробегало - достаточно создать всего 64 файла что бы убить btrfs.. вот так..
Похороникс чуть раньше сравнил ZFS и EXT4. Результат был предсказуем...
Это что ли сравнение: http://www.phoronix.com/scan.php?page=news_item&px=MTM1ODk
?
> Это что ли сравнение: http://www.phoronix.com/scan.php?page=news_item&px=MTM1ODkТы как-то очень изящно подтасовываешь результаты. Я про http://www.phoronix.com/scan.php?page=news_item&px=MTM1NTA разумеется. А то что на многодисковой конфиге ext4 не обязан хорошо работать - дык это, иди XFS там побивай. А на однодисковой конфиге ext4 просто разгромил zfs. Т.к. у самого по себе дизайна нет никаких особых поводов проявлять резвость самому по себе.
Справедливости ради, ZFS тоже не любит многопоточного доступа. Раньше были вилы вплоть до прекращения всякого I/O при работающей системе (почему-то это связано с функцией сжатия файлов в архивы tbz и tgz). Сейчас более-менее наладилось раскидывание запросов к дисковой подсистеме.
Почему не используешь EXT4 или NTFS ?))
С чего вы взяли, что он не использует NTFS?
> Почему не используешь EXT4 или NTFS ?))EXT4 не собираюсь использовать — слишком много костылей нагородили вокруг EXT2, да и малонадёжная эта ваша ФС. Пруфлинк: http://www.linux.org.ru/forum/talks/8896263
На флешке использовать данную ФС — полный бред: http://www.linux.org.ru/forum/general/8874385?cid=8874516 — журнал нужно обязательно отключать и монтировать в read-only, а то скорость ниже плинтуса. (Уж лучше UFS2, там хоть метаданные не пострадают при внезапном выдёргивании, зато скорость записи-чтения на уровне скоростных показателей контроллера флешатины).
NTFS успешно использую на корпоративной рабочей станции.
Пруфлинк не прокатит, т.к. не ясно в чём было дело - в глюке оборудования, кривых руках настройщика, убунте или в самом деле в фс. Однако, зная что soko1 - бсдешник, предполагаю что в первую очередь в кривых руках, вторая возможная причина - в оборудовании. То, что чел не попытался разобраться в чём было дело, а сразу пошёл кричать о глючности линукса, кагбэ намекает, чего стоит этот пруфлинк.Я по собственному опыту знаю, что глючат все файловые системы, особенно если бывают проблемы с оборудованием или электричеством. У меня и UFS2 ломалась (ещё в те времена, когда бсдешники кричали о том что журнал не нужен и есть Soft Updates - чекалось по полтора часа в фоне), и NTFS ломалась, и FAT32 ломалась и ReiserFS ломалась и Ext3 ломалась. Из них, естественно, самая ненадёжная - FAT32. Для ReiserFS практически отсутствуют инструменты для восстановления, когда уж совсем всё поломалось так, что даже fsck не может справиться. Поэтому на винде - NTFS, на Linux - Ext3 или Ext4 (на домашнем компе стоит, на серверах - Ext3). На фре уж не знаю что лучше использовать, пожалуй UFS+SU+J, потому что ZFS жрёт неоправданно много ресурсов. На работе бсдешники пробовали с UFS на ZFS перейти, в итоге скорость записи упала в разы, откатились обратно.
>На фре уж не знаю что лучше использовать, пожалуй UFS+SU+JЯ на DFBSD мигрирую на Hammer, бо после пары факапов UFS доверия уже нет. Хотя Hammer тоже мне сюрприз подкинул - понадеявшись на дефолтные настройки, я прохлопал исчерпание места на диске.:)
> На фре уж не знаю что лучше использовать, пожалуй UFS+SU+J, потому что ZFS жрёт
> неоправданно много ресурсов. На работе бсдешники пробовали с UFS на ZFS перейти,
> в итоге скорость записи упала в разы, откатились обратно."No silver bullet". (C)
Универсальной файловой системы на все случаи жизни нет и не будет. Реализуемые файловой системой свойства -- это всегда результат некоей торговли. И ценность торгуемых свойств очень сильно зависит от парадигмы отношения к хранимым на ФС данным.
Например, если исходить из парадигмы "данные бесценны" (то есть, принципиально никаким способом не восстанавливаемы -- например, являются результатами метеорологических наблюдений), тогда кагбэ чихать на стоимость ОЗУ -- надо 4 гигабайта под кэш для файлухи, значит, поставим. Надо 16 -- поставим 16. В этой парадигме разговорчики а-ля "ну, вероятность потери данных при сбое равна ... " считаются оппортунизмом. :)
Если же таких требований к данным не предъявляется, можно и не использовать ZFS. При наличии процедуры регулярного резервного копирования плевать с балкона, какая ФС. :) Ну, потратится время на восстановление с бэкапа, да... Ну, что-то там потеряется, что в промежутке между бэкапами было...
> Например, если исходить из парадигмы "данные бесценны"То начинать надо не с ZFS, да и заканчивать не ей. Репликация и только репликация, + контроль ошибок на всех уровнях _до_ диска.
>> Например, если исходить из парадигмы "данные бесценны"
> То начинать надо не с ZFS, да и заканчивать не ей. Репликация
> и только репликация, + контроль ошибок на всех уровнях _до_ диска.Скажи мне, человече, как ты планируешь это реализовать в RDBMS на задачах OLTP? М? С конечной латентностью ну и соответствующими требованиями к надежности и оверхеду?
Вот куда-куда, а под rdbms (и oltp, и dss) кладут zfs только полные дауны.
> Скажи мне, человече, как ты планируешь это реализовать в RDBMS на задачах
> OLTP? М? С конечной латентностью ну и соответствующими требованиями к надежности
> и оверхеду?Выше правильно ответили - положить ZFS да и вообще CoW под RDBMS может только конченый идиот. Потому что параметр latency будет совершенно непредсказуемым.
Маргиналы такие маргиналы.
>> Почему не используешь EXT4 или NTFS ?))
> EXT4 не собираюсь использовать — слишком много костылей нагородили вокруг EXT2, да
> и малонадёжная эта ваша ФС. Пруфлинк: http://www.linux.org.ru/forum/talks/8896263
> На флешке использовать данную ФС — полный бред: http://www.linux.org.ru/forum/general/8874385?cid=8874516
> — журнал нужно обязательно отключать и монтировать в read-only, а то
> скорость ниже плинтуса. (Уж лучше UFS2, там хоть метаданные не пострадают
> при внезапном выдёргивании, зато скорость записи-чтения на уровне скоростных показателей
> контроллера флешатины).
> NTFS успешно использую на корпоративной рабочей станции.NTFS вполне себе работает, если дефрагментацию проводить хотябы раз в неделю ... :)))
> NTFS вполне себе работает, если дефрагментацию проводить хотябы раз в неделю ... :)))"Фрибздшники" палятся.
ой! если бы там дело в дефрагментации было...
> NTFS вполне себе работает, если дефрагментацию проводить хотябы раз в неделю ...
> :)))Слишком толсто.
>> NTFS вполне себе работает, если дефрагментацию проводить хотябы раз в неделю ...
>> :)))
> Слишком толсто.Это не шутка, если не делать дефрагментацию то тормоза можно почуствовать уже через неделю :))
Мне трудно представить, что надо делать с томом, чтобы производительность деградировала так сильно и так быстро.
> Мне трудно представить, что надо делать с томом, чтобы производительность деградировала
> так сильно и так быстро.CoW?
Это было когда Solaris API пытались приладить к FreeBSD.
> до прекращения всякого I/O при работающей системеКруто. Впрочем там и веселее было - дедлок ядра при попытке вызвать sendfile().
> функцией сжатия файлов в архивы tbz и tgz).
А вот это врядли. Впрочем, видно птицу по помету. В смысле, жабиста по тупым заявам.
>> функцией сжатия файлов в архивы tbz и tgz).
> А вот это врядли. Впрочем, видно птицу по помету. В смысле, жабиста по тупым заявам.А синюшника видно по чему? Проблема явно где-то в zlib(3).
>>> функцией сжатия файлов в архивы tbz и tgz).
>> А вот это врядли. Впрочем, видно птицу по помету. В смысле, жабиста по тупым заявам.
> А синюшника видно по чему? Проблема явно где-то в zlib(3).А как связаны архивы tbz и zlib ?
Колбэками вызовов функций сжатия, очевидно.
> Колбэками вызовов функций сжатия, очевидно.Все бы ничего, но bzip не имеет к zlib'у вообще никакого отношения. Это вообще совершенно другое семейство алгоритмов даже :)
>> Колбэками вызовов функций сжатия, очевидно.
> Все бы ничего, но bzip не имеет к zlib'у вообще никакого отношения.
> Это вообще совершенно другое семейство алгоритмов даже :)С точки зрения Изи, это одна программа - 7z.exe :)
Шо, уже 14 февраля 2012 года таки наступило ?
"Как у BTRFS со стабильностью и производительностью?"
Как, как? Никак!
https://plus.google.com/117537647502636167748/posts/F3GC4T4W99gСправедливости ради:
"Как у EXT4 со стабильностью и производительностью?"
Как, как? Никак!
http://serverfault.com/questions/454889/ext4-kernel-panic
Что за выхлоп? Обычный протухший бит на диске. Да, и RAM сбоит, и шины данных сбоят, и поверхность диска, и логика диска которая по идее должна исправлять некоторые ошибки тоже ни марсианами сделана из вручную отобраннвх кварков атомов и молекул. И космические лучи все таки бороздят вселенную и могут редко не метко попасть и вызвать ложный сигнал.
> Что за выхлоп? Обычный протухший бит на диске. Да, и RAM сбоит,
> и шины данных сбоят, и поверхность диска, и логика диска которая
> по идее должна исправлять некоторые ошибки тоже ни марсианами сделана из
> вручную отобраннвх кварков атомов и молекул. И космические лучи все таки
> бороздят вселенную и могут редко не метко попасть и вызвать ложный
> сигнал.Вот здесь всё намного хуже:
http://www.youtube.com/watch?v=QGIwg6ye1gE
Но ведь выживает, собака такая!
RAID6 и любая фс тоже самое сделают. Это как раз таки очень легкий случай: полный вывод из строя одного носителя. Это больше демонстрация возможностей zpool, чем zfs. Если поднять ext4 поверх lvm с raid6 томом, можно будет развлечься аналогичным способом.
стабильность ext4 в 2.6.18? ну-ну.
в 2.4 с ext4 вообще полная жопа была trollface.jpg
> стабильность ext4 в 2.6.18? ну-ну.это ж фанобздоиды, у них такое считается «свежачком».
> это ж фанобздоиды, у них такое считается «свежачком».Ну так их линукслятор как раз до 2.6.22 не добирает по фичам :).В 2.6.22 уже куски lxc появилисьь А такие навороты они уже не смогли. А понтов то джайлами было, понтов...
пшшшшшш! сейчас изя ещё багрепорты из 2.4 ветки принесёт.
паника в ext4? это не модно.. А вот последний тред в linux-ext4 из-за того что оказывается в linux mm - LRU кривой и вытесняет не те странички из памяти - весьма веселит..
> из-за того что оказывается в linux mm - LRU кривой и
> вытесняет не те странички из памяти - весьма веселит..А можно сцылочку?
а не важно, что это существо пишет: это всегда ложь.
> а не важно, что это существо пишет: это всегда ложь.Не-а, порой есть сигнал.
при таком уровне зашумлености проще игнорировать полностью, нежели пытаться добыть что-то полезное.
>> а не важно, что это существо пишет: это всегда ложь.
> Не-а, порой есть сигнал.Когда играют длинную симфонию, в тысячном зале чисто случайно, теоретически кто-то может пёрнуть и попасть "в ноту", и даже в ритм. Можно ли пёрнувшего назвать музыкантом (тем более, что это случайное "попадание" вони не отменяет)?
ну да, когда эта проблема стала темой обсуждения на FS & Storage Summit в SF, в где-то в районе 20 апреля этого года - то да, ложь..А ты еще не устал защищать то в чем не разбираешься?
> А ты еще не устал защищать то в чем не разбираешься?Обоим: умерьте тон.
да ну? то есть призывать к аборту это нормально? Хм.. интересно как бы ты сдержался если это сказано было о твоей матери? хотя да.. это же твой любимец линуксоид :-) чего уж тут - ему все можно.
>> из-за того что оказывается в linux mm - LRU кривой и
>> вытесняет не те странички из памяти - весьма веселит..
> А можно сцылочку?http://marc.info/?l=linux-ext4&m=136695619430425&w=2
как-то так.
Не кривой уж тогда, а слегка быстро удаляет страницы в очень специфичном юзкейсе.Пробежал тред - народ изучает и ищет пути сделать универсальное решение, чтобы всем было хорошо. Причем фикс данного специфичного юзкейса потенциально ставит под угрозу типовые юзкейсы, и выглядит костыльно, поэтому решение достаточно нетривиальное, и до сих пор обсуждается.
Думается, что если бы это было в другой ОС / коммюнити - на решение бы просто положили, ибо юзкейс действительно специфичный.
> Не кривой уж тогда, а слегка быстро удаляет страницы в очень специфичном
> юзкейсе.в сильно специфичном? хм.. это теперь так называют полное игнорирование aging у LRU и запихивание страниц в inactive list вместо active.. мда...
А test case простой - просто пишем через DIO много, много .. и получаем постоянные чтения с диска в момент записи - потому что система убивает метаданные в памяти.
А все почему.. потому что накапливаем в pagevec и игнорируем mark_page_accessed().
> Пробежал тред - народ изучает и ищет пути сделать универсальное решение, чтобы
> всем было хорошо. Причем фикс данного специфичного юзкейса потенциально ставит под
> угрозу типовые юзкейсы, и выглядит костыльно, поэтому решение достаточно нетривиальное,
> и до сих пор обсуждается.плохо читал. Типовой аргумент - это слишком много знаний о потрохах mm в FS.
> Думается, что если бы это было в другой ОС / коммюнити -
> на решение бы просто положили, ибо юзкейс действительно специфичный.Говорят - что кур тоже доят.. Может не будем выдумывать чего не знаем? :)
А в linux комьюнити на твоем примере - очень хорошо заметно желание принизить ошибку (игнорирование mark_page_accessed()) и свести - "это же специфический use case".. мда.. повеселили :-)
> полное игнорирование aging у LRU и запихивание страниц в inactive list вместо activeПруф в студию. Хотя бы прочитайте кейс - там всё расписано, что и как делается. И для чего. Запихивание кеша в inactive - это штатное поведение - поскольку иначе кешем будут выпихиваться полезные страницы. В своп.
> А test case простой - просто пишем через DIO много, много...
Опять же - пруф в студию. В указанном выше кейсе ситуация связана с большим чтением (3-4GB/s), быстрее чем хочет автор, выпихиваются страницы из кеша, включая страницы метаданных. Это также штатное поведение. Однако со страницами метаданных народ начал разбираться - ибо это не очень хорошо.
> и получаем постоянные чтения с диска в момент записи - потому что система убивает метаданные в памяти.
Пруф.
> А все почему.. потому что накапливаем в pagevec и игнорируем mark_page_accessed().
mark_page_accessed() в том пути исполнения никогда и не было. Это уже следствие работы над кейсом.
> Говорят - что кур тоже доят.. Может не будем выдумывать чего не
> знаем? :)Да а чего выдумывать? В той же фряхе ядро при использовании IPv6 уже года 3 так и падает в кору. Это тебе не деградация производительности на специфичных юзкейсах, а несколько хуже.
Имею ничтожный с точки зрения продакшн-одминов опыт использования на домашнем десктопе как Btrfs, так и ZFS. Стандартные задачи: гента + медиапомойка.Btrfs использовал более года на SSD под системные (/ + /home) нужды.
Плюсы:
1) Снапшоты
2) Сжатие (lzo весьма увеличивает скорость ФС и экономит место на таких каталогах как исходники ядра или дерево portage)
3) Надёжность (было в общей сложности около 15 жёстких ребутов, ФС не теряла файлы и не требовала проверки/починки)
4) Томами (subvolumes) оперировать так же легко и прозрачно, как обычными каталогами
Минусы:
1) То, что в Btrfs называется снапшотами - по сути клоны, а не снапшоты, т.к. снапшот - это просто состояние ФС, его можно лишь прочесть, а в Btrfs в снапшоты можно и писать, что несколько неочевидно и снижает безопасность и сохранность)
2) Невозможно штатными средствами узнать сколько занимают снапшоты. Вообще, с диагностикой и аудитом у Btrfs огромные проблемы
3) Заметная (хотя и небольшая) просадка скорости работы с течением времени, особенно на большом количестве мелких файловZFS в общей сложности использовал месяца четыре, как на SSD для / + /home, так и на HDD для файлопомойки.
Плюсы:
1) Высокая скорость работы на SSD, и, главное, стабильность этой скорости
2) Средства аудита и мониторинга великолепны. Штатными средствами можно узнать любую мелочь о созданных ФС и пулах
3) На одном пуле можно создать множество отдельных ФС ZFS с отдельными опциями (сжатие, чексуммы, кэширование и т.д.)
4) Снапшоты (только на чтение, можно делать откаты), клоны (это то, что в Btrfs называется снапшотами), дедупликация (жрёт оперативку в невменяемых количествах), сжатие (несколько алгоритмов на выбор), чексуммы (тоже несколько алгоритмов) и ещё куча всего, чего я даже пока ещё не пробовал.
5) Надёжность. Не представляю что нужно сделать чтобы убить эту ФС
Минусов тоже хватает:
1) Жрёт оперативку под кэши за обе щёки, при этом аппетит не поддаётся контролю.
2) При забитом кэше на HDD эта ФС демонстрирует просто редкостную слоупочность. Связано это с самими алгоритмами размещения файлов на носителе - ZFS и фрагментация это единоутробные братья. Пример: есть каталог со скриншотами, который на Ext4 открывается (в KSnapshot, например, или в Dolphin) мгновенно, на ZFS с полным кэшем же он открывается несколько десятков секунд
3) Как мне кажется, вполне способна убить HDD раньше времени, т.к. бешено дёргает головки туда-сюда
4) В Linux приходится замещать встроенные в ZFS средства монтирования штатным средством Linux (mount), т.к. при выключении какие-то траблы с отмонтированием
5) Этой ФС нет и не будет в ядре, поэтому приходится возиться с initramfsВ данный момент использую ZFS на SSD под систему и на одном HDD под медиапомойку. Уже сожалею, что впилил её на HDD, но снова меремещать туда-сюда 700 Гб данных уже неохота.
c ZFS очень хорошо помогает иметь отдельные устройства для zil log и L2ARC (это если мозга мало).А я вот перехожу на линукс и с ужасом выбираю ФС, их там чуть более чем до=я но все они как-то более чем бесполезны на моих задачах, и после ZFS на них смотреть буэээ, а ext4 + снапшоты от LVM тот еще садо-мазо... и не дай Бог вам их надо много... а мне надо
$ zfs list -t snapshot|wc -l
269
я боюсь даже представить что будет с ext4 + LVM снапшотами при таком количестве. Ну а btrfs все еще бетта к сожалению и некоторые тонкости дизайна изначально не рулят.
Фишки которым ищу замену - удобство создания пулов/фс, монтирования/отмонтирования, кучи настроек для ФС, плюшки типа zfs send|receive, много бесплатных по скорости снапшотов. Полагаю что прямых аналогов в линуксах нету, просто там это видимо делается по другому. Вопрос только как. :)
Я думал ФС нужна для хранения данных необходимых для решения задач бизнеса. А вам для создание пулов, настроек и send/receive...
а если это не бизнес, а "just for fun", то фс не подходит? как страшно жить!бизнесу, вообще жизненно необходима кнопка "решить все проблемы разом и бесплатно", как я понял
> а если это не бизнес, а "just for fun", то фс не
> подходит? как страшно жить!
> бизнесу, вообще жизненно необходима кнопка "решить все проблемы разом и бесплатно", как
> я понялВ данном случае "для бизнеса" можно заменить "для использования".
А что вам мешает использовать ту же ZFS и на Линуксе?
> А что вам мешает использовать ту же ZFS и на Линуксе?Линукс и так переусложнён, а тут ещё столько же строк кода, как у XFS... Думаете, Росинант вынесет двоих (вместе с недоделанной Btrfs — троих)?
Ядро не сильно засрано в отличие от юзерспейсов, гнома с их зависимостями ...
ZFS орудие будущего, когда уже не будет механики и такого понятия как "фрагментация".
> ZFS орудие будущего, когда уже не будет механики и такого понятия как
> "фрагментация".Почему это орудие будущего тогда не поддерживает TRIM?
>> ZFS орудие будущего, когда уже не будет механики и такого понятия как
>> "фрагментация".
> Почему это орудие будущего тогда не поддерживает TRIM?CoW ФС несовместимы с TRIM.
> CoW ФС несовместимы с TRIM.Бугага. BTRFS прекрасно совместим. Может быть, ZFS несовместима с TRIM? Хотя TRIM туда припёрли, да, напомнили в этой ветке.
А можно объяснить - почему CoW несовместим с TRIM, и как выжить на флеше без этой операции?
>> CoW ФС несовместимы с TRIM.
> Бугага. BTRFS прекрасно совместим. Может быть, ZFS несовместима с TRIM? Хотя TRIM
> туда припёрли, да, напомнили в этой ветке.
> А можно объяснить - почему CoW несовместим с TRIM, и как выжить на флеше без этой операции?CoW ФС распространяется на всё доступное пространство блочного устройства и занимает его целиком. Со временем новые данные пишутся поверх помеченных к удалению самых старых не нужных данных. Если случается сбой ФС, то она должна откатиться на то состояние, которое было подтверждено предыдущей транзакцией, если это состояние тоже неконсистентно, то откат происходит дальше — и так до самого конца, когда на носитель делалась самая первая запись. Только в этом случае CoW ФС в принципе не нуждается в отдельной процедуре проверки целостности всех данных, а только в проверке консистентности последней транзакции при своей инициализации.
Таким образом, TRIM (и последующий GC) для CoW ФС фактически уменьшает пространство для манёвра отката и не способствует глубокому восстановлению ФС в случае значительных разрушений — в последнем случае необходима внешняя утилита для полной проверки целостности и фиксации нарушений (почти что сделано в Btrfs).
В ZFS же повреждения ФС обходятся откатом на последнее консистентное состояние, монтированием (импортом) с последующим выяснением характера повреждения и недоступных данных (scrubbing). Если все физические устройства, из которых состоят виртуальные, физически целы, но часть из них перезаписаны внешними инструментами (dd, например, в то время, как ZFS находилась в оффлайне), при наличии отказоустойчивых конфигураций виртуальных устройств вероятность полного восстановления ZFS практически 100% без использования ручного запуска проверочных утилит.
> CoW ФС распространяется на всё доступное пространство блочного устройстваhint: blocksize
PS: в смысле тот, который устройство показывает наружу, а то ведь будете спорить.
Извини, бред про восстановления глубокие и неглубокие поскипан - не имеет отношения к теме.> CoW ФС распространяется на всё доступное пространство блочного устройства и занимает его целиком.
Не CoW ФС, а ZFS. Более того, ZFS (как и почти любая FS) вообще ничего не знает об организации подлежащего устройства, и, как следствие, на ВЕСЬ флеш распространится не может ну совершенно никак - у него есть рабочий набор, который ОС не виден.
> Со временем новые данные пишутся поверх помеченных к удалению самых старых не нужных данных.
К сожалению, в нашем случае это решает левелер флеша. Который де факто та же самая CoW и есть.
> Таким образом, TRIM (и последующий GC) для CoW ФС фактически уменьшает пространство
> для манёвра откатаTRIM вообще не может никак уменьшать пространство - это функция только передает контроллеру флеша - какие блоки можно стереть. Ну и запускает GC, как правило.
Тогда уж давайте говорить о том, что конкретно ZFS с текущей реализацией дисков на флеше несовместим вообще, ну никак. Ему можно дать голый MTD - и он будет выступать в роли недолевелера, но вот только незадача: стираться забитые блоки флеша будут только при перезаписи, а не в фоне, как левелером в SSD, и производительность при заполнении девайса транзакциями под завязку будет сильно ниже плинтуса.
---
Да, CoW пытается взять на себя работу левелера, заполняет полностью дисковое пространство. Казалось бы - где бы прибахать TRIM к CoW? Всё просто: когда место подходит к концу - CoW FS, как правильно замечено, начинает стирать старые данные. И вот тут-то и можно очень легко помочь левелеру: CoW FS может сTRIM'ать не только то, что перезаписывается, а всю транзакцию, подлежащую удалению с диска, целиком. Сразу. И левелеру хорошо - в рабочий набор попал целый блок пространства флеша сразу, и CoW-механика поддерживается. Но это так, о птичках.
> Извини, бред про восстановления глубокие и неглубокие поскипан - не имеет отношения
> к теме.
>> CoW ФС распространяется на всё доступное пространство блочного устройства и занимает его целиком.
> Не CoW ФС, а ZFS. Более того, ZFS (как и почти любая
> FS) вообще ничего не знает об организации подлежащего устройства, и, как
> следствие, на ВЕСЬ флеш распространится не может ну совершенно никак -
> у него есть рабочий набор, который ОС не виден.Я говорил про CoW ФС вообще.
>> Со временем новые данные пишутся поверх помеченных к удалению самых старых не нужных данных.
> К сожалению, в нашем случае это решает левелер флеша. Который де факто та же самая CoW и есть.В вашем случае он решает. В нашем случае TRIM ещё нестабилен и не перенесён из -CURRENT в -STABLE.
>> Таким образом, TRIM (и последующий GC) для CoW ФС фактически уменьшает пространство
>> для манёвра отката
> TRIM вообще не может никак уменьшать пространство - это функция только передает
> контроллеру флеша - какие блоки можно стереть. Ну и запускает GC,
> как правило.ФС не скажет контроллеру: "TRIM", — GC в контроллере флэша никогда не заработает. А если скажет, то нафик ей хранить стадии собственного состояния, и нафик ей вся механика откатов CoW?! Сам подумай.
> Тогда уж давайте говорить о том, что конкретно ZFS с текущей реализацией
> дисков на флеше несовместим вообще, ну никак. Ему можно дать голый
> MTD - и он будет выступать в роли недолевелера, но вот
> только незадача: стираться забитые блоки флеша будут только при перезаписи, а
> не в фоне, как левелером в SSD, и производительность при заполнении
> девайса транзакциями под завязку будет сильно ниже плинтуса.Вот только не заметил я что-то у себя ухудшения производительности ZFS на SSD. Когда ждать-то?
> Да, CoW пытается взять на себя работу левелера, заполняет полностью дисковое пространство.
Наконец-то, просвещение настало.
> Казалось бы - где бы прибахать TRIM к CoW? Всё просто:
> когда место подходит к концу - CoW FS, как правильно замечено,
> начинает стирать старые данные. И вот тут-то и можно очень легко
> помочь левелеру: CoW FS может сTRIM'ать не только то, что перезаписывается,
> а всю транзакцию, подлежащую удалению с диска, целиком. Сразу. И левелеру
> хорошо - в рабочий набор попал целый блок пространства флеша сразу,
> и CoW-механика поддерживается. Но это так, о птичках.А она разве не это же делает, без всякого TRIM'а и GC со стороны контроллера флэша?
> Я говорил про CoW ФС вообще.CoW FS бывают разные.
> В вашем случае он решает. В нашем случае TRIM ещё нестабилен и
> не перенесён из -CURRENT в -STABLE.Логично - ибо припёрт сравнительно недавно из нашего случая.
> ФС не скажет контроллеру: "TRIM", — GC в контроллере флэша никогда не
> заработает.Бредовое заявление. GC срабатывает при заполнении рабочего набора, или близкого к тому состояния. Если не тримать специфично - то сработает во время одной из записей, замечательно вогнав систему в ожидание операции.
> А если скажет, то нафик ей хранить стадии собственного состояния, и нафик ей вся механика откатов CoW?!
Простой вопрос: каким образом TRIM удаляемой (подлежащей удалению) транзакции CoW мешает собственно логике CoW?
> Вот только не заметил я что-то у себя ухудшения производительности ZFS на
> SSD. Когда ждать-то?Когда флеш осыпется от числа перезаписей. А осыпется без TRIM он сравнительно быстро.
Ну и да - устройство уже 100% заполнено данными CoW? Если нет - пока что говорить о чем-то рано.Еще возможен случай, когда устройство досталось уже заполненным, и никакой деградации уже не будет - просто потому, что уже достигнут нижний предел производительности при записи.
> А она разве не это же делает, без всякого TRIM'а и GC со стороны контроллера флэша?
Нет, не делает. Флеш еще и стирать надо иногда. И желательно - не в процессе записи, а в фоне. Чтобы не встать в ступор при очередной записи на время стирания. И - да - не путайте SSD и MTD.
> GC срабатывает при заполнении рабочего набора, или близкого к тому состояния.Каким образом контроллер флэша начнёт процедуру GC, если не знает, какие конекретно блоки освобождены, а пространство занято под ФС всё? ФС же не сообщает ничего, не посылает команду TRIM контроллеру (в моём случае)?
> Если не тримать специфично - то сработает во время одной из записей, замечательно вогнав систему в ожидание операции.
Если используется асинхронная запись (ZFS) и предварительная компоновка групп транзакций в памяти (UFS2 и ZFS), то это не так страшно, как кажется.
>> А если скажет, то нафик ей хранить стадии собственного состояния, и нафик ей вся механика откатов CoW?!
> Простой вопрос: каким образом TRIM удаляемой (подлежащей удалению) транзакции CoW мешает собственно логике CoW?Кто говорил что мешает?
TRIM сокращает оперативный простор для отката CoW ФС, уменьшает глубину отката в случае серьёзных повреждений. Это — из-за того, что на флэше будет два набора: занятые блоки и готовые к записи/предварительно очищенные блоки. В случае отсутствия TRIM флэш под CoW ФС полностью занимается (со временем, конечно, не сразу): новые данные пишутся с предварительным очищением блоков от самых старых, помеченных к удалению блоков, размеры которых очень велики (128k) по сравнению с аппаратными блоками (4k). Очистка и перезапись больших блоков ФС (состоящих из наборов мелких аппаратных блоков флэша при условии выровненности по границам блоков) производится гораздо быстрее, чем если бы размеры блоков были равны или ненамного отличались (в случае классических ФС размеры блоков могут быть равны или в всего лишь в несколько раз превышать размер аппаратных блоков).
>> Вот только не заметил я что-то у себя ухудшения производительности ZFS на SSD. Когда ждать-то?
> Когда флеш осыпется от числа перезаписей. А осыпется без TRIM он сравнительно быстро.Вот я и спрашиваю, когда ожидать первых весточек о деградации производительности записи от SSD 64 ГБ. Суточная перезапись идёт примерно по 200 МБ, что, естественно, никак не сказывается на общей скорости или какой-либо латентности в дисковых операциях.
Про осыпания флэша без TRIM — вообще бред, я считаю.
TRIM увеличивает деградацию носителя, так как помимо GC запускает процесс освежения данных.
> Каким образом контроллер флэша начнёт процедуру GC, если не знает, какие конекретно
> блоки освобождены, а пространство занято под ФС всё? ФС же не
> сообщает ничего, не посылает команду TRIM контроллеру (в моём случае)?Бугага. Ты не в курсе, что у левелера имеется невидимый ОС рабочий набор? И контроллер, когда ты пишешь данные на "заполненный" диск - пишет это в тот самый пресловутый рабочий набор. А освобождает его по мере возможности - в рамках GC. GC срабатывает не только на TRIM.
> Если используется асинхронная запись (ZFS) и предварительная компоновка групп транзакций в памяти (UFS2 и ZFS), то это не так страшно, как кажется.
Хоть чего ты там группируй - а операция записи встанет на существенное для машины время.
> TRIM сокращает оперативный простор для отката CoW ФС
Это как, простите? TRIM'ается только то, что реально подлежит удалению.
Далее бред поскипан.> Вот я и спрашиваю, когда ожидать первых весточек о деградации производительности записи
> от SSD 64 ГБ. Суточная перезапись идёт примерно по 200 МБ, что, естественно, никак не сказывается на общей скорости или какой-либо латентности в дисковых операциях.И какова ныне скорость? А если сделать Factory Erase?
>> Каким образом контроллер флэша начнёт процедуру GC, если не знает, какие конекретно
>> блоки освобождены, а пространство занято под ФС всё? ФС же не
>> сообщает ничего, не посылает команду TRIM контроллеру (в моём случае)?
> Бугага. Ты не в курсе, что у левелера имеется невидимый ОС рабочий
> набор? И контроллер, когда ты пишешь данные на "заполненный" диск -
> пишет это в тот самый пресловутый рабочий набор. А освобождает его
> по мере возможности - в рамках GC. GC срабатывает не только
> на TRIM.Нет, не в курсе. Я не сомневаюсь в том, что в SSD есть определённый набор запасных блоков флэш памяти для подмены "плохих секторов"и этот набор довольно велик, чтобы обеспечить безотказную работу массива многоуровневых ячеек MLS без деградации продолжительное время. А про "леверный набор" поёшь только ты.
>> Если используется асинхронная запись (ZFS) и предварительная компоновка групп транзакций в памяти (UFS2 и ZFS), то это не так страшно, как кажется.
> Хоть чего ты там группируй - а операция записи встанет на существенное для машины время.Как его прочувствовать, если операции записи происходят асинхронно?!
>> TRIM сокращает оперативный простор для отката CoW ФС
> Это как, простите? TRIM'ается только то, что реально подлежит удалению.
> Далее бред поскипан.Устал протирать глаза на очевидные вещи.
>> Вот я и спрашиваю, когда ожидать первых весточек о деградации производительности записи
>> от SSD 64 ГБ. Суточная перезапись идёт примерно по 200 МБ, что, естественно, никак не сказывается на общей скорости или какой-либо латентности в дисковых операциях.
> И какова ныне скорость?% diskinfo -t /dev/ada4
/dev/ada4
512 # sectorsize
64023257088 # mediasize in bytes (59G)
125045424 # mediasize in sectors
0 # stripesize
0 # stripeoffset
124053 # Cylinders according to firmware.
16 # Heads according to firmware.
63 # Sectors according to firmware.
0000000012170909003D # Disk ident.Seek times:
Full stroke: 250 iter in 0.039546 sec = 0.158 msec
Half stroke: 250 iter in 0.038466 sec = 0.154 msec
Quarter stroke: 500 iter in 0.070313 sec = 0.141 msec
Short forward: 400 iter in 0.054375 sec = 0.136 msec
Short backward: 400 iter in 0.053934 sec = 0.135 msec
Seq outer: 2048 iter in 0.091451 sec = 0.045 msec
Seq inner: 2048 iter in 0.090278 sec = 0.044 msec
Transfer rates:
outside: 102400 kbytes in 0.416739 sec = 245717 kbytes/sec
middle: 102400 kbytes in 0.413515 sec = 247633 kbytes/sec
inside: 102400 kbytes in 0.415535 sec = 246429 kbytes/sec> А если сделать Factory Erase?
Но ЗАЧЕМ?
> ячеек MLS без деградации продолжительное время. А про "леверный набор" поёшь
> только ты.Если бы ты хоть немножко вникал - было бы проще. В левелерном наборе находятся все свободные блоки флеша. Как правило, у SSD есть некоторый overprovisioning - эти блоки используются как для замещения сбойнувших, так и в качестве рабочего набора FTL. Пассивно простаивающих блоков у SSD, как правило, нет - используется всё доступное рабочее пространство.
Вообще я с FTL работал еще лет 10 тому назад - и уже тогда на NAND-флеше, используемом в псевдодисках (ныне модное название оных - SSD) по сей день, были все эти механизмы. Сейчас они усовершенствовались, но основная идеология не изменилась - основополагающие принципы работы всё те же, бородатые.
На почитать - есть вот здесь:
Вот здесь немножко "на пальцах"по принципам работы: http://www.flashmemorysummit.com/English/Collaterals/Proceed...А здесь уже серьёзно вокруг FTL:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.163...
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.178...
http://research.microsoft.com/pubs/63596/usenix-08-ssd.pdf
http://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=10...Ну и вот нашлись даже некоторые данные по флешам:
http://forums.anandtech.com/showthread.php?t=2158353> Устал протирать глаза на очевидные вещи.
Блин, протираешь-протираешь, и всё никак не протрёшь. Протри глаза уже,
>>> Вот я и спрашиваю, когда ожидать первых весточек о деградации производительности записи
>>> от SSD 64 ГБ. Суточная перезапись идёт примерно по 200 МБ, что, естественно, никак не сказывается на общей скорости или какой-либо латентности в дисковых операциях.
>> И какова ныне скорость?
> Transfer rates:
> outside: 102400 kbytes in
> 0.416739 sec = 245717 kbytes/sec
> middle: 102400 kbytes in
> 0.413515 sec = 247633 kbytes/sec
> inside: 102400 kbytes in
> 0.415535 sec = 246429 kbytes/secЭто read. Read не интересно, интересно write - как раз таки всё зависит от состояния левелера и рабочего набора.
>> А если сделать Factory Erase?
> Но ЗАЧЕМ?Сравнить загаженный диск с чистым. Причем чистым не на уровне FS, а на уровне FTL.
>[оверквотинг удален]
>>>> Вот я и спрашиваю, когда ожидать первых весточек о деградации производительности записи
>>>> от SSD 64 ГБ. Суточная перезапись идёт примерно по 200 МБ, что, естественно, никак не сказывается на общей скорости или какой-либо латентности в дисковых операциях.
>>> И какова ныне скорость?
>> Transfer rates:
>> outside: 102400 kbytes in
>> 0.416739 sec = 245717 kbytes/sec
>> middle: 102400 kbytes in
>> 0.413515 sec = 247633 kbytes/sec
>> inside: 102400 kbytes in
>> 0.415535 sec = 246429 kbytes/secНаш друг от маркетологии лишь тонко намекает что диски с контролером sandforce2 сначала сжимают данные, а потом пишут и что то что пишется может очень сильно отличаться от исходного. Не даром же на всех форумах рекомендуют избегать это г...
> Это read. Read не интересно, интересно write - как раз таки всё
> зависит от состояния левелера и рабочего набора.Прежде всего это зависит от того насколько сожмутся записываемые данные.
> Прежде всего это зависит от того насколько сожмутся записываемые данные.Подсовывайте в тестировании рандом, делов-то. У меня стоит SSD на SandForce SF-2281 - ей вообще имхо монопенисуально при записи - сжимаемые данные или нет - показатели одни и те же. Во всяком случае серьезной разницы при записи нулей и видео не увидел. А вот при чтении - да, определенная разница имеется.
>> Прежде всего это зависит от того насколько сожмутся записываемые данные.
> Подсовывайте в тестировании рандом, делов-то. У меня стоит SSD на SandForce SF-2281
> - ей вообще имхо монопенисуально при записи - сжимаемые данные или
> нет - показатели одни и те же. Во всяком случае серьезной
> разницы при записи нулей и видео не увидел. А вот при
> чтении - да, определенная разница имеется.О мой всегда говорящий правду и только правду друг, вы можете предоставить видео того что вы только описали ? :)))))))
> О мой всегда говорящий правду и только правду друг, вы можете предоставить
> видео того что вы только описали ? :)))))))Видео вот специально ради тебя писать не буду, но вывод с консоли покажу. SSD стоит на десктопе с виндой.
Файлы для теста чтения были созданы следующим образом, и помещены на SSD:
C:\>dd if=/dev/zero of=test_zero bs=1M count=4096
C:\>dd if=/dev/random of=test_random bs=1M count=4096На машине 8Гб памяти, из них более 4Гб занято запущенным софтом, и файлы в кэш полностью не влезут.
Далее читаем нули:
C:\>dd if=test_zero of=/dev/null bs=1M
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 11.66 seconds, 368 MB/sC:\>dd if=test_zero of=/dev/null bs=1M
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 10.765 seconds, 399 MB/sА теперь читаем рандом:
C:\>dd if=test_random of=/dev/null bs=1M
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 19.891 seconds, 216 MB/sC:\>dd if=test_random of=/dev/null bs=1M
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 20.074 seconds, 214 MB/sКак бэ разница при чтении на лице. А теперь проверим запись. Чтобы запись проверить, пришлось создать рамдиск. К сожалению, рамдиск размером в 4 Гб в память не влез, поэтому создал только рамдиск в 2 Гб. Файлы формировались следующим образом:
G:\>dd if=/dev/zero of=test_zero bs=1M count=2048
G:\>dd if=/dev/random of=test_random bs=1M count=2048Сначала протестировал на нулях:
G:\>dd if=test_zero of=C:\test_zero bs=1M
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 16.047 seconds, 134 MB/sG:\>dd if=test_zero of=C:\test_zero bs=1M
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 16.585 seconds, 129 MB/sПотом грохнул нули, сформировал рандом, и протестировал на рандоме:
G:\>dd if=test_random of=C:\test_random bs=1M
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 23.036 seconds, 93.2 MB/sG:\>dd if=test_random of=C:\test_random bs=1M
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 23.833 seconds, 90.1 MB/sИтого: разница некая в синтетике, конечно, имеется - но всего в ~35Mb/s, против разницы в 150Mb/s при чтении.
>> GC срабатывает при заполнении рабочего набора, или близкого к тому состояния.
> Каким образом контроллер флэша начнёт процедуру GC, если не знает, какие конекретно
> блоки освобождены, а пространство занято под ФС всё? ФС же не
> сообщает ничего, не посылает команду TRIM контроллеру (в моём случае)?А помните рекомендацию оставлять 5-10% дискового пространства SSD неразмеченным ? Наверно не от нехрен делать это придумали.
> А помните рекомендацию оставлять 5-10% дискового пространства SSD неразмеченным ? Наверно
> не от нехрен делать это придумали.Естественно не зря. В случае ФС без поддержки TRIM это делать просто необходимо (и предварительно делать Factory Erase), чтобы флеш прожил несколько дольше и работал несколько быстрее.
В случае FS с поддержкой TRIM особой необходимости в этом нет - сама FS будет отдавать блоки в рабочий набор по мере удаления данных.
AFAIK TRIM - медленная операция, так что не всё так радужно.
> AFAIK TRIM - медленная операция, так что не всё так радужно.Ее надо грамотно использовать просто. А если ее не использовать - то ее "медленность" размазывается по обычным операциям, плюс за счет снижения объёма рабочего набора идёт дополнительная деградация по производительности.
> AFAIK TRIM - медленная операция, так что не всё так радужно.Ах, вот оно что. А я-то думал, почему это поддержку TRIM со стороны файловых систем преподносят как панацею от всех-всех проблем с SSD. Оказывается, нет никакого преимущества от увеличения скорости записи на SSD даже с использованием оного функционала ФС. Тогда уж точно: способность асинхронной записи ФС нивелирует преимущество использования TRIM.
Ты просто не понимаешь, как работает флеш с левелером. Даже при том, что тебе уже 100500+ раз объясняли. Отсюда и такие "умозаключения"."Асинхронная запись" не расскажет левелеру флеша, какие блоки можно использовать для внутренних операций в качестве рабочего набора. TRIM для SSD - не просто "фича", а жизненная необходимость.
# sysctl -a| grep -i trim
vfs.zfs.vdev.trim_on_init: 1
vfs.zfs.vdev.trim_max_bytes: 2147483648
vfs.zfs.vdev.trim_max_pending: 64
vfs.zfs.trim_disable: 0
vfs.zfs.trim.txg_delay: 32
vfs.zfs.trim.timeout: 30
vfs.zfs.trim.max_interval: 1
kstat.zfs.misc.zio_trim.bytes: 0
kstat.zfs.misc.zio_trim.success: 0
kstat.zfs.misc.zio_trim.unsupported: 270
kstat.zfs.misc.zio_trim.failed: 0
# uname -por
FreeBSD 10.0-CURRENT amd64
Прошу прощения - почему не поддерживала до недавнего времени? Совсем забыл, что из Linux-ZFS притащили-таки...
> Прошу прощения - почему не поддерживала до недавнего времени? Совсем забыл, что
> из Linux-ZFS притащили-таки...проблемы с GEOM
> проблемы с GEOMИ где тогда оно "оружие будущего", если оно только-только научилось поддерживать девайсы без ротации/фрагментации? Об оптимизации речи нет - речь о минимальной поддержке.
А еще г-н выше утверждает, что ZFS (и вообще CoW) несовместимы с TRIM. Это конечно лол (хотя в плане ZFS - может быть и так). Но какое тогда отношение эта FS вообще имеет к флешу?
Ну там не все так просто и логи нужно хранить на отдельном девайсе,Котлеты отдельно, мухи отдельно.
>> проблемы с GEOM
> И где тогда оно "оружие будущего", если оно только-только научилось поддерживать девайсы
> без ротации/фрагментации? Об оптимизации речи нет - речь о минимальной поддержке.
> А еще г-н выше утверждает, что ZFS (и вообще CoW) несовместимы с
> TRIM. Это конечно лол (хотя в плане ZFS - может быть
> и так). Но какое тогда отношение эта FS вообще имеет к
> флешу?Не золотая пуля, но, под нагрузкой не прогибаеться так сильно
Разве кто-то кроме тебя говорил об отношении ZFS к устройствам на flash? Сказано было в том ключе, что эта ФС эпохи устройств без механики. Ну, например, завтра придумают "суперфлеш" не с тысячами а с триллионами циклов перезаписи да к тому же не нуждающиеся в "сборке мусора"? Мелко мыслишь сегодняшними категориями.
И да, подумай на досуге, как концепция CoW сочетается со сборкой мусора, особенно это касается труЪ CoW файловых систем типа JFFS и подобных ей.
К моменту, когда это придумают, ZFS будет уже окаменевшим ГМ.
Судя по всем линуксовским файловым системам она не умрет
Да и управление ZFS куда приятинее
У некоторых ФС на линуксе нету проверки диска :) что уж там про потерью инфы говорить
Точнее - не успеет даже ожить... Юзкейсов слишком мало.
> К моменту, когда это придумают, ZFS будет уже окаменевшим ГМ.В любом случае, она переживет поколение пепси, ярким представителем которого ты являешься.
>> К моменту, когда это придумают, ZFS будет уже окаменевшим ГМ.
> В любом случае, она переживет поколение пепси, ярким представителем которого ты являешься.точнее, "клинского"
> В любом случае, она переживет поколение пепси, ярким представителем которого ты являешься.Ути-пути. Во-первых, телепатия не прокачана, двойка. Во-вторых, FAT уже пережила минимум одно поколение. Вот только ничего хорошего от ее наличия не было и нет. И не будет.
ну и где твоя супер пупер линуксовая фс которая рвет ZFS в клочья? Я как раз ищу такую.
Требования: обеспечение целостности данных на уровне FS, быстрые снапшоты не влияющие на скорость, легкость управления, про разные настройки для каждой FS ладно промолчу.
снапшоты ради снапшотов?
> снапшоты ради снапшотов?ради быстрых бэкапов..
>> снапшоты ради снапшотов?
> ради быстрых бэкапов..И чем снапшот конкретно убыстряет бэкап? Для рядового бэкапа вполне достаточно снапшота LVM, для огромных объёмов уже нужны специальные механизмы в любом случае.
>>> снапшоты ради снапшотов?
>> ради быстрых бэкапов..
> ... вполне достаточно снапшота LVM ...Сразу видно кто не пробовал их делать на больших винтах :))
> Сразу видно кто не пробовал их делать на больших винтах :))Для "больших винтов" (точнее - объемов данных выше 5-10 Тб) есть несколько иные способы снятия бэкапа, чем тупое копирование. Например - лог операций. Но это опять же о птичках. Тупое копирование хоть со снапшотом, хоть без, длится вечность и напрягает дисковую систему.
>> Сразу видно кто не пробовал их делать на больших винтах :))
> Для "больших винтов" (точнее - объемов данных выше 5-10 Тб) есть несколько иные способы снятия бэкапа, чем тупое копирование.Ага — инкрементное бэкапирование.
> Например - лог операций.
А что это такое? Что нам даст лог операций?
> Ага — инкрементное бэкапирование.Заколебешься инкременты сверять. А если изменяющийся файл в пару терабайт объёмом (БД)?
>> Например - лог операций.
> А что это такое? Что нам даст лог операций?Это журнал событий/изменений. По нему можно восстановить систему от последнего полного бэкапа до любого момента времени в журнале с момента полного бэкапа. Простейший пример - binlog в СУБД.
Напомните как там в linux с поддержкой ntfs ? Писать можно или только читать ?
> Напомните как там в linux с поддержкой ntfs ? Писать можно или
> только читать ?Можно и читать и писать. Модуль ntfs-3g.
>>> снапшоты ради снапшотов?
>> ради быстрых бэкапов..
> И чем снапшот конкретно убыстряет бэкап? Для рядового бэкапа вполне достаточно снапшота
> LVM, для огромных объёмов уже нужны специальные механизмы в любом случае.lvm snapshot не обеспечивает консистентности содержимого FS. так как представляет из себя слепок блочного устройсва - в тоже время fs snapshot (UFS / ZFS / тестовые варианты для EXT4) гарантирует что с данными и метаданными у тебя все в порядке.
Это все не считая того что при количестве снапшотов больше 10 - LVM томозит просто неприлично.
> lvm snapshot не обеспечивает консистентности содержимого FS
> Это все не считая того что при количестве снапшотов больше 10 -
> LVM томозит просто неприлично.Ну, для бэкапа достаточно и одного.
Тут вопрос - что важнее - снапшоты, или всё-таки высокая производительность в боевом режиме. Если снапшоты - то BTRFS/ZFS, если всё остальное - то классика.
Юзкейс?Требования: высокая производительность при приличном заполнении диска, отсутствие гиперфрагментации файлов при перезаписи блоков внутри файлов, минимальный расход памяти на поддержание структур FS, поддержка TRIM на флеше, поддержка экстентов для быстрой работы с файлами большого объёма, поддержка DIRECT_IO, кеширование средствами системного кэша, поддержка барьерной записи.
Типовой юзкейс для вышеперечисленного - СУБД. Ну и где ZFS при таких требованиях?
А если до кучи впилить в требование нативную поддержку Linux, поскольку весь стабильный и поддерживаемый, что немаловажно, серверный софт в основном под оный... и имеем в сухом остатке не так уж и много вариантов.
> Юзкейс?
> Требования: высокая производительность при приличном заполнении диска, отсутствие гиперфрагментации
> файлов при перезаписи блоков внутри файлов, минимальный расход памяти на поддержание
> структур FS, поддержка TRIM на флеше, поддержка экстентов для быстрой работы
> с файлами большого объёма, поддержка DIRECT_IO, кеширование средствами системного кэша,
> поддержка барьерной записи.
> Типовой юзкейс для вышеперечисленного - СУБД. Ну и где ZFS при таких
> требованиях?после чего начинаем думать - а почему это для СУБД советуют использовать raw storage....
Хотя ты прав - ZFS в этих условиях не нужна, а вот zpool - будет очень удобен.
потому как ему не нужны вские струтукруры на диске - он просто предоставляет сторадж с поддержкой транзакций.PS. кэширование средствами системного кэша и DIO - это противоположные требования. DIO - подразумевает cache by pass..
> PS. кэширование средствами системного кэша и DIO - это противоположные требования.Это разные требования, однако в боевых случаях нужно как то, как и другое. СУБД может работать как в DIO, так и без оного. Важно то, что кеш в случае его использования должен быть системным. А не на соплях сбоку.
> Важно то, что кеш в случае его использования должен быть системным.Системный кэш нужен только под метаданные ФС, в случае raw storage не нужен и он. А самой СУБД системный кэш нафег не уперся. У нее свой собственный, гораздо гораздючее под ее собственные особенности. И логичнее будет отдать ту память ей.
> Системный кэш нужен только под метаданные ФС, в случае raw storage не
> нужен и он. А самой СУБД системный кэш нафег не уперся.
> У нее свой собственный, гораздо гораздючее под ее собственные особенности. И
> логичнее будет отдать ту память ей.Именно. И тем более ей не уперся гвоздями прибитый сбоку ZFS ARC. Который хочет over 100500 RAM, и не отключается... Ну и размер метаданных в ZFS "слегка" побольше.
>> Системный кэш нужен только под метаданные ФС, в случае raw storage не
>> нужен и он. А самой СУБД системный кэш нафег не уперся.
>> У нее свой собственный, гораздо гораздючее под ее собственные особенности. И
>> логичнее будет отдать ту память ей.
> Именно. И тем более ей не уперся гвоздями прибитый сбоку ZFS ARC.
> Который хочет over 100500 RAM, и не отключается... Ну и размер
> метаданных в ZFS "слегка" побольше.Слушай, ну не трындите уже, о том чего вы не знаете, а? "Не отключается". Вафелы вы неграмотные:
set zfs:zfs_arc_max=1073741824
set zfs:zfs_immediate_write_sz=1000000000
set zfs:zvol_immediate_write_sz=1000000000Чо-чо там не отключается, не ограничивается, итп.???????
> Слушай, ну не трындите уже, о том чего вы не знаете, а?
> "Не отключается". Вафелы вы неграмотные:
> set zfs:zfs_arc_max=1073741824
> set zfs:zfs_immediate_write_sz=1000000000
> set zfs:zvol_immediate_write_sz=1000000000И где там отключение? zfs_arc_max=0 работать будет?
да тут бы у Иксперта сначала кнопку для включения мозгов найти…
>> zfs_arc_max=0 работать будет?Пока не закончиться оперативка :)
zfs create tank/mysql
zfs set atime=off tank/mysql
zfs set mountpoint=/var/db/mysql tank/mysql
zfs create tank/mysql/ibdata
zfs set recordsize=16k tank/mysql/ibdata
zfs create tank/mysql/iblogs
zfs set recordsize=128k tank/mysql/iblogszfs set primarycache=metadata data/mysql/ibdata
innodb_flush_method = O_DIRECT
skip-innodb_doublewrite
innodb_data_home_dir=/var/db/mysql/ibdatavfs.zfs.prefetch_disable=1
От гиперфрагментации (ибо CoW) это не избавит.
> От гиперфрагментации (ибо CoW) это не избавит.Так мы таке почитали вики что такое CoW? Ну и как вам CoW + TRIM? Расскажите, интересно же.
> Так мы таке почитали вики что такое CoW? Ну и как вам CoW + TRIM? Расскажите, интересно же.Почитали? Ну идите еще почитайте. Особенно по логике работы флеша.
в zfs нету CoW
> в zfs нету CoWв raidz есть
> в zfs нету CoWit's epic, bro
> Юзкейс?
> Требования:Нагромождение требований к дизайну ФС плюс дикий микс разных к этому дизайну плюшек не относящихся. Ты что, дурак?
Так юзкейс для своего варианта уже приведёшь, или пустопорожнее?
вот как ограниченность файловых систем в линуксах не дает даже возможности представить где можно использовать сотни снапшотов и какой от этого может быть профит. реальной альтернативы ZFS не представлено, и судя по фанатичности отстаивания позиций православного линукса дальнейшее обсуждение перспектив не имеет.
В качесте ликбеза сходите и посмотрите как архитектурно построены правильные ФС типа того жу WAFL и почему разработка 20летней давности до сих пор кроет как бык овцу все современные ФС начиная от костыльных ext(2,3,4) кончая всевозможными CoW.
PS: По степени упоротости AlexAT пожалуй превосходит и юзера294 и _Nick_ вместе взятых.
Слив засчитан. Пока, господа, для ваших академических поделок не будет _широкого_ юзкейса - они так и останутся узкоспециализированным раритетом, выбирать который будут только в исключительно специфичных случаях. И то - постоянно смотря на более универсальные альтернативы, ибо в эксплуатации проще поддерживать одну сущность, чем несколько.
http://joyent.com/blog/why-smartos-kvm-dtrace-zones-and-more
> http://joyent.com/blog/why-smartos-kvm-dtrace-zones-and-moreАдовый гибрид Illumos + QEMU + KVM + тонны маркетингового булшита. Спасибо, избавьте.