Тим Берд (Tim Bird), инженер компании Sony и участник группы разработки встраиваемых систем в Linux Foundation, опубликовал (http://permalink.gmane.org/gmane.linux.embedded.celinux.deve...) подробное руководство (PDF (http://elinux.org/images/b/b6/EMMC-SSD_File_System_Tuning_Me...), 550 Мб) по тюнингу производительности файловых систем Ext4, Btrfs и F2FS (http://www.opennet.ru/opennews/art.shtml?num=35667) с учётом выбора планировщиков ввода/вывода, для достижения оптимальной производительности на накопителях eMMC/SSD. В статье досконально проанализированы доступные опции и представлены тесты производительности, демонстрирующие эффект, достигнутый при использовании каждой опции.
В частности, изучен эффект от монтирования с такими опциями, как "mount -o noatime", "mount -o discard", "tune2fs -O ^has_journal", "mount -o data=writeback", "mount -o nobarrier", "mount -o stripe=, mkfs -E stripe-width=", "mount -o ssd", "mount -o ssd_spread". Оценено влияние выбора планировщиков ввода/вывода noop, deadline, cfq, row. В итоге, правильный выбор планировщика и опций монтирования позволил увеличить производительность при выполнении некоторых тестов от 20% до 400%.
При этом универсального набора опций не найдено, для каждого типа носителя и типа нагрузки эффективным оказывался свой вариант тюнинга. При однотипной нагрузке (только чтение или только запись) влияние опций оптимизации и типа планировщка менее заметно, чем при смешанном характере нагрузки. В общем виде скорость чтения в основном упирается в пропускную способность накопителя. На скорость операций случайной записи положительно влияет размер кэша ФС.
Среди общих наблюдений: ФС Btrfs демонстрировала заметный рост производительности при включении режима SSD для накопителей с поддержкой операции TRIM. Оптимальная производительность Ext4 достигается при ипользовании опций noatime и nojournal в сочетании с планировщиком CFQ. Для Ext4 также наблюдается небольшой рост производительности при использовании на накопителях eMMC, даже без поддержки TRIM, при включенной опции discard. F2FS работает отлично при использовании настроек по умолчанию и при включении noatime. Наилучшие показатели продемонстрировал планировщик CFQ, от которого немного отстал ROW.<center><img src="http://www.opennet.ru/opennews/pics_base/0_1372832216.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></center>
URL: http://permalink.gmane.org/gmane.linux.embedded.celinux.deve...
Новость: http://www.opennet.ru/opennews/art.shtml?num=37339
Кто же в итоге выиграл при максимальных нагрузках на SSD?
Победила "Дружба" - пробурчал дровосек...В смысле, с результатами дело ясное что дело темное: в зависимости от условий, типа нагрузки и опций результаты варьируются. И однозначный победитель не определяется. Что еще веселее у разных носителей разные алгоритмы и они по разному накладываются на разные ФС.
Так что единственный вывод - носители могут быть достаточно индивидуальны и единый рецепт вообще отсутствует.
Ах да, и они в основном уделили внимание SD картам на эмбеднутых девайсах. Так что SSD вообще отдельный ворос.
> В общем виде скорость чтения в основном упирается в пропускную способность накопителя.Спасибо Кэп! :D
почему CFQ? NOOP вроде же позиционировался, как планировщик, который все операции возлагает на контроллер как раз ССД, потому что тот сам знает, как лучше, э?
> почему CFQ? NOOP вроде же позиционировался, как планировщик, который все операции возлагает
> на контроллер как раз ССД, потому что тот сам знает, как
> лучше, э?Видать CFQ умнее оказался :-)
> Видать CFQ умнее оказался :-)Все равно хомячки-оптимизаторы будут жрать BFQ, потому что модно и молодежно.
это другое
"это другое" - это не аргумент.
> почему CFQ? NOOP вроде же позиционировался, как планировщик, который все операции
> возлагает на контроллер как раз ССД, потому что тот сам знает, как лучше, э?Обратите внимание: при большом размере кэша тип шедулера пофигу. При малом - уже не совсем.
Ну а для обычных флешек, которые вставляются в USB, какие настройки оптимальны? Я знаю только про nojournal.
Для обычных флэшек вааще не нужна журналируемая ФС, туда можно ext2 если по каким-то причинам фат не устраивает.
> Для обычных флэшек вааще не нужна журналируемая ФС, туда можно ext2 если
> по каким-то причинам фат не устраивает.Есть же какая-то JFFS2, специально для флешек. Во всяком случае, внезапное выключение, если ОС загружена с Ext2-флешки может привести к печальным последствиям.
У меня система потом делала проверку и загружалась. Но файлы пару раз терялись, к счастью ненужные.
> У меня система потом делала проверку и загружалась. Но файлы пару раз
> терялись, к счастью ненужные.А я нужные терял. Так что лучше не рисковать.
глубоко в теории нужные и не потеряются. пропасть могут тока свежие( в теории)
конкретно убить мне удавалось почемута только xfs.
reiser тоже както раз подсдох но вылечился часа за 2 с полной перестройкой дерева.
> пропасть могут тока свежие( в теории)"Свежий файл" - это, например, директория которая была перезаписана из-за добавления ненужных файлов. В итоге при безопасных на первый взгляд операциях может потеряться всё её содержимое.
> терялись, к счастью ненужные.А еще бывает что надо тебе на флешку записать файло. Вот прям ща. А тебе и говорят: "отдыхайте, сегодня работать не будем!" (read-only file system).
> Есть же какая-то JFFS2, специально для флешек.Не для USBшных
> Для обычных флэшек вааще не нужна журналируемая ФС,Ага, а потом выдернешь флешку на горячую необдуманно и потом полчаса fsck гонять. Или на выбор вас посетит внезапное западло в наименее подходящий момент.
Кстати идея: область FAT на флешках подразумевает частые апдейты и прочая и поэтому некоторыми носителями обрабатывается специально. Можно попробовать журнал упхать ровно по этой области.
> Кстати идея: область FAT на флешках подразумевает частые апдейты и прочая и
> поэтому некоторыми носителями обрабатывается специально. Можно попробовать журнал упхать
> ровно по этой области.usb flash drive разве не размазывают всё одинаково на весь объём?
> usb flash drive разве не размазывают всё одинаково на весь объём?Каждый др@чит как он хочет. Если почитать статью и погулять по ссылкам, можно найти массу чудесатых описаний различных wear leveler'ов. Некоторые - одинаково. Некоторые - рассматривают область fat отдельно. Алгоритмы везде разные. Как и фактическая геометрия.
Иногда встречаются реально чудесатые экспонаты. Наример в устройствах с triple level cell размер блока может быть не кратен степени двойки даже. Такая вот чудесатая хрень (которую надо советовать врагам).
> Для обычных флэшек вааще не нужна журналируемая ФС, туда можно ext2 если
> по каким-то причинам фат не устраивает.По причинам размера файла, скорее всего. Но можно и ext4 -o ^journal.
> Ну а для обычных флешек, которые вставляются в USB, какие настройки оптимальны?
> Я знаю только про nojournal.Целиком зависит от того, как собираешься использовать. Если не как ОС, посмотри ещё на noatime|realatime, nodiratime, sync|async. Если просто как обычную флешку и поддержка оффтопика не нужна - обычная Ext2 с настройками по дефолту.
> и поддержка оффтопика не нужна - обычная Ext2 с настройками по дефолту.И потом выдернув флеху по запаре без размонтирования - гоняй fsck или налетай на побитую ФС. Очень приятно приложиться фэйсом об тэйбл в самый интересный момент.
Флешки надо монтировать с sync, я считаю. Индикатор активности перестал моргать – можно дёргать.
> Флешки надо монтировать с sync, я считаю. Индикатор активности перестал моргать – можно дёргать.Как вы понимаете, мало кто заморачивается смотрением на какие-то там индикаторы. Схапал и пошел. Безжурнальная система при этом может быть серьезно факапнута.
Без журнала плохо везде, но на съемных носителях - особенно.
Видимо f2fs (создавалась из расчёта на флешки/ссд, можно сразу использовать с настройками по умолчанию), только из-коробки её сейчас нигде нет :(
> Видимо f2fs (создавалась из расчёта на флешки/ссд, можно сразу использовать с настройками
> по умолчанию), только из-коробки её сейчас нигде нет :(На свежих линуксах разве не?
Другое дело, что дохнет она быстро. Вот это действительно проблема.
> На свежих линуксах разве не?Да, на свежих ядрах оно есть. Но...
> Другое дело, что дохнет она быстро. Вот это действительно проблема.
Дело даже не в том что дохнет, дело в том что fsck нету. Так что потом еще и корректность проверять нечем. А вот это уже совсем проблема, да.
XFS у меня первое же выключение питания не пережила.
У вас какие-то проблемы с жёстким диском, видимо он не корректно реализует команду FLUSH или ошибка в ядре которое у вас установленно. У меня на файлопомойке XFS поверх LVM, torrent пишет, неожиданные выключения питания несколько раз в месяц несколько лет, проблем нет.
> XFS у меня первое же выключение питания не пережила.А это в какой версии ядра и при каких условиях? А то у меня пачка томов в XFS не в курсе такого безобразия.
> А это в какой версии ядра и при каких условиях? А то
> у меня пачка томов в XFS не в курсе такого безобразия.Внезапно вырубилось электричество. UPS не было. После включения электричества машина не загрузилась. Пришлось делать xfs_repair, после него убились несколько тысяч файлов.
Ядро было какое-то из третьей ветки, 3.2, что ли.
> Внезапно вырубилось электричество. UPS не было.В целом у меня несколько томов с XFS в течение сколькиъ-то лет (начиная с 2.6.28) пережили серию негуманных экспериментов. Тут и внезапные слеты питания когда в упсе батарейка сдохла, и несколько весьма жестких локапов в процессе системных экспериментов, и чего там еще. Да еще и дисковый буфер огромный (16Гб оперативы на борту).
> загрузилась. Пришлось делать xfs_repair, после него убились несколько тысяч файлов.
Ого. Как-то много. Может у вас оборудование врет насчет сброса кэша и/или барьеры не работают?
> Ядро было какое-то из третьей ветки, 3.2, что ли.
Странно. В том плане что я за эн лет сделал немало потенциально проблемных операций а XFS не факапнулся ни разу. Правда под систему я его не пользую, только под большие файлы данных.
- По милицейской статистике маньяк убил 60 человек в нашей подворотне и даже знакомого соседа убили!
- Странно. В том плане что я за эн лет сделал немало потенциально проблемных операций с _подворотней_ не факапнулся ни разу. Правда я один через подворотню не хожу, только вместе с грузчиками переношу крупногабаритную мебель.
А она случайно не поверх RAID'а, сделанного LVM'ом, жила?
в линуксе все обычно туева хуча файловых систем и большинство из них шустрые как истребитель, но ломучие как жидули. ext4 победил потому что затестирован по самые помидоры. вот теперь мне интересно какой линуксоид в здравом уме ставит что-то отличное от ext4 без журнала? ну и смысл от этой кучи ФС если все они чуть более чем экспериментальные? джаст фор фан такой джаст фор фан :))
На HDD - ReiserFS v3.6 over LVM, на USB флешки - Ext2.
> На HDD - ReiserFS v3.6 over LVM, на USB флешки - Ext2.За что вы нас так не любите? :)
У первого утилиты fsck ни к черту, у второго нет журнала. Конечно если у вас ничего ценнее порнухи с торентов нету - оно сойдет. Если факапнется - перекачаете. А вот для более ответственных применений такой сетап только врагам можно советовать.
Ext2 туда, где критичны циклы чтения/записи, при особых случаях - ФС для того предназначенные. А на десктопе - да, только Ext4 и имеет смысл использовать (ну может быть когда-нибудь это будет Btrfs, хотя вряд ли...).
смысл в задачах и фичах...
в бтрфс пилят модные фичи (хотя - странным образом, читайте Шишкина http://habrahabr.ru/post/108629/)
extX - поддерживают преемственность прошлых версий и "достаточную" производительность
xfs - мультимедийные данные...
reiserfs - интересная архитектураато как в мире виндовс - для всего одна Фс (ну две с половиной, если не только десктопы/сервера, трупик ФАТ и экстФС) и для всего она так-себе, заявленные показатели м.б. не имплементированы (в тек. реинкарнации виндовс) ну т.п.
> в бтрфс пилят модные фичи (хотя - странным образом, читайте Шишкина http://habrahabr.ru/post/108629/)
> extX - поддерживают преемственность прошлых версий и "достаточную" производительностьС ними всё ясно.
> xfs - мультимедийные данные...А чем оно лучше ext для этой цели?
> reiserfs - интересная архитектура
И что оно даёт? Какие конкретно "интересности"?
>> xfs - мультимедийные данные...
> А чем оно лучше ext для этой цели?Если у вас один процессор или домашняя дисковая подсистема то скорее всего ничем, если же у вас несколько процессоров и дисковая подсистема позволяет то у XFS скорость операций растёт практически линейно с увеличением процессоров. ext4 пока только приближается к этим показателям.
>> reiserfs - интересная архитектура
> И что оно даёт? Какие конкретно "интересности"?tail pack например
> tail pack напримерНынче подобные по смыслу фокусы, как минимум, хранение мелких файлов прямо в метаданных - умеют как минимум EXT4 и btrfs.
А еще вы забилы уточнить пару моментов:
1) Этот самый tail pack в рейзере - известный источник проблем. Что вам тот гражданин сделал что вы ему заведомо грабельную фичу сватаете?
2) У рейзера 3.х плохие утилиты восстановления (fsck) которые временами окончательно добивают том совсем вместо его починки.
3) А рейзер 4, у которого интересная архитектура - вообще сырой недопилок с непонятными перспективами. Работает над ним целый Шишкин. А работы там - как на пять btrfs'ов, если по нормальному делать то что задумано. Ну в общем лет через 500 такими темпами может что и получится.И главное: никогда не читайте мнение автора о его собственной программе и наиболее очевидных конкурентах. Это почти всегда заведомо необъективный буллшит. У конкурентов всегда оказывается масса недостатков, ну а свое - оно как известно не пахнет...
> Нынче подобные по смыслу фокусы, как минимум, хранение мелких файлов прямо
> в метаданных - умеют как минимум EXT4 и btrfs.Хранить данные в метаданных - это агли хак.
> 1) Этот самый tail pack в рейзере - известный источник проблем.сам ты источник проблемы
> 2) У рейзера 3.х плохие утилиты восстановления (fsck) которые временами окончательно добивают том совсем вместо его починки.Покажи хоть один багрепорт в листе рассылки за последние пять лет, балаболка
> И главное: никогда не читайте мнение автора о его собственной программе и
> наиболее очевидных конкурентах. Это почти всегда заведомо необъективный буллшит. У конкурентовБулшит - это в Btrfs вместо B-деревьев, что и было показано на популярном языке.
> Булшит - это в Btrfs вместо B-деревьев, что и было показано на популярном языке.На мой взгляд, он перестарался с популяризацией. Популяризация хороша тогда, когда простыми словами объясняет сложные вещи, но когда всё сводится к "btrfs говно и не лечится, а я умная в белом пальто стою красивая", немного пересыпается поцреотизмом и академическим ЧСВ, то это уже, извините, не популяризация, а речь политика. Ну или, если хотите, популяризация для быдла.
Главная проблема райзера - не более 1024 буферов чтения/записи, в результате чего запись больших файлов медленная.
Для XFS одна из главных фич (на мой взгляд) - agsize=4g, что позволяет писать (разные и большие) файлы в столько потоков, сколько ядер у проца (Numa-oriented, естественно, а не Интеловские кеш-на-два-ядра извраты).
Плюс райзера - быстро пишет много мелких файлов. На мой взгляд, единственный.
> Хранить данные в метаданных - это агли хак.Да нормально - если файл мелкий, сразу же и прочитается. Механике меньше дергать головы, да и NAND поимеет некий профит, т.к. ему наиболее удобно читать последовательно и желательно побольше. Так что если удастся странсформировать 2 мелких чтения/записи в 1 покрупнее - это замечательно.
>> 1) Этот самый tail pack в рейзере - известный источник проблем.
> сам ты источник проблемыДостаточно скормить гугле нечто типа reiser tail pack и узнать много нового и интересного :).
Хотя если уж мы о проблемах - рейзер вообще источник проблем. У авторов aMule например рейзер целиком все данные на серванте потерял после fsck.
>> 2) У рейзера 3.х плохие утилиты восстановления (fsck) которые временами окончательно
>> добивают том совсем вместо его починки.
> Покажи хоть один багрепорт в листе рассылки за последние пять лет, балаболкаА нет смысла репортить - как минмум 1 ситуация такого плана объявлена "known issue".
Описанная ситуация в которой это возможно: если на томе отформаченом в рейзер лежит образ диска, и так получилось что он тоже был с рейзером - fsck рейзера очень даже может взять дерево из образа и попробовать "починить" на основе этих данных несущий том. Результатом станет полный дестрой, разумеется. Разработчики рейзера на это скзали "known issue" и предложили воркэраунд - "не храните образа диска с reiserss на томе reiserfs". Что, конечно, замечательно, но риск факапов полностью не отменяет. Сколько там еще поодбных ситуаций - понятия не имею. Вот эта точно есть - это сами же разработчики рейзера и описали как известную проблему.
А то что багрепортов мало - посмотрите что в основном использует народ. Там и багрепорты, собственно. Не потому что EXT4 бажный, а потому что повсеместный :).
> Булшит - это в Btrfs вместо B-деревьев, что и было показано на популярном языке.
Булшит - это в основном статьи Шишкина. Себе он сделал фантастического размера скидки, зато к btrfs докопался что в синтетических случаях, дескать, может быть так и сяк. Тем не менее, пусть он сначала попробует столько же возможностей реализовать, чтоб оно при этом не глюкало постоянно. А я потом тоже найду к чему докопаться :). Благо, при должном желании свалить на лопатки можно любую ФС.
> А чем оно лучше ext для этой цели?Быстрей практически во всех отношениях. Единственное где может проиграть - удаление каталогов со 100000 файлов.
> Быстрей практически во всех отношениях.Да хрен там. Только при работе с мелочью и не во всех операциях. На больших файлах рулит XFS, особенно в многодисковых конфигах. А EXT4 - просто достаточно резвый и труднораздалбываемый, умеет discard (для SSD актуально). F2FS - предсказуемо надирает попы на флеше. Но пока сыроват (только выкатили же) и fsck нету.
XFS также "discard (для SSD актуально)"
> XFS также "discard (для SSD актуально)"Зато он с мелочью работает плоховато. Его конек - быстрая работа с большими файлами. SGI - это ж были рабочие станции для видеомонтажа и тому подобного. Ну вот что-то такое для XFS'а и хорошо.
У вас не актуальные данные. XFS сильно допилили по работе с мелочью, кое-где он и Ext4 обскакивал. Правда, потом Ext4 тоже подкручивали, так что не знаю, кто там сейчас шустрее, но катастрофических отставаний точно нет.
> У вас не актуальные данные.У меня вполне себе актуальный тридесятый кернель и тома в XFS. Ты мне хочешь рассказать о их свойствах? Ну попробуй :).
Спору нет, XFS допилили. Резвее стало. Но не быстрее конкурентов типа ext4 и рейзера.
> XFS сильно допилили по работе с мелочью,
А все-равно слоупочит он как-то на разлапистых иерархиях с мелочевкой.
> кое-где он и Ext4 обскакивал.
Может кое где оно и обскакивает, но в целом - впечатления при работе с мелочью хуже чем в случае с EXT4. Мне нравится как оно с большими файлами работает - вот там оно себя оправдывает. И фрагментация минимальна, и скорость ядреная. А вот работа с разлапистыми иерархиями из мелочи мне не понравилась, ext4 быстрее обычно отрабатывает.
> Правда, потом Ext4 тоже подкручивали, так что не знаю, кто там сейчас шустрее,
> но катастрофических отставаний точно нет.Кроме случая когда что-то делается с иерархией из мелочи. В общем как оно было хорошо для больших файлов так и осталось. Принципиально свойства дизайна никуда не изменились.
> xfs - мультимедийные данные...А как она их отличает от не мультимедийных данных...
>> xfs - мультимедийные данные...
> А как она их отличает от не мультимедийных данных...Он имел ввиду дампы блюреев, матроски, RAW поток FullHD-TV со спутника.
XFS ваще няшка, 15-терабайтный файлик за 5 сек. удаляет. :)
> Он имел ввидучто XFS хорошо работает с "большими" файлами и не очень хорошо с мелкими. Эта мысль прививается всем? Cколько лет XFS и какие тогда файлы назывались "большие". Как она с ними управлялась ума не приложу.
анонимные вопросы... - кто они :)
http://oss.sgi.com/projects/xfs/
читать ограничения и сравнивать с др. (реализациями, замечу, а не теорией)
> что XFS хорошо работает с "большими" файлами и не очень хорошо с
> мелкими. Эта мысль прививается всем? Cколько лет XFS и какие тогда
> файлы назывались "большие". Как она с ними управлялась ума не приложу.Дело не в том. Дело в том что если вы захотите перелопатить 100 000 файлов, на куче мелочи основное время будет работа с метаданными. А на больших файлах - с данными. Вот с метаданными XFS работает неспешно в ряде ситуаций. Так что в результате работа с иерархией из кучи мелочи будет тормознее чем в других ФС. Только и всего. Никто там не оптимизил особо этот юзкейс, в линевом ядре 3.5 и новее работу с метаданными несколко оптимизнули, но в целом оно все-равно не очень быстрое на таких иерархиях. По сравнению с ext4 и прочими.
>[оверквотинг удален]
>> файлы назывались "большие". Как она с ними управлялась ума не приложу.
> Дело не в том. Дело в том что если вы захотите перелопатить
> 100 000 файлов, на куче мелочи основное время будет работа с
> метаданными. А на больших файлах - с данными. Вот с метаданными
> XFS работает неспешно в ряде ситуаций. Так что в результате работа
> с иерархией из кучи мелочи будет тормознее чем в других ФС.
> Только и всего. Никто там не оптимизил особо этот юзкейс, в
> линевом ядре 3.5 и новее работу с метаданными несколко оптимизнули, но
> в целом оно все-равно не очень быстрое на таких иерархиях. По
> сравнению с ext4 и прочими.и потому возвращаемся к теме "задача", а не пытаемся сыпать в одну кучу :)
> и потому возвращаемся к теме "задача", а не пытаемся сыпать в одну кучу :)Задача у большинства людей проста: ФС должна хранить данные. Надежно. Не тормозя и прочая.
Ну вот XFS хорошо справляется с хранением больших файлов. Что и понимали под мультимедией. А вот как оно работает с обширными иерархиями из мелкоты - мне вот например совсем не нравится. Ничего там хорошего особо нет.
Да, серебряных пуль не бывает. Кто-то хорош в одном, кто-то в другом. А для тех кто не знает что ему надо - есть EXT4, который полимеры особо нигде не сливает по крупному.
Это вылечено уже, причем с год.
да древние предрассуюки это всё, в районе 5 версий ядра назад его сильно подкрутили. Сейчас - вполне универсальная FS.
> сильно подкрутили. Сейчас - вполне универсальная FS.Универсальная - это ext4. А XFS хоть и подкрутили но фундаментальные свойства не изменились особо. Лично мне не нравится как он работает с большими иерархиями мелочевки всякой.
>> xfs - мультимедийные данные...
> А как она их отличает от не мультимедийных данных...она их не отличает, для дифференциации существует некий посредник, с элементами разума :)
> А как она их отличает от не мультимедийных данных...По размеру. XFS неважно работает с мелочевкой в больших количествах, но на больших файлах - очень шустр.
вот для этого и нужно осмысленное разделение - что и где хранить
универсальных решений нет, и выбор - это плюс
> вот для этого и нужно осмысленное разделение - что и где хранить
> универсальных решений нет, и выбор - это плюсВот именно так я и сделал - на XFS живут относительно крупные файлы. А вот держать на нем разлапистые иерархии мелочи - чисто технически конечно можно. А чисто практически работа всего этого будет оставлять желать.
Шишкин во многом неправ.
> Шишкин во многом неправ.Просто себе он сделал феерического размера скидки, а по конкурентам прошелся по максимуму. Теретически рейзер4 крут. Практически это злостный недопилок, который некому пилить.
>> Шишкин во многом неправ.
> Просто себе он сделал феерического размера скидки, а по конкурентам прошелся по
> максимуму.Дело в беспрецедентном пиаре btrfs, умело организованном группой людей. Поэтому и спрос
с них больше. Ибо тысячи людей ставят себе эту так называемую "файловую систему",
полностью доверяясь рекламе, и только 1% из них задаётся вопросами: "я записал три
маленьких файла на гигабайтную партицию, и получил "ноу спейс он дивайс". Куда делось
моё дисковое пространство?". Остальные 99% покорно идут в магазин покупать новый диск. А
тому одному проценту умело пудрят мозги. Вы только почитайте лист рассылки btrfs.
За одно то, что открыл глаза, Шишкину спасибо.
> в линуксе все обычно туева хуча файловых систем и большинство из них
> шустрые как истребитель, но ломучие как жидули. ext4 победил потому что
> затестирован по самые помидоры. вот теперь мне интересно какой линуксоид в
> здравом уме ставит что-то отличное от ext4 без журнала? ну и
> смысл от этой кучи ФС если все они чуть более чем
> экспериментальные? джаст фор фан такой джаст фор фан :))В некоторых ОС подобная экспериментальная ФС является практически единственным вариантом (NTFS в винде, ZFS в соляре).
> В некоторых ОС подобная экспериментальная ФС является практически единственным вариантом (NTFS в винде, ZFS в соляре)Чем же ZFS экспериментален? Тем более - в Солярке? O_o
Даже во Фряху уже вполне юзабельна и уверенно чувствует себя.
> ну и смысл от этой кучи ФС если все они чуть более чем
> экспериментальные? джаст фор фан такой джаст фор фан :))Поведайте нам, что там у энтерпрайза используется?
> Поведайте нам, что там у энтерпрайза используется?Очевидно же - Enterprise File System
> экспериментальные? джаст фор фан такой джаст фор фан :))Действительно, намного лучше как в фряхе: тормозной и ынтырпрайзный ZFS, который на SD-карте больше похож на пудовую гирю подвешенную к воробью, и древний и тормозной UFS у которого оптимизации под флеш вообще отсутствуют.
Вот это я понимаю - забойный ассортимент: под озвученную задачу вообще нормальных ФС не обнаружено, зато на линуксоидов потявкали. Бсдшники в диком виде, чо.
> Действительно, намного лучше как в фряхе: тормозной и ынтырпрайзный ZFS, который на
> SD-карте больше похож на пудовую гирю подвешенную к воробью, и древний
> и тормозной UFS у которого оптимизации под флеш вообще отсутствуют.trim есть, 4k есть. Назови остальные "оптимизации под флеш" которые знаешь.
> trim есть,Ну да, не прошло и 20 лет. Пожалуй на этом оптимизации и заканчиваются.
> 4k есть.
А оно тут вообще каким боком? Надеетесь угадать и попасть в страницу нанда? А что если страница не 4K? Все, болт? А как насчет erase block или даже групп блоков? На это забьем? :)
> Назови остальные "оптимизации под флеш" которые знаешь.
Изменение стратегий аллокации в основном.
1) Надо стараться оперировать большими блоками, желательно последовательно.
2) Стоимость seek иная чем у HDD и это некисло бы учесть.
3) Те кто реально целился на флеш - позволяют вообще fine tune'ить стратегии под конкретный накопитель и его свойства. F2FS - вот это конкретно так оптимизировано на флеш, да. Во всех закоулках дизайна. А UFS типичная дисковая фс для механики, древняя и бестолковая.
"Устриц не ел, но мнение имею...". :D
> "Устриц не ел, но мнение имею...". :DДа, Изя, это как раз про тебя.
> "Устриц не ел, но мнение имею...". :DСказал пользователь Шindoшs XP, советующим всем ставить FreeBSD.
Да, было дело. бтрфсцк умеет только падать на ассертах при ошибках фс, больше нихрена не умеет.
Этой осенью будет получше, поток больших изменений иссяк, давно уже не слышно победных заявлений о небывалом могуществе, значит начали разбираться с ошибками. Но вообще это провал конечно, с учетом такой поддержки как от Линуса "это будет главная мейнстрим файловая система, а пока перетерпим на ext4" -цать лет назад, а воз и ныне там. Не осилили.
> "это будет главная мейнстрим файловая система, а пока перетерпим на ext4"
> -цать лет назад, а воз и ныне там.А что - не осилили? Там баги более-менее поотлавливали - начались оптимизации и донаворачивание фич типа raid5/6. А то что никто попы не рвет отчаянно -
> Не осилили.
Вы так говорите, как будто вышла финальная версия линуха, завтра наступает конец света, так что уже можно подвести окончательные итоги.
>Вы так говорите, как будто вышла финальная версия линуха, завтра наступает конец света, так что уже можно подвести окончательные итоги.да уже года 4 пхороникс победные графики бенчмарков рисует, пора уже.
> да уже года 4 пхороникс победные графики бенчмарков рисует, пора уже.Спору нет. И это время приближается.
А насчет победных - это где как, где как. Идите вон F2FS на флешовом накопителе победите. Слабо? :)
А что reiser4?
> А что reiser4?
> А что reiser4?Она утонула©
Что сразу "утонула"?! Вы нас недооцениваете - мы любим разнообразие! http://www.youtube.com/watch?v=9jQ_tPm0J2EУ Шишкина впрочем таких катастрофических отказов обычно не случается - все заранее прикидывают перспективы иметь дело с сложным но категорически недоделанным экспонатом и заранее догадываются чем это закончится. Поэтому обчно запуск сразу ссут проводить. Без масс-дестроя пользовательских данных.
Значит я правильно сделал, что у меня ext4. Как раз устойчивость к внезапным отключениям ключевой параметр.
> внезапным отключениям ключевой параметр.Если у вас так часто слетает питание - не лишне UPS купить. На файловую систему надейся, а сам не плошай.
> Если у вас так часто слетает питание - не лишне UPS купить.
> На файловую систему надейся, а сам не плошай.Моя практика показывает, что не все UPS одинаково полезны.
Даже боюсь спраштвать а что ты с ними делаешь?
> до вывода fsck предупреждения о появлении автоматически невосстановимой ошибки было произведено 1406 циклов выключений питанияА почему это вообще произошло? Разве журнал не предназначен как раз что бы такого не происходило?
>> до вывода fsck предупреждения о появлении автоматически невосстановимой ошибки было произведено 1406 циклов выключений питания
> А почему это вообще произошло? Разве журнал не предназначен как раз что
> бы такого не происходило?Давайте на вас оденем шлем и ударим 1406 раз по стене. Упали в обморок? Интересно, почему - шлем как раз предназначен, чтобы этого не происходило.
Наденем, конечно. *бьёт себя учебником русского языка по голове.*
> *бьёт себя учебником русского языка по голове.*А шлем надели? :)
в истории ревизий документа: M. Filippov, K. Kozhevnikov, D. Semyonov
в контактах: max.filippov и artemi.ivanovтакой прямо Тим Бёрд :)
Только из-за этого поста скачал-таки пдфку
Старательно обошли случайное чтение-запись из одного файла (база данных, нагруженная одна таблица) в несколько потоков.Внезапно при этом получается что CFQ + ext* = запись в один поток и цифры не такие красивые.
> Старательно обошли случайное чтение-запись из одного файла (база данных, нагруженная одна таблица) в несколько потоков.База, многопотоков, на NOR/NAND-флеше? Заголовок темы, а лучше PDF-ку читал?
Да чо там, все ынтырпрайзники на SD картах с базами работают :)
> Наилучшие показатели продемонстрировал планировщик CFQБез BFQ/BFQ+EQM не интересно.
> Без BFQ/BFQ+EQM не интересно.С ним и так все ясно (http://www.linux.org.ru/forum/general/9312470 например).
Лубунта 12.10. Что самое интересное, у меня на HDD с deadline всё вешалось при копировании/перемещении больших файлов. Сменил на cfq - стало значительно лучше, хотя загрузка проца всё равно до 30% временами подпрыгивает. На Хабре читал, что всё должно быть как раз наоборот. И ложка дёгтя: на винде эти операции у меня вообще проц не грузят.
> И ложка дёгтя: на винде эти операции у меня вообще проц не грузят.А теперь запусти дефрагментацию.
И почувствуй разницу.
> Лубунта 12.10. Что самое интересное, у меня на HDD с deadline всё
> вешалось при копировании/перемещении больших файлов. Сменил на cfq - стало значительно
> лучше, хотя загрузка проца всё равно до 30% временами подпрыгивает. На
> Хабре читал, что всё должно быть как раз наоборот. И ложка
> дёгтя: на винде эти операции у меня вообще проц не грузят.Если этот HDD в NTFS отформатирован, и через fuse подключен, то это просто очевидно, и нисколько не интересно...
А если нет, то спрашивается - а это копирование/перемещение вообще там (на винде) производятся в реале, или откладываются на потом? Прооверить просто - вызвать диалог безопасного извлечения флешки/диска, когда Винда скажет (сделает вид?), что все, запись большого файла закончена... Или не о внешнем (USB) диске речь идет, а о штатно подключенном?Еще один момент - в Лубунте (и не только) из-под иксов, по-моему, все флешки/внешние USB диски чере fuse монтируются, что изрядно доставляет... Как вариант, попробуйте хоть в окне консоли смотировать флешку через sudo mount, или что там у Вас (типа из-под рута), и сравните скорость копирования. Заодно, может, и вешаться с deadline перестанет...
Вы оба о чём-то о своём (слышите голоса?) В принципе, это был больше вопрос, чем вброс, но вы увидели только слово "винда". ЛГМ прогрессирует, пора к доктору.
> лучше, хотя загрузка проца всё равно до 30% временами подпрыгивает.А у тебя файловой системой NTFS, через FUSE, да? Ну так пользуйся нативными файловыми системами из комплекта ядра линуха - и твои волосы будут мягкими и шелковистыми, а загрузка проца - близкой к нулю :). А то FUSE контексты user-kernel немилосердно переключает и это будет тормозить. Линь может работать с NTFS, но это не значит что это оптимальное решение. А вот если 30% проца жрется например на ext4 - я сильно удивлюсь, ибо у меня столько даже на роутере не жрется на работу с ФС.
> Оптимальная производительность Ext4 достигается при ипользовании опций noatime и nojournal
> работает отлично при использовании настроек по умолчанию и при включении noatime.Вывод? Опцию noatime для ФС нужно сделать дефолтной и занести в стандарт POSIX!
> В связи с этим авторы исследования не рекомендуют использовать Btrfs и F2FS в конфигурациях с ненадёжным питанием.
Кто бы сомневался. "Классика" "семёрка" — ваше всё. :))
> Вывод? Опцию noatime для ФС нужно сделать дефолтной и занести в стандарт POSIX!Вы хоть знаете, что это за опция и для чего она предназначена?
>> Вывод? Опцию noatime для ФС нужно сделать дефолтной и занести в стандарт POSIX!
> Вы хоть знаете, что это за опция и для чего она предназначена?Да.
И что же? Как только вы ответите на него - автоматически придёт понимание, что atime - нужная функция и выключать её совсем не надо.
> И что же?Оверхед на перезапись метаинформации.
> Как только вы ответите на него - автоматически придёт
> понимание, что atime - нужная функция и выключать её совсем не
> надо.А я вот выключаю везде, где она есть (NTFS, UFS2, ZFS), и от этого мне ни разу не поплохело.
>>> Вывод? Опцию noatime для ФС нужно сделать дефолтной и занести в стандарт POSIX!
>> Вы хоть знаете, что это за опция и для чего она предназначена?
> Да.Врешь как Изя.
> Кто бы сомневался. "Классика" "семёрка" — ваше всё. :))Простите, не наше, а ваше :)
(Когда под хрюшу окончательно перестанут выпускать софт и дрова.)
> Опцию noatime для ФС нужно сделать дефолтной и занести в стандарт
> POSIX!noatime, как сказали рядом, может кое-что сломать. А relatime, при небольшой разнице, давно по умолчанию[1]. Обо всём этом в man mount есть.
> Вывод? Опцию noatime для ФС нужно сделать дефолтнойВот это может быть и повод для обсуждения.
> и занести в стандарт POSIX!
А вот это - это как? :)
> Кто бы сомневался. "Классика" "семёрка" — ваше всё. :))
Я почему-то думал что у тебя XP...
В свое время занимался подобной фигней. На том и порешил - нету ничего лучше, быстрее и надежнее (по совокупности), чем ext с отключенным журналом. %)
Че за фигня, на какой странице графики ext4 random write, не смог найти, есть только для f2fs и btrfs?
