https://opennet.ru/openforum/vsluhforumID3/57761.html В статье "SSDs and filesystems" (часть 1 (http://blogs.gentoo.org/nightmorph/2009/08/02/ssds-and-filesystems), 2 (http://blogs.gentoo.org/nightmorph/2009/08/09/ssds-and-filesystems-part-2часть)) предпринята попытка оценить работу Linux на SSD-накопителе и подобрать оптимальную файловую систему, параметры монтирования и планировщика ввода/вывода.<br><br>URL: http://blogs.gentoo.org/nightmorph/2009/08/02/ssds-and-filesystems<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=22970<br> https://opennet.ru/openforum/vsluhforumID3/57761.html#18 Thu, 22 Sep 2011 07:53:27 GMT Из найденного по теме полезного (озадачился SSD во втором ноутбуке): http://www.bog.pp.ru/hard/SSD.html<br> https://opennet.ru/openforum/vsluhforumID3/57761.html#17 Thu, 22 Sep 2011 06:18:25 GMT &gt; Вот автора статьи я тоже уважаю.<br><br>Статья действительно слабенькая, как и комментарии... накатал с разбегу:<br><br>CFQ has had its overly fair share of troubles back then, mind you &#8212; I&#8217;ve stuck with deadline and was much happier.<br><br>Re XFS, two things:<br>1) the current behaviour regarding &#8220;unsure&#8221; blocks at crash recovery is &#8220;deploy zerogun in case there&#8217;s a sensitive info leak&#8221; (was supposed to change but dunno if they&#8217;ve done it as of 3.0.4 &#8212; it&#8217;s rather a local policy decision, not fs design decision, and should be tweakable);<br>1a) you do want stable hardware, stable kernel+drivers and stable power (including physical connector safety) with XFS to avoid losing data;<br>1b) don&#8217;t call me names, I&#8217;m using XFS since ca. 2003 for storage including multi terabyte by now;<br>2) XFS had pretty bad CPU wakeup footprint (which does matter for portables) a year or two ago, while ext3/ext4 didn&#8217;t (even if they tend to have much worse RAM and disk https://opennet.ru/openforum/vsluhforumID3/57761.html#16 Thu, 22 Sep 2011 05:54:27 GMT Выравнивание начала разделов, -o discard.<br> https://opennet.ru/openforum/vsluhforumID3/57761.html#15 Mon, 29 Nov 2010 14:45:05 GMT &gt; За цитированием из какой-то помойной книжки девяностых готов, про контроллер и озу,<br>&gt; стоящие в SSD, было великодушно забыто. Конечно, ось должна знать<br>&gt; не только про SATA, но и про каждый электрон в ячейке<br>&gt; флеша. Отож... синергизм флеша в линуксе... внушаеть...<br>&gt; Сходите про ваймакс добавьте, которого ни в одном компьютере нет. Охота еще<br>&gt; поржать.<br><br>А в чем товарищь сосбственно был неправ?, NAND и сейчас так работает, хотя уже 2010 год наступил.<br> https://opennet.ru/openforum/vsluhforumID3/57761.html#13 Wed, 12 Aug 2009 05:53:01 GMT Да-да. А ссылки на подробные результаты тестов - это для лохов, которые даже КР573РФ2 вручную запрограммировать не могут.<br><br>И вообще, зачем нам простые пути, когда User294 может рассказать столько умных вещей? Вот автора статьи я тоже уважаю. Взял хороший SSD, ничего не намерял, зато долбанул генту и потом еще два раза ext4. Настоящий пацан!<br><br> https://opennet.ru/openforum/vsluhforumID3/57761.html#12 Wed, 12 Aug 2009 05:46:02 GMT За цитированием из какой-то помойной книжки девяностых готов, про контроллер и озу, стоящие в SSD, было великодушно забыто. Конечно, ось должна знать не только про SATA, но и про каждый электрон в ячейке флеша. Отож... синергизм флеша в линуксе... внушаеть...<br><br>Сходите про ваймакс добавьте, которого ни в одном компьютере нет. Охота еще поржать.<br> https://opennet.ru/openforum/vsluhforumID3/57761.html#11 Wed, 12 Aug 2009 05:40:56 GMT &gt;Угу. В свежей прошивке для OCZ на днях даже автоматическую дефрагментацию во <br>&gt;время простоя прикрутили. <br><br>Вот только это скорее всего совсем не та дефрагментация о которой вы могли подумать.Это скорее всего не переколупывание ФС с ее структурами.А всего лишь низкоуровневый фоновый garbage collector, работающий уровнем ниже (для него вообще файлов нет, есть блоки флеша) который в фоне перегруппирует полузанятые блоки, расчищая свободное место.Не для того чтобы скоростной последовательный доступ к данным обеспечить(с ним все ок и при фрагментации).А чтобы расчистить свободное место флеша от данных, чтобы при очередной записи не надо было стирать erase-блоки полузанятые данными, пыжиться по записи этих данных (ведь юзеру они нужны) и только потом производить запись того что попросили, просрав до этого массу времени на "левую" (с точки зрения юзера) read-modify-write активность(нужную только потому что флеш так работает - стирание только большими блоками и далеко не любая запись катит без стирания всего блока https://opennet.ru/openforum/vsluhforumID3/57761.html#10 Wed, 12 Aug 2009 05:03:10 GMT &gt; Знакомо. Трындеть - не мешки ворочать.<br><br>Во-во.Ляпнуть какую-то ересь не понимая механику процесса - самое простое что можно сделать.<br><br>&gt; Хотя бы одну настройку в студию, которая не применима к hdd<br>&gt; или не дает сравнимого эффекта по производительности. Тогда и поговорим.<br><br>Для флеша удобна запись крупными блоками, с технической точки зрения - лучше всего когда запись выровнена на erase блок(который в современных флешах порядка 128Кб).Тогда не делается "лишней" работы.А если не выравниваться на страницу NAND'а и скажем пичкать флеш кучей мелких записей (менее 2...4 Кб каждая) - ничерта хорошего вообще не выйдет, можно нарваться на read-modify-write страниц нанда (2Кб как правило) ради записи 512 байтов(ну а поскольку врут что это HDD, ось в своем праве работать с ним такими блоками).Не надо быть 7 пядей во лбу чтобы понять что чтение-модификация-запись 2Кб (а если не повезет то еще и медленный erase и перезапись 128Kb erase-блока) ради записи 512 байтов - не очень то эффективно по скорости.А если ось буд https://opennet.ru/openforum/vsluhforumID3/57761.html#9 Wed, 12 Aug 2009 04:17:28 GMT Угу. В свежей прошивке для OCZ на днях даже автоматическую дефрагментацию во время простоя прикрутили.<br>