Структура SSD сильно отличается от HDD, поэтому непонятно как будут располагаться блоки, которые ФС планировала разместить на разных "дорожках" диска HDD на SSD.
С точки зрения ФС отличий нет. Данные будут располагаться там где есть свободное место. А место укажет уже контроллер.
Вот еще кстати пара статей, с описанием TRIM:
http://www.nix.ru/computer_hardware_news/hardware_news_viewer.html?id=158429&page=3http://www.nix.ru/computer_hardware_news/hardware_news_viewer.html?id=160084&page=2Смутила фраза
Именно благодаря данной технологии (повторимся - обязательна поддержка как со стороны операционной системы, так и накопителя), на протяжении всего жизненного цикла SSD без какой-либо дополнительной заботы со стороны пользователя, установки сервисных утилит и прочих не слишком удобных действий будет поддерживаться близкая к максимальной теоретической производительность твердотельного накопителя.
Пользователь решил продолжить мысль 26 Января 2010, 07:51:27:
Кстати, а тут мысль пришла, какие ФС и их опции монтирования приводят при удалении данных к их полному стиранию? Может ли это заменить TRIM?
Пользователь решил продолжить мысль 26 Января 2010, 11:24:43:
И еще, на форониксе конечно сидят те еще тролли, но это единственный тест (из тех, что я видел) быстродействия ФС на современном SSD:
http://www.phoronix.com/scan.php?page=article&item=intel_x25e_filesystems&num=1До кучи нашел еще:
http://www.opennet.ru/opennews/art.shtml?num=20561http://www.opennet.ru/opennews/art.shtml?num=20068http://blog.loxal.net/2009/04/tuning-ext4-for-performance-with.html
Пользователь решил продолжить мысль 26 Января 2010, 23:21:48:
Собственно, из приведенных опций для ext4 что мне НЕ нравится:
data=writeback и nobhИМХО это снижение надежности. Увеличение скорости ext3/4 замечено только при переходе от полного журналирования к журналированию метаданных (ordered), при смене ordered на writeback выигрыш мизерный, а вот риск потери данных повыше.
# journal_data предполагает, что _в_журнал_ пишется всё
# journal_data_ordered предполагает, что в журнал пишутся только метаданные, но перед каждой записью метатанных в журнал делается datasync (т.е. сброс на диск кеша данных - не в журнал!), что-то вроде:
запись данных -> datasync -> запись метаданных (журанала) -> datasync
(только на уровне ядра это, видимо, выглядит так:
взять кеш данных - добавить барьер - добавить метаданные - sync -
# journal_data_writeback предполагает, что в журнал пишутся только метаданные, а данные просто сбрасываются время от времени по таймеру.
При этом уж если сильно бояться износа, то журнал надо вообще отключать, хотя это и сомнительно
That being said, though, it shouldn't be necessary to avoid using a
journal on the Intel SSD. Intel says that laptop will last at least 5
years with 10GB worth of writes per day, and that's a huge amount. I
have an X25-M SSD in my laptop, using an ext4 file system and with the
journal enabled, and since the file system was created 266 days ago,
when I put my X25-M into service, the drive has seen 570GB worth of
writes, so I'm averaging 2.14 GB writes per day. That's well under
the 20GB of writes/per day upon which Intel based its 5 year lifetime
(and most hard drives, and heck, most laptops generally aren't in
service for that long before they are replaced.)
Выдержка из статьи LWN: «Код файловой системы обязан перед созданием записи фиксации [журнала] быть абсолютно уверенным, что вся информация о транзакции помещена в журнал. Просто делать запись в правильном порядке недостаточно; современные диски имеют кэш большого объёма и меняют порядок записи для оптимизации производительности. Поэтому файловая система обязана явно сообщить диску о необходимости записать все журнальные данные на носитель перед созданием записи фиксации; если сначала будет создана запись фиксации, журнал может быть повреждён. Блокирующая система ввода-вывода ядра предоставляет такую возможность благодаря использованию механизма «шлагбаумов» (barriers); проще говоря, «шлагбаум» запрещает запись любых блоков, посланных после него, до того момента, как всё, что было прислано перед «шлагбаумом», будет перенесено на носитель. При использовании «шлагбаумов» файловая система может гарантировать, что всё, что находится на диске, целостно в любой момент времени».
Аналогично, хз зачем менять. Ничто явно на интенсивный износ винта не указывает
noatimeВ последнее время вместо опции noatime рекомендуется сходная опция — relatime. Ей отличие в том, что при ней атрибут времени доступа (atime) обновляется — но только в том случае, если изменились данные файла (атрибут mtime) или его статус (атрибут ctime).
Имеет смысл монтировать SSD с параметром не noatime, а relatime. Иначе время доступа не будет обновляться даже при записи в файл, а некоторые приложения такого не любят.
На ЛОРе божатся что опция абсолютно безвредная, однако ведь в убунте по-умолчанию relatime стоит, а менять дефолтные настройки без точной уверенности что оно таки надо - плохая идея.
commitУвеличение промежутка отложенной записи на диск как я понял, а значит чем больше - тем значительнее уязвимость перед возможными сбоями.
Пользователь решил продолжить мысль 27 Января 2010, 04:47:19:
Ога... с TRIM похоже все ясно:
http://www.ocztechnologyforum.com/forum/showthread.php?54379-Linux-Tips-tweaks-and-alignmentили вкратце
In-kernel automatic TRIM
* You need at least kernel version 2.6.33 or later.
* You need at least firmware version 1.5. Firmware version 1.4 works, but it is too slow.
This thread covers most of the findings on the subject. (Link)(First relevant post)
For Ubuntu users, you need to manually update your kernel if you want automatic trim. The first Ubuntu version to support this feature will probably be Ubuntu 10.10 which will be released at the end of October 2010. Manual trim will of course still be supported through wiper.sh as with the previous firmware (1.4).
Хотя тут
http://forum.notebookreview.com/showthread.php?p=5761204 пишут что
Linux has full Trim support only since 2.6.32. (According to Wikipedia, Trim was prepared in 2.6.28 but not fully implemented.)
Since 10.04 LTS will use 2.6.32, it should support Trim (it seems some of the necessary changes on the file system side have already been implemented with Karmic)
Так что с надеждой буду ждать 10.04 LTS
Тема: Файловые системы пригодные для SSD (Прочитано 33455 раз)
