В статье "SSDs and filesystems" (часть 1 (http://blogs.gentoo.org/nightmorph/2009/08/02/ssds-and-files...), 2 (http://blogs.gentoo.org/nightmorph/2009/08/09/ssds-and-files...часть)) предпринята попытка оценить работу Linux на SSD-накопителе и подобрать оптимальную файловую систему, параметры монтирования и планировщика ввода/вывода.URL: http://blogs.gentoo.org/nightmorph/2009/08/02/ssds-and-files...
Новость: https://www.opennet.ru/opennews/art.shtml?num=22970
Ссылка на 2ую часть кривая.
Муть какая-то. Читаем вот это http://www.anandtech.com/storage/ и не выделываемся.Рекомендации для SSD последних поколений такие же, как для HDD.
> Рекомендации для SSD последних поколений такие же, как для HDD.Ну да, щаззз. Можно конечно скрутить ужа клубочком и натыкать в него иголок.Но ежом от этого он не станет, даже если внешне и будет похоже. И в ряде свойств флешатина сильно отличается от дисковых дел.
Знакомо. Трындеть - не мешки ворочать.Хотя бы одну настройку в студию, которая не применима к hdd или не дает сравнимого эффекта по производительности. Тогда и поговорим.
> Знакомо. Трындеть - не мешки ворочать.Во-во.Ляпнуть какую-то ересь не понимая механику процесса - самое простое что можно сделать.
> Хотя бы одну настройку в студию, которая не применима к hdd
> или не дает сравнимого эффекта по производительности. Тогда и поговорим.Для флеша удобна запись крупными блоками, с технической точки зрения - лучше всего когда запись выровнена на erase блок(который в современных флешах порядка 128Кб).Тогда не делается "лишней" работы.А если не выравниваться на страницу NAND'а и скажем пичкать флеш кучей мелких записей (менее 2...4 Кб каждая) - ничерта хорошего вообще не выйдет, можно нарваться на read-modify-write страниц нанда (2Кб как правило) ради записи 512 байтов(ну а поскольку врут что это HDD, ось в своем праве работать с ним такими блоками).Не надо быть 7 пядей во лбу чтобы понять что чтение-модификация-запись 2Кб (а если не повезет то еще и медленный erase и перезапись 128Kb erase-блока) ради записи 512 байтов - не очень то эффективно по скорости.А если ось будет пичкать "диск" 512 байтными записями - ему придется их изображать, *эмулируя* их из того что есть (а есть чипаки нанда с страницами минимум на 2Кб, это минимальный атомарно записываемый юнит для нанда).Эмуляция ессно делая read-modify-write 2 киловых нанд страниц.Грубо говоря перефигачивая 2К блок чтобы поменять в нем запрошенные 512 байтов (прочли - пропатчили в 2к 512 байтов - записали назад).Правда понять во что эти свойства трансформируются при работе через шибко вумный контроллер достаточно нелегко - его логика работы может быть любой, но в конечном итоге природу он не обманет и никогда не сделает свойства флеша похожими на хард, только интерфейс сэмулирует.В общем случае - желательны большие непрерывные записи, вероятно выравненные на N*128Kb(крутые контроллеры распараллеливают запись на N чипов).И еще у флеша чисто на уровне физики работы чтение куда быстрее записи.
У HDD нет никаких "предпочтений" по части выравнивания на блоки типа 128К, им это похрену.И 512 байтов они пишут без извратов - для них минимальный юнит записи реально такой.И скорость чтения и записи у hdd более-менее одинаковы по понятной причине.Зато при чтении hdd от random seek очень проседает.А флешу оно почти пофигу(последовательное чтение чуть быстрее, но лишь чуть, а вот физическую голову в другой конец дика загнать - не быстро).Так что флеш-диск при чтении не особо страдает от фрагментации, в отличие от механики.
Кой-что общее у них есть - длинные непрерывные записи хороши и тем и другим.По совершенно разным физическим причинам, но все-таки.Наверное отсюда и такие далеко идущие выводы всяких "умников" о том что "похоже на hdd", дескать.Тем не менее, как ни извращайся а кремниевые чипаки с их особенностями технологии флеш не станут идентичны по свойствам вращающимся пластинам.Это так сложно для понимания? :)
За цитированием из какой-то помойной книжки девяностых готов, про контроллер и озу, стоящие в SSD, было великодушно забыто. Конечно, ось должна знать не только про SATA, но и про каждый электрон в ячейке флеша. Отож... синергизм флеша в линуксе... внушаеть...Сходите про ваймакс добавьте, которого ни в одном компьютере нет. Охота еще поржать.
> За цитированием из какой-то помойной книжки девяностых готов, про контроллер и озу,
> стоящие в SSD, было великодушно забыто. Конечно, ось должна знать
> не только про SATA, но и про каждый электрон в ячейке
> флеша. Отож... синергизм флеша в линуксе... внушаеть...
> Сходите про ваймакс добавьте, которого ни в одном компьютере нет. Охота еще
> поржать.А в чем товарищь сосбственно был неправ?, NAND и сейчас так работает, хотя уже 2010 год наступил.
Выравнивание начала разделов, -o discard.
насколько мне извесно, такого рода параметры как чередование кластеров, скважность и тд давным давно вынесены с драйверов в контроллер самого винта, так что говорить о какой то существенной "оптимизации" просто нет смысла. Единственное в чем наблюдается разница между ссд и винтами - это линейность параметров передачи данных. У веников она зависит от цилиндра внутренний-внешний, а у флешек она постоянна для всего объема. Все остальное: трындеть - не мешки ворочать. :))
Угу. В свежей прошивке для OCZ на днях даже автоматическую дефрагментацию во время простоя прикрутили.
>Угу. В свежей прошивке для OCZ на днях даже автоматическую дефрагментацию во
>время простоя прикрутили.Вот только это скорее всего совсем не та дефрагментация о которой вы могли подумать.Это скорее всего не переколупывание ФС с ее структурами.А всего лишь низкоуровневый фоновый garbage collector, работающий уровнем ниже (для него вообще файлов нет, есть блоки флеша) который в фоне перегруппирует полузанятые блоки, расчищая свободное место.Не для того чтобы скоростной последовательный доступ к данным обеспечить(с ним все ок и при фрагментации).А чтобы расчистить свободное место флеша от данных, чтобы при очередной записи не надо было стирать erase-блоки полузанятые данными, пыжиться по записи этих данных (ведь юзеру они нужны) и только потом производить запись того что попросили, просрав до этого массу времени на "левую" (с точки зрения юзера) read-modify-write активность(нужную только потому что флеш так работает - стирание только большими блоками и далеко не любая запись катит без стирания всего блока).Ежу понятно что просто запись в пустой блок - лучше чем чтение-патчинг-запись полузанятого блока.Ну вот фоновый gc и подготавливает плацдарм из пустых блоков которые не надо стирать и патчить.Альтернативный вариант - решать проблемы по мере их возникновения.Проще.Но чревато сильной просадкой записи когда "диск" подзабит и блоков в которые можно просто записать данные без дополнительных плясок с бубном - не оказалось.Собссно фоновый GC - изобретение достаточно древнее.Когда данные стали хранить в флеше, изобрели и фоновые GC.А то что какой-то там OCZ его сейчас релизовал - ну круто, ога.Можно продавать очевидный и всем давно известный фич как что-то крутое и новое (как всегда).
Да-да. А ссылки на подробные результаты тестов - это для лохов, которые даже КР573РФ2 вручную запрограммировать не могут.И вообще, зачем нам простые пути, когда User294 может рассказать столько умных вещей? Вот автора статьи я тоже уважаю. Взял хороший SSD, ничего не намерял, зато долбанул генту и потом еще два раза ext4. Настоящий пацан!
> Вот автора статьи я тоже уважаю.Статья действительно слабенькая, как и комментарии... накатал с разбегу:
CFQ has had its overly fair share of troubles back then, mind you — I’ve stuck with deadline and was much happier.
Re XFS, two things:
1) the current behaviour regarding “unsure” blocks at crash recovery is “deploy zerogun in case there’s a sensitive info leak” (was supposed to change but dunno if they’ve done it as of 3.0.4 — it’s rather a local policy decision, not fs design decision, and should be tweakable);
1a) you do want stable hardware, stable kernel+drivers and stable power (including physical connector safety) with XFS to avoid losing data;
1b) don’t call me names, I’m using XFS since ca. 2003 for storage including multi terabyte by now;
2) XFS had pretty bad CPU wakeup footprint (which does matter for portables) a year or two ago, while ext3/ext4 didn’t (even if they tend to have much worse RAM and disk space overhead).XFS is magnificent under heavy load, especially mixed/scattered one — provided one did take care of the aforementioned.
Re SSDs, the article is pretty weak:
1) no mention of partition alignment which is *critical* for performance and durability of both SSDs and 4k-sectored HDDs (and erase block size issues not covered at all);
2) no mention of “discard” and “noatime” mount options.Part 2 is 404 by now, and I’m too lazy to dig up it on web.archive.org. :)
Из найденного по теме полезного (озадачился SSD во втором ноутбуке): http://www.bog.pp.ru/hard/SSD.html