форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Оценка производительности файловой системы F2FS, включённой ..."	+/–
Сообщение от opennews on 22-Фев-13, 10:11
Ресурс Phoronix провел (http://www.phoronix.com/scan.php?page=article&item=linux_f2f...) серию тестов работы файловых систем на SSD-накопителях. Основной целью данных тестов была проверка, как новая файловая система F2FS (https://www.opennet.ru/opennews/art.shtml?num=35667) соотносится с другими файловыми системами в ситуации, когда носитель представляет собой массив NAND flash памяти, на работу с которой в основном и оптимизирована файловая система F2FS.   В тесте приняли участие файловые системы F2FS, Btrfs, EXT3, EXT4, XFS и JFS. Тестирование производилось на 160Гб накопителе Intel SSD SA2M160. -  В тесте Flexible IO Tester 1.57 первое место занял ext4. Второе место поделили между собой JFS и EXT3. F2FS показал в данном тесте весьма неважный результат, выиграв только у btrfs и проиграв всем остальным участникам тестирования. -  В семействе тестов FS-Mark V3.3 F2FS показал отличный результат, заняв первое место. На втором месте с довольно небольшим отрывом оказался JFS, который очень хорошо показал себя в этом семействе тестов. За третье место соревновались XFS и EXT4. Самые плохие результаты в этом семействе тестов показал ReiserFS, заметно отставший от других файловых систем. -  В тесте dbench F2FS победил с огромным отрывом. На втором месте оказался JFS, который тем не менее проиграл победителю более чем в полтора раза. На 3-м месте оказался ext4, отставший от лидера в примерно 2.5 раза. Последнее место в данном тесте занял ReiserFS. -  В тестах на чтение IOZone F2FS показал вполне приличный результат, на равных соперничая с JFS. XFS и EXT4. Все этим файловые системы показали очень близкий результат. Самыми медленными в этом семействе тестов показали себя EXT3 и Btrfs. -  В тестах на запись IOZone F2FS опять был в рядах лидеров. При этом разница между F2FS, EXT3, EXT4, BTRFS и XFS была незначительной. Медленней всех данные тесты выполнили JFS и ReiserFS, тем не менее, отставание от лидеров было достаточно скромным. -  В тесте compile bench - compile лидерами выступили btrfs и ext4, поделившие первое место с очень близкими результатами. Второе место заняли EXT3 и XFS, показавшие очень близкий друг к другу результат. За третье место боролись F2FS и JFS, опять же показавшие близкие результаты. Самой медленной ФС в данном тесте был ReiserFS. -  В тесте compile bench - initial create первое место разделили XFS и EXT4. Второе место занял EXT3, а третье - btrfs. F2FS и JFS разделили 4-е место, показав близкие результаты. Самым медленной ФС в этом тесте опять был ReiserFS. -  В тесте PostMark F2FS занял первое место, практически разделив его с XFS и EXT4, отставшими от F2FS на незначительную величину. От группы лидеров немного отстал JFS. Хуже всех в данном тесте опять выступил ReiserFS. В целом по результатам данного теста можно сделать вывод, что F2FS является вполне заслуживающим внимания вариантом в случае использования SSD. Также можно отметить неожиданно высокие результаты JFS в ряде тестов и достаотчно неожиданный проигрыш ReiserFS (считающейся довольно быстрой ФС) в значительном количестве тестов. Отдельно было проведено (http://www.phoronix.com/scan.php?page=article&item=linux_f2f...) тестирование файловой системы F2FS на SDHC карте памяти.  В качестве тестового носителя в данной серии замеров выступала карта памяти Patriot LX Series 16GB Class 10 SDHC. Поскольку SD карты намного медленнее чем SSD, было решено ограничиться соперниками в виде EXT4 и Btrfs. Кроме того, отмечается, что неплохим кандидатом на тестирование могла бы стать ФС Tux3, однако она пока не внесена в основное ядро Linux. -  В тесте Flexible IO tester - оценке производительности доступа к файлам F2FS показал наилучший результат. Btrfs немного отстал от лидера, а ext4 оказался в этом тесте медленнее всех, проиграв примерно на треть. -  В тестах FSMark и Dbench F2FS также был лидером, заметно обогнав конкурентов. Второе место в обоих тестах занял EXT4, btrfs оказался в указанных тестах самой медленной ФС. -  В тесте IOZone - операции чтения с размером блока в 4Кб F2FS и EXT4 показали очень близкие результаты. Btrfs заметно отстал от обоих лидеров. -  В тесте IOZone - при записи с размером блока в 4Кб лидером стал ext4, тогда как F2FS и Btrfs несколько отстали от лидера, показав близкий результат. -  В тесте IOZone - операции чтения с размером блока в 64Кб F2FS и EXT4 опять показали близкие результаты, с некоторым преимуществом в пользу F2FS. Btrfs отстал от соперников более чем в 2 раза. -  В тесте IOZone - при зависи с размером блока в 64Кб лидером стал ext4. Btrfs показал близкий результат. F2FS заметно отстал от обоих ФС. -  В тесте PostMark F2FS одержал безоговорочную победу. Второе место с некоторым отставанием занял btrfs. EXT4 в данном тесте показал очень плохой результат, проиграв лидеру теста более чем в 5 раз. В целом F2FS показал себя на подобном носителе довольно перспективно, обгоняя ext4 на многих нагрузках. Btrfs, с другой стороны, в большинстве тестов показал себя медленнее остальных ФС на данном носителе и его сложно рекомендовать для использования с таким носителем. URL: http://www.phoronix.com/scan.php?page=article&item=linux_f2f... Новость: https://www.opennet.ru/opennews/art.shtml?num=36184
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Оценка производительности файловой системы F2FS, включённой ..."	–2 +/–
Сообщение от brzm on 22-Фев-13, 10:11
Мне всегда было непонятно в новостях про похороникс на опеннете: зачем словами описывать то, что есть в графиках? Экономия трафика? По сабжу: обычная ос, не выбивающаяся из общего числа. В плюсах то, как она заполняет носитель. Быть.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Оценка производительности файловой системы F2FS, включённой ..."	+5 +/–
	Сообщение от Аноним (??) on 22-Фев-13, 11:57
	> Экономия трафика? Скорее непонятки как это оформить так чтобы не было например нарушением авторских прав и/или не вызывало неудовольствия фороникса насчет плагиата. Событие можно описать своими словами, особенно на другом языке, и я как бы в результате получаюсь автор этого текста и все более-менее честно. Ну, автор описал некое увиденное событие, копирайт на текст у него по идее, и он может делать с текстом что хочет. А для совсем уж очистки совести - линк на оригинал, как это общепринято в интернете. А вот влобовую передрать графики уже ай-яй-яй по линии авторских прав. Это надо дотошно условия уточнять и прочая и/или как-то отдельно договариваться на этот счет. > По сабжу: обычная ос, Может, обычная ФС? И да, на NAND-based носителях она таки показала себя вполне перспективно, как и ожидалось.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Оценка производительности файловой системы F2FS, включённой ..."	+2 +/–
Сообщение от КЭП on 22-Фев-13, 10:38
1) В тестах отсутствует прямой аналог F2FS - JFFS2. 2) Не указано как все эти ФС равномерно расходовали ресурс NAND флеш памяти. ------- Резюме: полная бессмыслица тестов.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Оценка производительности файловой системы F2FS, включённой ..."	+2 +/–
	Сообщение от sasa (??) on 22-Фев-13, 10:58
	1) JFFS2 работает с устройствами MTD (RAW NAND), F2FS - для блочных устройств, так что сравнивать вы будете теплое с мягким 2) F2FS наиболее оптимально - ваш КО :)
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	5. "Оценка производительности файловой системы F2FS, включённой ..."	+5 +/–
	Сообщение от Аноним (??) on 22-Фев-13, 11:08
	> Резюме: полная бессмыслица тестов. В комментарии присутствует непонимание цели проведенного тестирования. ------- Резюме: полная бессмысленность комментария.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	11. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от Аноним (??) on 22-Фев-13, 11:59
	> 1) В тестах отсутствует прямой аналог F2FS - JFFS2. Вы упупеете ждать монтирования 160Gb SSD с данной ФС. > 2) Не указано как все эти ФС равномерно расходовали ресурс NAND флеш А это не так то просто замерять в устройствах с контроллером wearing'а. И это потребует туеву хучу времени. Т.к. надо минимум несколько раз полностью переписать носитель. К тому же логика работы будет варьироваться в зависимости от степени заполнения накопителя. Предложите разумную методику проведения такого теста для начала? И если из SSD еще как-то можно извлечь статистику по wearing'у, то вот с SDHC картой я тут вообще в тупике.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
Сообщение от rt (??) on 22-Фев-13, 11:07
> В тесте приняли участие файловые системы F2FS, Btrfs, EXT3, EXT4, XFS и JFS. ... > Самые плохие результаты в этом семействе тестов показал ReiserFS, WTF!?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Оценка производительности файловой системы F2FS, включённой ..."	–1 +/–
	Сообщение от kerneliq (ok) on 22-Фев-13, 11:31
	Да ладно! Круто же :)
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	13. "Оценка производительности файловой системы F2FS, включённой ..."	+4 +/–
	Сообщение от Аноним (??) on 22-Фев-13, 12:02
	> WTF!? Довольно шустрый SSD, выжимающий несколько сотен мегов в секунду. Поэтому кроме всего прочего начинает роялить алгоритмический оверхед от ФС - судя по всему, временами все упиралось в проц. Думается по этой же причине втопил JFS, всегда славившийся низкими требованиями к процу. Там где остальные уперлись в проц, он упирался в него куда позднее, что позволило ему показать весьма годный результат.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	18. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от ананим on 22-Фев-13, 12:40
	ежели так (а это похоже на правду), то zfs был бы ещё хуже рэйзера. с её то оверхедом по дублированию системных вызовов. зыж зато бтр очень не плохо себя показал. даже с идиотскими параметрами. (эти клоуны, увидив параметр ssd даже не посмотрели, что он включается автоматом, при этом НЕ включает trim!!! :D)
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	19. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от ананим on 22-Фев-13, 12:43
	ззыж и да, до проца затыкается вначале память.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	29. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от Аноним (??) on 22-Фев-13, 13:11
	> ежели так (а это похоже на правду), то zfs был бы ещё хуже рэйзера. Ну если учесть что он обычно хуже btrfs в подобных забегах - не знаю слил бы он рейзеру, но плелся бы точно ближе к хвосту. > с её то оверхедом по дублированию системных вызовов. Возможно. Хотя тут еще от реализации зависит. Надо бы подать форониксу идею забенчить ZFS vs ZFS. Ну, в соляре, бзде и лине. > зато бтр очень не плохо себя показал. даже с идиотскими параметрами. Ну да. И параметры F2FS'у они не пробовали твикать, вполне возможно что более удачным наложнием оного можно было бы на тех же 4K блоках поиметь больше. Тем не менее очень много юзерей именно так и будет юзать ФСы. > (эти клоуны, увидив параметр ssd даже не посмотрели, что он включается автоматом, > при этом НЕ включает trim!!! :D) А вот это кстати странно: trim нынче умеют почти все и проблем он нынче не вызывает.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	32. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от ананим on 22-Фев-13, 13:28
	>> (эти клоуны, увидив параметр ssd даже не посмотрели, что он включается автоматом, >> при этом НЕ включает trim!!! :D) >А вот это кстати странно: trim нынче умеют почти все и проблем он нынче не вызывает. чтобы включить trim, нужен параметр discard. а ssd (это не трим, а определённые оптимизации) включится автоматом, если cat /sys/block/sda/queue/rotational вернёт 0. ниже ссылку дал уже. зыж >Тем не менее очень много юзерей именно так и будет юзать ФСы. за них это сделают либо инсталяторы, либо знакомые, либо они сами, прочитав хавту. вставить 2-а параметра нифига не квантовая механика.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	66. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от Аноним (??) on 22-Фев-13, 21:10
	> /sys/block/sda/queue/rotational вернёт 0. > ниже ссылку дал уже. Ну спасибо, Капитан, правда вот я в курсе опция монтирования btrfs. Мне правда не совсем понятно почему discard при этом не включать до кучи. Хотя тут нужны какие-нибудь добавочные проверки явною > за них это сделают либо инсталяторы, либо знакомые, либо они сами, прочитав хавту. Ну да, и поэтому даже в таком режиме ФС претендующая на то чтобы стать новым дефолтом должна работать если не великолепно то по крайней мере - выше среднего. > вставить 2-а параметра нифига не квантовая механика. Абсолютно. Но как известно, defaults will prevail.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	67. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от ананим on 22-Фев-13, 21:29
	> Ну да, и поэтому даже в таком режиме ФС претендующая на то чтобы стать новым дефолтом должна работать если не великолепно то по крайней мере - выше среднего. Ну так посмотри на графики ещё раз и удивись. Без доп.опций (и даже без discard) она уже делает ext3 и иногда ext4. Рэйзер вообще в хвосте, xfs отстаёт. Ждёшь когда пару букв в опции по умолчанию запихнут? Жди.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

6. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
Сообщение от SergMarkov (ok) on 22-Фев-13, 11:19
Пожалуй самое интересное это характеристика Btrfs. "ФС завтрашнего дня" в дне сегодняшнем смотрится неблестяще. Примерно как так же широкоразрекламированный
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от Stax (ok) on 22-Фев-13, 11:31
	У COW-файловых систем своя специфика.. Многие виды нагрузок, особенно синтетические им даются сильно хуже обычных ФС. На реальных же нагрузках в случае ZFS эти проблемы нивелируются грамотным ARC-кэшированием для чтения и внешним ZIL, если требуются быстрые синхронные записи (но за это приходится платить большим расходом ресурсов). Btrfs тут - ни два, ни полтора; тяжелых механизмов, используемых в ZFS для решения проблем производительности там было решено не делать - плюсом более низкое потребление ресурсов и хорошая интеграция в текущие системы ядра, минусом - много где COW-дизайн дает большое падение производительности. Дизайн-то у нее вполне "будущий", но компромисс, чтобы сделать ее более похожим на другие линуксовые фс по потреблению ресурсов и различные упрощения по сравнению с ZFS имеют свою цену. Зато, с другой стороны, ей будет легко попасть в линуксовый продакшен и получать плюсы от COW-дизайна, в отличие от слишком нестандартного ZFS.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	9. "Оценка производительности файловой системы F2FS, включённой ..."	–3 +/–
	Сообщение от iZEN (ok) on 22-Фев-13, 11:43
	Сейчас ZFS серьёзно оптимизировали по потреблению ресурсов оперативной памяти. Что было месяц назад и что сейчас на FreeBSD 9.1-STABLE — "земля и небо". ARC не так агрессивно распоряжается свободной оперативной памятью, как раньше. Файловые системы для SSD нужно ещё правильно готовить, чтобы они учитывали специфику 4k-блоков флешатины вместо стандартных 512 байтных секторов HDD. Для этого на FreeBSD есть провайдер GEOM Nop gnop(8), который подготавливает пространство SSD под использование файловой системы, будь-то классическая ФС или же современная CoW-ФС. В Linux, наверное, об этом не слышали, так как ФС там дюже умные и сами определяют, какой носитель они используют.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	14. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от ананим on 22-Фев-13, 12:03
	>ARC не так агрессивно распоряжается свободной оперативной памятью, как раньше. ARC вообще не должно быть в грамотно спроектированной фс.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	20. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от Аноним (??) on 22-Фев-13, 12:44
	> Сейчас ZFS серьёзно оптимизировали по потреблению ресурсов оперативной памяти. Да, да, отдельный кэш у ФС, не управляемый непосредственно ядром ОС - это пиндец как оптимально. Не, извините, юзеры линукса привыкли к нормально работающим решениям, а не вот такому вот. > Что было месяц назад и что сейчас на FreeBSD 9.1-STABLE — "земля и небо". > ARC не так агрессивно распоряжается свободной оперативной памятью, как раньше. Ну значит при большой записи он лишний раз тормознет. Понимаешь, пока вы его на костылях и подпорках учите бегать, в нормальных ФС дисковый кэш играет с кернелом в совместную игру, так что ФСам по сути всегда доступна вся свободная память покуда она есть. А как только она становится нужна - кернел может ее оттяпать форсированным образом, вплоть до форсирования сброса буфферов на диск с целью их изъятия. А случае живущего своей жизнью ARC так не катит. > Файловые системы для SSD нужно ещё правильно готовить, чтобы они учитывали специфику > 4k-блоков флешатины вместо стандартных 512 байтных секторов HDD. А также сдвиг по erase-блокам и прочая. Но это в идеале. А реально - половина юзерей безбашенно форматнет "уж как вышло". И хорошо бы чтобы ФС не падала в грязь лицом даже при таком, не столь удачном раскладе. > Для этого на FreeBSD есть провайдер GEOM Nop gnop(8), который > подготавливает пространство SSD под использование файловой системы, И чем он так уж помогает флешу? И чего он такого делает, чего нельзя сделать иными средствами? Или это очередной понт "от изена"? > будь-то классическая ФС или же современная CoW-ФС. В Linux, наверное, об этом не слышали, > так как ФС там дюже умные и сами определяют, какой носитель они используют. Тем не менее, там есть и возможность вручную тыкнуть "а вот считай это SSD" или "а заюзай-ка trim вот с этим носителем". И да, если ты не понял, ФС должна довольно сильно менять логику работы под SSD, ориентируясь на крупноблочный обмен. Но зато совершенно не парясь насчет времени перемещения голов, которого нет. По поводу чего опция монтирования с требованием сделать именно это самое - смотрится вполне логично.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	23. "Оценка производительности файловой системы F2FS, включённой ..."	+1 +/–
	Сообщение от BayaN (ok) on 22-Фев-13, 12:57
	>И чем он так уж помогает флешу? И чего он такого делает, чего нельзя сделать иными средствами? Или это очередной понт "от изена"? А ничем, iZEN просто как всегда сморозил чушь: >    The gnop utility is used for setting up transparent providers on existing >    ones.  Its main purpose is testing other GEOM classes, as it allows >    forced provider removal and I/O error simulation with a given probabil- >    ity.  It also gathers the following statistics: number of read requests, >    number of write requests, number of bytes read and number of bytes writ- >    ten.  In addition, it can be used as a good starting point for implement- >    ing new GEOM classes. Это GEOM модуль для тестирование фреймворка. В случае с 4K, у него просто есть возможность задать смещение, т.к. выровнять область на границу 4K. Это был временный костыль. Сейчас насколько мне известно всё делается с помощью gpart.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	27. "Оценка производительности файловой системы F2FS, включённой ..."	+1 +/–
	Сообщение от Аноним (??) on 22-Фев-13, 13:04
	> Это GEOM модуль для тестирование фреймворка. В случае с 4K, у него > просто есть возможность задать смещение, А, понятно, в бзде как обычно подставили изощренный костыль партиционеру весьма странным образом, а изен почему-то решил что это - фича. Бывает :)
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	33. "Оценка производительности файловой системы F2FS, включённой ..."	+1 +/–
	Сообщение от BayaN (ok) on 22-Фев-13, 13:41
	> А, понятно, в бзде как обычно подставили изощренный костыль партиционеру весьма странным > образом Нет, не так. Когда появились первые диски с 4K сектором (причём сообщающие, что у них всё по старому - 512), в списках рассылки freebsd возникла заворушка, типа всё тормозит и чё делать. Пришли к выводу что делать надо, нужно кодить. Но внезапно GEOM опять проявил свою гибкость и оказалось, что можно изпользовать GNOP в несвойственной ему области. Поэтому тем кому надо кровь из носу прямо сейчас, могут использовать GNOP, что не отменяет костыльность этого способа. Затем естественно проблему решили нормальным способом.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	37. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от Аноним (??) on 22-Фев-13, 13:57
	> freebsd возникла заворушка, типа всё тормозит и чё делать. Пришли к > выводу что делать надо, нужно кодить. Да что там кодить то? Только смещение начала партиции указать. Неужто у бсдоидов партиционер такой элементарщины раньше не позволял? (для ФС на флеше хорошо бы еще угадать с началом erase block, делая отступ от начала диска на нечто кратное, допустим 512К). > Но внезапно GEOM опять проявил свою гибкость и оказалось, что можно изпользовать > GNOP в несвойственной ему области. Поэтому тем кому надо кровь из носу прямо сейчас, > могут использовать GNOP, что не отменяет костыльность этого способа. Ну я и говорю - неумение партиционера нормально размечать диски походу скомпенсировали таким вот фигурным костылем. А изен почему-то думает что это - фича. Лол :) > Затем естественно проблему решили нормальным способом. ...а изен, забывший отпустить ручник, по прежнему считает что те костыли - не баг а фича...
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	36. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от iZEN (ok) on 22-Фев-13, 13:52
	>> Это GEOM модуль для тестирование фреймворка. В случае с 4K, у него >> просто есть возможность задать смещение, > А, понятно, в бзде как обычно подставили изощренный костыль партиционеру весьма странным > образом, а изен почему-то решил что это - фича. Бывает :) SSD Crucial в dmesg пишет о 512 байтных секторах. Хотя известно, что внутри флэша контроллер работает с 4k-блоками. Каким образом известить файловую систему о том, чтобы она использовала другое физическое представление секторов и отличала SSD от стандартного HDD? Подумай на досуге.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	41. "Оценка производительности файловой системы F2FS, включённой ..."	–1 +/–
	Сообщение от ананим on 22-Фев-13, 14:14
	>SSD Crucial в dmesg пишет о 512 байтных секторах. первый вопрос — в бздях?
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	69. "Оценка производительности файловой системы F2FS, включённой ..."	+1 +/–
	Сообщение от iZEN (ok) on 22-Фев-13, 22:07
	>>SSD Crucial в dmesg пишет о 512 байтных секторах. > первый вопрос — в бздях? В бздях. В линуксях по-другому?
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	42. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от Аноним (??) on 22-Фев-13, 14:23
	>> образом, а изен почему-то решил что это - фича. Бывает :) > SSD Crucial в dmesg пишет о 512 байтных секторах. Хотя известно, что > внутри флэша контроллер работает с 4k-блоками. Каким образом известить файловую систему > о том, чтобы она использовала другое физическое представление секторов и отличала > SSD от стандартного HDD? Подумай на досуге. Ну лично я вообше захинтил ext4'му в опциях что "это у нас, типа, stripe, с блоком 512К" при этом ФС будет стараться вести обмен с накопителем блоками по размеру erase-block'а. Что для SSD лучше чем россыпь из кучи мелочи на вход. Есть у ext4 такие твикинги. Оно исходно под RAID-ы заточено, но, собственно, я не вижу почему бы не применить этот фокус и к SSD, которому крупноблочный формат обмена явно лучше россыпи, которая почем зря заставит изгаляться FTL-уровень по распихиванию "куда-нибудь". Так что оно будет пытаться по возможности оперировать даже не страницами а erase block за раз. Что по идее должно быть достаточно удобным для накопителя. Алсо, у ФС типа ext4 по сути нет понятия "сектор". Есть "блок ФС". Это минимально адресуемый за раз юнит. То что он по дефолту 4К - очень кстати. И остается разложить ФС так чтобы блоки не попадали на пересечение страниц. Сдается мне что если я выравнивал размещение ФС на целые 512К (по erase block'у), на страницы оно при этом "само" выровняется, просто потому что 4K * 128 == 512K. Т.е. я разложил ext4 с отступом кратным erase block от начала диска. Ну и ясен пень включил trim. В целом вроде неплохо работает - за почти год SSD протерся на 1% судя по SMART.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	56. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от Харитон on 22-Фев-13, 15:06
	В целом > вроде неплохо работает - за почти год SSD протерся на 1% > судя по SMART. А по какому параметру вы это смотрите? А то я когда-то читал что для ССД смартцтл должен быть начиная с определенной версии и различные стандартные значения СМАРТА для винта имеют другое смысловое значение для ССД...
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	60. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от ананим on 22-Фев-13, 15:28
	Wear Leveling Count http://www.citilink.ru/promo/crucial/review128.php
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	72. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от Аноним (??) on 22-Фев-13, 23:22
	> А по какому параметру вы это смотрите? У моего SSD несколько параметров касающихся wearing. Наиболее интересные: 1) 233 Media_Wearout_Indicator, насколько я понимаю это процент износа (в процентах, vs число циклов/задекларированное для флеша производителем). У меня пока оно вообще идеальное, как у нового диска. С точностью до 1%. Получается что я пока не протер даже на 1%. 2) 226 Workld_Media_Wear_Indic - тоже нечто касающееся износа, однако формат цифры не соответствует даташиту. Ну, чтобы интел и совсем без багов - так не бывает :). Теоретически, там записан износ с момента последнего сброса таймера. Практически у меня этот атрибут содержит нечто, что совсем не укладывается в формат числа из даташита, по поводу чего интерпретировать данное поле мне не удалось. 3) 241 Host_Writes_32MiB - объем записанных данных, в 32Mb попугаях. Можно грубо прикинуть число циклов которые проехали. И/или сравнить с задекларированным объемом записи (для моего накопителя 60Tb). По ним как раз получается что я 1% не добрал. Но это валидно только для SSD intel и только для серии с контроллером от интел. У других производителей могут быть иные атрибуты. > А то я когда-то читал что для ССД смартцтл должен быть начиная с определенной версии и > различные стандартные значения СМАРТА для винта имеют другое смысловое значение для ССД... Абсолютно другое, т.к. параметры касающиеся вращаюшихся дисков к SSD неприменимы вообще. Smartctl должен быть достаточно свежий + девайс должен быть в его базе. Иначе он просто не сможет понять что это за атрибуты и будет выводить их как unknown_attribute. Впрочем, зная номер атрибута и производителя, можно скормить это гуглю и узнать WTF. Но лучше если smartctl сам по человечески покажет.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	70. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от iZEN (ok) on 22-Фев-13, 22:22
	> Алсо, у ФС типа ext4 по сути нет понятия "сектор". Понятие "сектор" — физическая единица адресации пространства носителя. > Есть "блок ФС". Это минимально адресуемый за раз юнит. В NTFS и FAT он называется "кластер". И что? > То что он по дефолту 4К - очень кстати. И остается разложить ФС так чтобы блоки не попадали на пересечение страниц. Это достигается выравниванием размеченного раздела по границе, кратной 4k. > Сдается мне что если я выравнивал размещение ФС на целые 512К (по erase block'у), на страницы оно при этом "само" выровняется Оно само не выровняется. Просто твой хвост от 512k-блока ФС может по недоумению захватить первую четверть, две четверти или три четверти 4k-блока, а остальной кусочек будет уже принадлежать следующему по физическому расположению 512k-блоку ФС, и не факт, что эта пара блоков ФС будет принадлежать одному и тому же файлу. Кроме того, 512k-блоки — это заранее обрекать себя на потерю пространства на маленьких (размером <512k) файлах. > просто потому что 4K * 128 == 512K. Т.е. я разложил ext4 с отступом кратным erase block от начала диска. У меня: % gpart show ada4 =>       34  125045357  ada4  GPT  (59G)          34          6        - free -  (3.0k)          40       1024     1  freebsd-boot  (512k)        1064        984        - free -  (492k)        2048  125040000     2  freebsd-zfs  (59G)   125042048       3343        - free -  (1.6M)
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	73. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от Аноним (??) on 22-Фев-13, 23:58
	>> Алсо, у ФС типа ext4 по сути нет понятия "сектор". > Понятие "сектор" — физическая единица адресации пространства носителя. Спасибо, капитан. Правда учитывая что SSD для записи 512 байтного сектора делает read-modify-write, это всего лишь такой красивый логический трындеж в паспорте диска, не имеющий под собой никакого реального физического смысла. Это всего лишь гнусная эмуляция, для того чтобы легаси софт (==древние ОС), который не подозревает о SSD не сыпался как горох. Полагаться на этот трындеж - себе дороже. Т.к. работа кусками по 512 байтов будет медленной, неэффективной и с конским write amplification factor, что поможет SSD побыстрее сдохнуть. >> Есть "блок ФС". Это минимально адресуемый за раз юнит. > В NTFS и FAT он называется "кластер". И что? А ничего, то же самое по смыслу. И производители флешек с FAT отлично в курсе этого момента. И очень характерно кроят для них FAT и партишн тейблы, откровенно выравнивая все это на erase block. Чтоб оно по разным erase block было. Что спасает партишн тейбл от слета в момент когда апдейтили фат и питание слетело. > Это достигается выравниванием размеченного раздела по границе, кратной 4k. Какой ты догадливый. А лучше уж по erase block-у, т.е. 512К. В том числе из-за озвученных выше соображений, дабы развязать апдейт критичных структур друг от друга. Дабл факап служебных структур - досаден вдвойне. > Оно само не выровняется. Просто твой хвост от 512k-блока ФС может по > недоумению захватить первую четверть, две четверти или три четверти 4k-блока, Ты не понял, в erase-block целове число страниц, при том одинаковое :). В частности erase-block на 512К содержит 128 x 4K страниц. Так что при выравнивании на 512К выравнивание на 4К получится "само" - просто потому что они кратные. А то что ты сказал - это случай когда выравнивание на 512К не удалось сделать. > а остальной кусочек будет уже принадлежать следующему по физическому расположению 512k-блоку Ну так это случай когда выравнивание на 512К не удалось сделать как раз. А если ты разместил структуры с смещением кратным 512К, оно будет автоматически кратно и 4К до кучи. И мне кажется наиболее логичным целиться в это двойное совпадение по возможности. Ну, как производители SD/флешек на фабричном формате примерно. Они ж не просто так делают, а из соображений оптимальной скорости и минимального веаринга. Как раз по озвученным тобой же :) причинам. > ФС, и не факт, что эта пара блоков ФС будет принадлежать одному и тому же файлу. Ну да, совершенно. Поэтому есть некий write amplification factor, т.е. фактически записей в флеш для удовлетворения конкретных запросов может оказаться больше чем размер запроса. Из-за фрагментации свободного места, например. В этом месте мы знакомимся с TRIM и его подыгрышем garbage collection, нацеленными на минимизацию этого безобразия. С trim накопитель может явно знать какие регионы не используются и расчистив заранее регионы более удачно раскладывать данные + не натыкаться на нужду GC+erase непосредственно в момент записи. > Кроме того, 512k-блоки — это заранее обрекать себя на потерю пространства на > маленьких (размером <512k) файлах. Ну да, поэтому я обошелся более "мягким" хинтом ФС что желаемый размер "страйпа" - вот такой. При этом некий риск что хвост блока будет не идеально стыковаться с erase block - таки есть. Но в целом оно судя по всему работает достаточно недурно, судя по тому что за год SSD даже на 1% не затерся. >   2  freebsd-zfs  (59G) Пардон, ZFS достаточно навернут и я не возьмусь даже грубо прикидывать как его variable length блоки будут раскладываться относительно страниц/erase blocks. Если в случае с фиксированными блоками это еще можно прикинуть, то для variable - дохлый номер. Теоретически, на флеше минимальный размер variable блока должен быть 4К и инкремент - строго кратный 4К. Ну, чтоб выравнивание хотя-бы на страницы после такого блока не отъехало. Практически я не знаю можно ли допинать блоки переменного размера ZFS до такой кондиции. Это высший пилотаж для гур в ZFS уже. В случае экстентов типа того что в ext4, такое свойство "само" получается "автоматически", просто потому что минимальным адресуемым юнитом является блок ФС в 4К и менее крупный юнит не будет использоваться, а экстент - это регион из эн * 4K блоков. Что довольно неплохо с точки зрения попадания в геометрию флеша без пересечений.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	77. "Оценка производительности файловой системы F2FS, включённой ..."	–2 +/–
	Сообщение от iZEN (ok) on 23-Фев-13, 00:51
	> Пардон, ZFS достаточно навернут и я не возьмусь даже грубо прикидывать как > его variable length блоки будут раскладываться относительно страниц/erase blocks. Минимальный размер блока ZFS — 128k. То есть кратно 4k физическим блокам. > Если > в случае с фиксированными блоками это еще можно прикинуть, то для > variable - дохлый номер. Дохлый номер — это если варьируемый размер блока ФС не будет кратен размеру физического блока флэшатины — 4k, что в случае с ZFS исключено, так как у ней 128k — это ступень, от которой прыгают экстенты, которые, в свою очередь, не могут быть меньше размера базового блока (128k), но всегда кратны размеру блока ФС. > Теоретически, на флеше минимальный размер variable блока > должен быть 4К и инкремент - строго кратный 4К. Именно. > Ну, чтоб > выравнивание хотя-бы на страницы после такого блока не отъехало. Практически я > не знаю можно ли допинать блоки переменного размера ZFS до такой > кондиции. Это высший пилотаж для гур в ZFS уже. В своё время, как только ZFS выпустили в продакшен, генеральный директор Sun Шварц написал в своём бложике, что для SSD это — идеальная файловая система, так как решает сразу несколько проблем: обеспечивает контроль за целостностью данных в режиме запроса данных, имеет CoW принцип — старые данные не перезаписываются новыми, новые данные пишутся в новое место, затирая разве что самые старые данные, щадя флэш от перезаписи одних и тех же физических секторов. > В случае > экстентов типа того что в ext4, такое свойство "само" получается "автоматически", > просто потому что минимальным адресуемым юнитом является блок ФС в 4К > и менее крупный юнит не будет использоваться, а экстент - это > регион из эн * 4K блоков. Что довольно неплохо с точки > зрения попадания в геометрию флеша без пересечений. А экстент в ZFS, по-твоему, это какого размера регион? Те же самые n*128k блоков файловой системы. ;)
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	45. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от ананим on 22-Фев-13, 14:30
	второе — в линухе вопрос решён. >4096 looks good to me!! http://forum.crucial.com/t5/Solid-State-Drives-SSD/linux/m-p... если (если!!!) не решён, то >Thus, I set up the file systems on the Intel SSD like this: >mkfs.ext4 -b 1024 -E stride=128,stripe-width=128 -O ^has_journal /dev/sda1 >mkfs.ext4 -b 4096 -E stride=32,stripe-width=32 /dev/sda3 http://blog.nuclex-games.com/2009/12/aligning-an-ssd-on-linux/ для btrfs — создаём с параметрами: -A, --alloc-start offset     Specify the offset from the start of the device to start the btrfs filesystem. -s, --sectorsize size        Specify the sectorsize, the minimum block allocation. -n, --nodesize size         Specify the nodesize. By default the value is set to the pagesize. монтируем как-то так: space_cache,inode_cache,discard,noatime,rw,ssd,compress=lzo,thread_pool=32
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	80. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от Michael Shigorin (ok) on 02-Мрт-13, 00:10
	> SSD Crucial в dmesg пишет о 512 байтных секторах. Хотя известно, что > внутри флэша контроллер работает с 4k-блоками. JFYI, про erase block в 4k на SSD ещё не слышал -- обычно 128k.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	34. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от iZEN (ok) on 22-Фев-13, 13:48
	> В случае с 4K, у него просто есть возможность задать смещение, т.к. выровнять область на границу 4K. Ни о каком смещении я не говорил, так как это привелегия gpart. Я имел в виду возможность прямого указания с помощью gnop размера "сектора" (см. ключ -S) для прозрачной трансляции этой информации ФС, которая работает с SSD, говорящем в dmesg о 512-байтовых секторах.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	39. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от ананим on 22-Фев-13, 14:04
	какая в попу привелегия? эта инфа есть в смарт на самом носителе. к примеру: # smartctl -i /dev/sda Model Family:     Seagate Momentus 7200.4 Device Model:     ST9500420ASG … Sector Size:      512 bytes logical/physical # smartctl -i /dev/sdc Model Family:     Seagate Momentus SpinPoint M8 (AF) … Sector Sizes:     512 bytes logical, 4096 bytes physical нахрен не нужно вставлять дополнительную сущность для тривиальной операции. тем более для zfs/btrfs. разбил диск, создал фс, всё. как создал, так создал. как разбил, так разбил. ты же предлагаешь заниматься преобразованиями данных через geom. зыж это для винтов. у кого есть ssd, плс, покажите айзену.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	43. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от Аноним (??) on 22-Фев-13, 14:26
	> Sector Sizes:     512 bytes logical, 4096 bytes physical А SSD от интеля врет про 512 байтов. Так что раз на раз... > ты же предлагаешь заниматься преобразованиями данных через geom. Я так понимаю, он не отпустиил ручник. Тут из зала более адекватные личности подсказывают :) > это для винтов. у кого есть ssd, плс, покажите айзену. Увы, мой ssd врет :) Sector Size:      512 bytes logical/physical
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	46. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от ананим on 22-Фев-13, 14:35
	>> Sector Sizes:     512 bytes logical, 4096 bytes physical >А SSD от интеля врет про 512 байтов. Так что раз на раз... врёт, исправляйте вручную. вон выше пару примеров дал. >Увы, мой ssd врет :) >Sector Size:      512 bytes logical/physical а весь вывод смарта можно посмотреть? :D
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	51. "Оценка производительности файловой системы F2FS, включённой ..."	–1 +/–
	Сообщение от BayaN (ok) on 22-Фев-13, 14:44
	> вон выше пару примеров дал. Дай пример для ZFS.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	54. "Оценка производительности файловой системы F2FS, включённой ..."	+1 +/–
	Сообщение от ананим on 22-Фев-13, 14:49
	а зачем мне? тут айзен за zfs оборону держит.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	76. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от Аноним (??) on 23-Фев-13, 00:13
	> врёт, исправляйте вручную. Ну ясен фиг, я как-то так и кроил себе ФС: захинтил размер страйпа в 512К + смещение подогнал. Журнал не отключал (kamikaze mode off), веар-левелинг худо-бедно с ним справится, тем паче что там только метаданные. > а весь вывод смарта можно посмотреть? :D === START OF INFORMATION SECTION === Model Family:     Intel 320 Series SSDs Device Model:     INTEL SSDSA2CW080G3 Serial Number:    <skip> LU WWN Device Id: <skip> Firmware Version: 4PC10362 User Capacity:    80,025,280,000 bytes [80.0 GB] Sector Size:      512 bytes logical/physical Device is:        In smartctl database [for details use: -P show] ATA Version is:   8 ATA Standard is:  ATA-8-ACS revision 4 Local Time is:    Fri Feb 22 21:11:53 2013 MSK SMART support is: Available - device has SMART capability. SMART support is: Enabled (полный вывод занимает пару страниц и был заскипан)
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	81. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от Michael Shigorin (ok) on 02-Мрт-13, 00:16
	>>Увы, мой ssd врет :) >>Sector Size:      512 bytes logical/physical Аналогично для SanDisk SSD U100 252GB и KINGSTON SNVP325S2128GB. > а весь вывод смарта можно посмотреть? :D Без толку, мы в них (конкретно WD 15EARS) чем только не тыкали, почитав спецификацию.  Информация и ссылки по теме собраны на http://www.altlinux.org/BigSector
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	50. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от BayaN (ok) on 22-Фев-13, 14:42
	>какая в попу привелегия? эта инфа есть в смарт на самом носителе. к примеру Простая, если диск врёт. > нахрен не нужно вставлять дополнительную сущность для тривиальной операции. тем более для zfs/btrfs. В том-то и дело, что как раз для тривиальной операции для ZFS весь это геморой до сих пор и нужен, т.к. если диск врёт о размере сектора, то для ZFS нету способа задать размер. Тут iZEN прав, с помощью GNOP её сообщают настоящий размер сектора. UFS2 в этом плане всегда нормально работает. В случае с нормальными дисками. Ничего, кроме выравнивания разделов с помощью gpart делать не надо.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	53. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от ананим on 22-Фев-13, 14:48
	>>какая в попу привелегия? эта инфа есть в смарт на самом носителе. к примеру >Простая, если диск врёт. да елки-палки… врёт? исправляйте вручную параметрами при создании фс. (если вы конечно узнали правильные) >В том-то и дело, что как раз для тривиальной операции для ZFS весь это геморой до сих пор и нужен, т.к. если диск врёт о размере сектора, то для ZFS нету способа задать размер. для бтр вон выше параметры создания привёл. а если фс нельзя заставить использовать те или иные параметры, то либо меняйте фс, либо устройство. а заниматься преобразованиями данных… это даже для айзена слишком.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	62. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от BayaN (ok) on 22-Фев-13, 16:34
	> да елки-палки… > врёт? исправляйте вручную параметрами при создании фс. > (если вы конечно узнали правильные) Для ZFS нельзя так сделать. Поэтому во FreeBSD фигачат gnop, в illumos'е конфигурят драйвер, в Linux'е я хз, как они это обходят. > а если фс нельзя заставить использовать те или иные параметры, то либо > меняйте фс, либо устройство. Вариант, но не всегда. > а заниматься преобразованиями данных… это даже для айзена слишком. GNOP не занимается преобразованием данных, это класс который который прозрачно проталкивает данные дальше по графу. Тормозить там нечему.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	59. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от ананим on 22-Фев-13, 15:18
	>В том-то и дело, что как раз для тривиальной операции для ZFS весь это геморой до сих пор и нужен, т.к. если диск врёт о размере сектора, то для ZFS нету способа задать размер. а что, вот как то так обмануть нельзя http://blog.nuclex-games.com/2009/12/aligning-an-ssd-on-linux/ >To make fdisk use 32 heads and 32 sectors, remove all partitions from a hard drive and then launch fdisk with the following command line when you create the first partition: > fdisk -S 32 -H 32 /dev/sda >For a normal hard drive, I’d probably use 128 heads and 32 tracks now to achieve 4 KiB boundaries for my partitions. не?
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	61. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от BayaN (ok) on 22-Фев-13, 16:28
	> не? Не, http://savagedlight.me/2012/07/15/freebsd-zfs-advanced-format/: ZFS is smart enough to query the underlying device to see how large its sectors are, and use this information to determine the size of its dynamic-width stripes. This is all fine and dandy for as long as the hardware isn’t lying. Sadly, hardware currently lie more often than not. My drives claim to have a logical sector size of 512 bytes (ashift=9 because 2^9=512) while the physical sectors are 4Kib (ashift=12). As such, ZFS will make stripes aligned to 512 bytes. This means stripes will almost always be non-aligned, forcing the underlying device to work its magic which in turn degrades performance. Это проблема только кривых дисков. Выравнивание разделов спокойно делается с помощью gpart. GNOP в данном случае просто костыль, который сообщает ZFS правильный размер сектора. Хотя мне например, решение у illumos больше нравится (хотя это тоже костыль) http://wiki.illumos.org/display/illumos/ZFS+and+Advanced+For...: Some operating systems provide a way to pass the desired ashift value to zpool invokation in some way, or even hard-code ashift=12 into a separately built zpool binary. The illumos-gate did not, after long discussions, follow this "trivial" path. Instead, illumos-based OSes can now override the physical block (sector) size for "talking" to particular devices regardless of what they announce, by using a value configured in the sd(7d) driver. Once the device vendor and identification strings are known, the /kernel/drv/sd.conf file can be modified: sd-config-list =         "SEAGATE ST3300657SS", "physical-block-size:4096",         "DGC     RAID", "physical-block-size:4096",         "NETAPP  LUN", "physical-block-size:4096"; Т.е. они конфигурируют драйвер, чтобы тот указывал нужный размер блока, а не тот, что рапортует железяка.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	68. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от iZEN (ok) on 22-Фев-13, 22:05
	На смотри: % smartctl -i /dev/ada4 smartctl 6.0 2012-10-10 r3643 [FreeBSD 9.1-STABLE amd64] (local build) Copyright (C) 2002-12, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family:     Crucial/Micron RealSSD C300/C400/m4 Device Model:     M4-CT064M4SSD2 Serial Number:    0000000012170909003D LU WWN Device Id: 5 00a075 10909003d Firmware Version: 000F User Capacity:    64 023 257 088 bytes [64,0 GB] Sector Size:      512 bytes logical/physical Rotation Rate:    Solid State Device Device is:        In smartctl database [for details use: -P show] ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 6 SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is:    Fri Feb 22 22:03:33 2013 VOLT SMART support is: Available - device has SMART capability. SMART support is: Enabled
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	28. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от Аноним (??) on 22-Фев-13, 13:05
	>[оверквотинг удален] > работающим решениям, а не вот такому вот. >> Что было месяц назад и что сейчас на FreeBSD 9.1-STABLE — "земля и небо". >> ARC не так агрессивно распоряжается свободной оперативной памятью, как раньше. > Ну значит при большой записи он лишний раз тормознет. Понимаешь, пока вы > его на костылях и подпорках учите бегать, в нормальных ФС дисковый > кэш играет с кернелом в совместную игру, так что ФСам по > сути всегда доступна вся свободная память покуда она есть. А как > только она становится нужна - кернел может ее оттяпать форсированным образом, > вплоть до форсирования сброса буфферов на диск с целью их изъятия. > А случае живущего своей жизнью ARC так не катит. Ты в этом уверен? Ткни мне место в сорце ZFS, где это написано, угумс? Потом потолкуем, чего там не катит, ага? PS. Не надо трындеть о том, в чем ты не разбираешься и чего ты своими глазами НЕ ВИДЕЛ. Смекаешь?
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	52. "Оценка производительности файловой системы F2FS, включённой ..."	+2 +/–
	Сообщение от Аноним (??) on 22-Фев-13, 14:45
	> Ты в этом уверен? Ткни мне место в сорце ZFS, где это > написано, угумс? Потом потолкуем, чего там не катит, ага? Фирма Оракл поздравляет мальчиков с 23 февраля, а девочек с 8 марта. И дарит вам всем замечательный подарок: http://hub.opensolaris.org/bin/view/Main/ "Site Unavailable After March 24, 2013" In preparation for the decommission of opensolaris.org, certain content, mailing lists and projects will be moving to java.net and/or the Oracle Technology Network (OTN). If you have questions about a particular collective, contact a leader of that collective.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	38. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от iZEN (ok) on 22-Фев-13, 13:58
	>> Сейчас ZFS серьёзно оптимизировали по потреблению ресурсов оперативной памяти. > Да, да, отдельный кэш у ФС, не управляемый непосредственно ядром ОС - > это пиндец как оптимально. Не, извините, юзеры линукса привыкли к нормально > работающим решениям, а не вот такому вот. Вообще-то, ZFS— часть ядра FreeBSD. Если в линуксе не так, то и говорите за линукс. Зачем в кучу мешать коней и людей? >> Что было месяц назад и что сейчас на FreeBSD 9.1-STABLE — "земля и небо". >> ARC не так агрессивно распоряжается свободной оперативной памятью, как раньше. > Ну значит при большой записи он лишний раз тормознет. ARC никак не связан с записью. Это кэш для чтения. > Понимаешь, пока вы > его на костылях и подпорках учите бегать, в нормальных ФС дисковый > кэш играет с кернелом в совместную игру, так что ФСам по > сути всегда доступна вся свободная память покуда она есть. А как > только она становится нужна - кернел может ее оттяпать форсированным образом, > вплоть до форсирования сброса буфферов на диск с целью их изъятия. > А случае живущего своей жизнью ARC так не катит. У вас, может быть, он и живёт "своей жизнью". Но обобщать не надо. >> Файловые системы для SSD нужно ещё правильно готовить, чтобы они учитывали специфику >> 4k-блоков флешатины вместо стандартных 512 байтных секторов HDD. > А также сдвиг по erase-блокам и прочая. Но это в идеале. А > реально - половина юзерей безбашенно форматнет "уж как вышло". И хорошо > бы чтобы ФС не падала в грязь лицом даже при таком, > не столь удачном раскладе. Поэтому ZFS используется специалистами весьма эффективно, а такими, как вы, — как придётся. >> Для этого на FreeBSD есть провайдер GEOM Nop gnop(8), который >> подготавливает пространство SSD под использование файловой системы, > И чем он так уж помогает флешу? И чего он такого делает, > чего нельзя сделать иными средствами? Он помогает флэшу не делать перезаписей соседних областей (флэш перезаписывает полностью 4k блок) на любую серию 512-байтных "чихов" ФС. >> будь-то классическая ФС или же современная CoW-ФС. В Linux, наверное, об этом не слышали, >> так как ФС там дюже умные и сами определяют, какой носитель они используют. > Тем не менее, там есть и возможность вручную тыкнуть "а вот считай > это SSD" или "а заюзай-ка trim вот с этим носителем". И > да, если ты не понял, ФС должна довольно сильно менять логику > работы под SSD, ориентируясь на крупноблочный обмен. Вот именно я это и хочу донести. ФС не откуда узнать о правильной структуре флэша, если информация от него самого фальшива.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	57. "Оценка производительности файловой системы F2FS, включённой ..."	–1 +/–
	Сообщение от Аноним (??) on 22-Фев-13, 15:08
	> Зачем в кучу мешать коней и людей? Оно у вас конечно часть ядра, но - примотанная скотчем сбоку. Со всеми вытекающими. > ARC никак не связан с записью. Это кэш для чтения. IIRC он таки и на чтение и на запись работает. Так что походу тебя жестоко глючит. >> А случае живущего своей жизнью ARC так не катит. > У вас, может быть, он и живёт "своей жизнью". Но обобщать не надо. Угу, расскажи еще что бсдшники полностью переписали управление кешом. Сомнительно как-то при вечной нехватке ресурсов то. > Поэтому ZFS используется специалистами весьма эффективно, а такими, как вы, — как придётся. Да, как он используется специалистами типа iZEN я уже видел. Получить 6Мб/сек на шпиндель может только настоящий гуру. > Он помогает флэшу не делать перезаписей соседних областей (флэш перезаписывает > полностью 4k блок) на любую серию 512-байтных "чихов" ФС. А приколись, в каком-нибудь ext4 минимальный юнит адресации равен блоку ФС и если он 4К то это получается "само" и "нахаляву". А еще там есть хинтинг для страйпа. Можно попытаться спровоцировать обмен размером с erase block, чтобы уж совсем хорошо. >> да, если ты не понял, ФС должна довольно сильно менять логику >> работы под SSD, ориентируясь на крупноблочный обмен. > Вот именно я это и хочу донести. ФС не откуда узнать о > правильной структуре флэша, если информация от него самого фальшива. Как ни странно, в этом месте ты даже не очень уж и натрындел. Тем не менее, если ФС может распознать SSD, логично применить ряд более-менее универсальных оптимизаций. Типа попытки работать относительно крупными блоками, но не обязательно близкими в логическом пространстве накопителя.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	71. "Оценка производительности файловой системы F2FS, включённой ..."	+1 +/–
	Сообщение от iZEN (ok) on 22-Фев-13, 22:26
	>> ARC никак не связан с записью. Это кэш для чтения. > IIRC он таки и на чтение и на запись работает. Так что походу тебя жестоко глючит. Матчасть подучи по ZFS, потом приходи.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	75. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от kurokaze (ok) on 23-Фев-13, 00:06
	> Матчасть подучи по ZFS, потом приходи. Матчасть?! Изень, я как много лет юзавший фряху и пишуший на жабке, утверждаю что ты и матчасть - это даже не разны планеты, это разные галактики. Все на что ты способен - позорить любую отрасль своими кривыми лапками - будь то фряха или жабка или фс. А знаешь почему? Потому что ты бздун.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	78. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от exn (??) on 23-Фев-13, 19:16
	> Сейчас ZFS серьёзно оптимизировали по потреблению ресурсов оперативной памяти. Что было >месяц назад и что сейчас на FreeBSD 9.1-STABLE — "земля и небо". ARC не так агрессивно >распоряжается свободной оперативной памятью, как раньше. >Файловые системы для SSD нужно ещё правильно готовить, чтобы они учитывали специфику >4k-блоков флешатины вместо стандартных 512 байтных секторов HDD. Для этого на FreeBSD есть >провайдер GEOM Nop gnop(8), который подготавливает пространство SSD под использование >файловой системы, будь-то классическая ФС или же современная CoW-ФС. В Linux, наверное, об >этом не слышали, так как ФС там дюже умные и сами определяют, какой носитель они используют. и этот комментарий заминусовали ? жесть, вообще обыдлела публика
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	15. "Оценка производительности файловой системы F2FS, включённой ..."	–2 +/–
	Сообщение от ананим on 22-Фев-13, 12:15
	тра-тата, бла-бла-бла, маркетинговый булшит. особенно это >На реальных же нагрузках в случае ZFS эти проблемы нивелируются грамотным ARC-кэшированием для чтения и внешним ZIL и это >для решения проблем производительности там было решено не делать - и это >Дизайн-то у нее вполне "будущий", но компромисс, чтобы сделать ее более похожим на другие линуксовые фс по потреблению ресурсов и различные упрощения по сравнению с ZFS имеют свою цену. Запомните, это ZFS выпустили отдельно со своим кэшем как компромисс. Уже столько про это писали. И тут, и сами разрабы. 2-а конкурирующих кэша в системе! ха!
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	12. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от ананим on 22-Фев-13, 12:01
	>Пожалуй самое интересное это характеристика Btrfs. "ФС завтрашнего дня" в дне сегодняшнем смотрится неблестяще. Нифигасе! бтр смотрится великолепно. С самыми идиотскими опциями монтирования (realatime, spacecashe) она смотрится очень не плохо. Уж лучше чем рэйзер и ext3. Попробуйте зафигачить data=journal в ext4/ext3 и btrfs их тутже порвёт как тузик грелку. И даже тут, с data=ordered, вставив в btr параметры compress=lzo,inode_cache всё резко изменится. Вот читайте раздел Performance тут https://btrfs.wiki.kernel.org/index.php/Mount_options#Perfor... зыж И да, ssd то параметр они вставили. А discard (Enables discard/TRIM on freed blocks) нет. >ssd     Turn on some of the SSD optimized behaviour within btrfs. This is enabled automatically by checking /sys/block/sdX/queue/rotational to be zero. This does not enable discard/TRIM! https://btrfs.wiki.kernel.org/index.php/Mount_options клоуны короче.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	25. "Оценка производительности файловой системы F2FS, включённой ..."	+1 +/–
	Сообщение от Аноним (??) on 22-Фев-13, 13:01
	> https://btrfs.wiki.kernel.org/index.php/Mount_options клоуны короче. Не клоуны а просто поюзали ФС в состоянии по дефолту, как это сделают обычные юзвери. Это нормально и думаю что постепенно в btrfs часть дефолтов станет более удачными. А если уж кого и ругать - то имхо рейзер, который так нахваливали как быстрый, а оказалось что на SSD он вообще слоупок.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	30. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от ананим on 22-Фев-13, 13:20
	вот не надо, по дефолту realatime, spacecashe, ssd сами не вставляются. при этом ssd определяется самостоятельно (см. выше). вообще то о том и речь, что btrfs даже с этими параметрами в большинстве тестов был не хуже ext4, а в некоторых лучше. не говоря уже об ext3 и рэйзер. при этом у btr есть ещё потенциал, когда при помощи пары-тройки параметров он может прибавить, а у остальных нет. зыж да, ругать я никого и не собирался. и ещё, юзверь либо вообще не будет заморачиваться с фс, либо за него это сделает другой (включая инсталятор дистра). так что не принимается. вон, ссдэхи маководы покупают взамен винтов и меняют, хотя это там и не тривиально, и трим настраивают, и то, и сё, и эпиквинами пол-инета забито. вот к примеру http://www.citilink.ru/catalog/parts/hdd/hdd_in/605205/?opin... не надо из людей идиотов априори лепить. это всего-ишь 2-а параметра монтирования, а не толмуды, как в zfs.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	35. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от Аноним (??) on 22-Фев-13, 13:51
	> вот не надо, по дефолту realatime, spacecashe, ssd сами не вставляются. > при этом ssd определяется самостоятельно (см. выше). И наверное relatime? Ну, относительное время доступа? А от spacecache вроде обычно скорее польза чем вред. > вообще то о том и речь, что btrfs даже с этими параметрами > в большинстве тестов был не хуже ext4, а в некоторых лучше. Да собственно он вполне нормально выступил, хотя еще явно есть куда твикать. Ну и самому по себе CoW удобнее несколько иные нагрузки чем классике. Что в этих бенчах просматривается местами (вплоть до некоторой симметрии поведения F2FS и btrfs в некоторых бенчах). > не говоря уже об ext3 и рэйзер. Ну первый - просто древний, с старинным аллокатором. Предсказуемо. А рейзер видимо пострадал за то что не сильно экономен в плане проца. На скорости в сотни мегов в секунду это икнется. > при этом у btr есть ещё потенциал, когда при помощи пары-тройки параметров он может прибавить, Да, там явно есть чего потвикать. > а у остальных нет. Не согласен, в случае F2FS вполне можно попробовать разложить его более удачно. Чем как я понимаю фороникс не заморачивался вообще. > него это сделает другой (включая инсталятор дистра). так что не принимается. Ну как бы в инсталляторах, даже убунтуйских, тип ФС можно выбрать. > вон, ссдэхи маководы покупают взамен винтов и меняют, хотя это там и > не тривиально, и трим настраивают, и то, и сё, и эпиквинами Ой, ну у меня на системном диске пока-что ext4+trim. Разумеется я сам это настраивал. Никакого там эпиквина, пара строк в конфиге. Хотя да, для макофага подобное же считается за геройство. > не надо из людей идиотов априори лепить. это всего-ишь 2-а параметра монтирования, > а не толмуды, как в zfs. Так никто и не считает. Просто тот факт что "95% - идиоты" еще не отменяли.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	40. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от ананим on 22-Фев-13, 14:12
	>> не надо из людей идиотов априори лепить. это всего-ишь 2-а параметра монтирования, а не толмуды, как в zfs. >Так никто и не считает. Просто тот факт что "95% - идиоты" еще не отменяли. глупости. я ж не тюнинг фс предлагаю, как izen в zfs. это всего-лишь 2-а(!!!) параметра монтирования. (блин, ну discard то для трим могли бы вставить?!)
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	64. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от Аноним (??) on 22-Фев-13, 19:13
	> я ж не тюнинг фс предлагаю, как izen в zfs. Он там вообще порно какое-то предлагает через geom :)) > (блин, ну discard то для трим могли бы вставить?!) Ну вообще да, могли бы. Правда на sdhc карте это имхо будет пофигу (а у нее вообще есть такие команды в наборе команд?).
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

16. "Оценка производительности файловой системы F2FS, включённой ..."	–3 +/–
Сообщение от Аноним (??) on 22-Фев-13, 12:28
fs или фс, это он или она или что?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	17. "Оценка производительности файловой системы F2FS, включённой ..."	+2 +/–
	Сообщение от ананим on 22-Фев-13, 12:34
	а оно вам надо? чувствуется же что сфера ваших интересов точно где-то не тут.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	21. "Оценка производительности файловой системы F2FS, включённой ..."	–4 +/–
	Сообщение от Аноним (??) on 22-Фев-13, 12:45
	оно нам надо
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	22. "Оценка производительности файловой системы F2FS, включённой ..."	+2 +/–
	Сообщение от ананим on 22-Фев-13, 12:50
	Так запишитесь на курсы. Вам, как группе, даже могут скидку дать.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

47. "Оценка производительности файловой системы F2FS, включённой ..."	+1 +/–
Сообщение от Аноним (??) on 22-Фев-13, 14:40
Забыли написать какой из этих показывает реальное значение производительности при обычной работе. А не синтетический мусор. Да и про стабильность F2FS не известно. Главное что бы не только быстро работала, но и быстро не порола ssd.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	49. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от Аноним (??) on 22-Фев-13, 14:42
	> обычной работе. Определите "обычная работа". А то обычная работа файлсервера, смартфона, станции для видеомонтажа и офисной печатной машинки "немного" различаются.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	63. "Оценка производительности файловой системы F2FS, включённой ..."	–1 +/–
	Сообщение от RazrFalcon (ok) on 22-Фев-13, 17:44
	А что тут определять то? Старт системы, браузинг и тупинг. Все что делает среднестатистический юзер. А синтетические тесты могут показатать только всякий мусор, который мало влияет на реальную работу. Потестили бы лучше скорость открытия прог и старта системы. Более полезно чем попугаии.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	65. "Оценка производительности файловой системы F2FS, включённой ..."	+/–
	Сообщение от Аноним (??) on 22-Фев-13, 19:17
	> А что тут определять то? > Старт системы, браузинг и тупинг. Все что делает среднестатистический юзер. При браузинге вообще в ФС ничего не упирается. Ну, получим стопку результатов в пределах погрешности. Сделаем вывод что для браузинга все ФС одинаковы? Какой интересный вывод! :) Насчет старта - там еще может время монтирования нас поинтересовать, это еще куда ни шло. А то тут горячие головы JFFS2 предлагают вон. Пусть разложат ее на 160Gb SSD, а потом попробуют это смонтировать, будет интересно посмотреть как им понравится результат :) > А синтетические тесты могут показатать только всякий мусор, который мало влияет на реальную работу. Они пытаются имитировать те или иные ворклоады которые требовательны к дисковой подсистеме. > Потестили бы лучше скорость открытия прог и старта системы. Более полезно чем попугаии. На SSD она настолько мизерная что погрешность измерений будет сравнима с результатом.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема