The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

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

"Исследование поведения Linux на SSD-накопителе"  +/
Сообщение от opennews (??) on 11-Авг-09, 00:49 
В статье "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

Ответить | Правка | Cообщить модератору

Оглавление

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


1. "Исследование поведения Linux на SSD-накопителе"  +/
Сообщение от Аноним (??) on 11-Авг-09, 00:49 
Ссылка на 2ую часть кривая.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Исследование поведения Linux на SSD-накопителе"  +1 +/
Сообщение от _Vitaly_ (ok) on 11-Авг-09, 01:51 
Муть какая-то. Читаем вот это http://www.anandtech.com/storage/ и не выделываемся.

Рекомендации для SSD последних поколений такие же, как для HDD.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Исследование поведения Linux на SSD-накопителе"  +1 +/
Сообщение от User294 (ok) on 11-Авг-09, 13:16 
> Рекомендации для SSD последних поколений такие же, как для HDD.

Ну да, щаззз. Можно конечно скрутить ужа клубочком и натыкать в него иголок.Но ежом от этого он не станет, даже если внешне и будет похоже. И в ряде свойств флешатина сильно отличается от дисковых дел.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Исследование поведения Linux на SSD-накопителе"  +/
Сообщение от _Vitaly_ (ok) on 11-Авг-09, 19:32 
Знакомо. Трындеть - не мешки ворочать.

Хотя бы одну настройку в студию, которая не применима к hdd или не дает сравнимого эффекта по производительности. Тогда и поговорим.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

10. "Исследование поведения Linux на SSD-накопителе"  +3 +/
Сообщение от User294 (ok) on 12-Авг-09, 09:03 
>  Знакомо. Трындеть - не мешки ворочать.

Во-во.Ляпнуть какую-то ересь не понимая механику процесса - самое простое что можно сделать.

> Хотя бы одну настройку в студию, которая не применима к 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", дескать.Тем не менее, как ни извращайся а кремниевые чипаки с их особенностями технологии флеш не станут идентичны по свойствам вращающимся пластинам.Это так сложно для понимания? :)

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

12. "Исследование поведения Linux на SSD-накопителе"  –2 +/
Сообщение от _Vitaly_ (ok) on 12-Авг-09, 09:46 
За цитированием из какой-то помойной книжки девяностых готов, про контроллер и озу,  стоящие в SSD, было великодушно забыто. Конечно, ось должна знать не только про SATA, но и про каждый электрон в ячейке флеша. Отож... синергизм флеша в линуксе... внушаеть...

Сходите про ваймакс добавьте, которого ни в одном компьютере нет. Охота еще поржать.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

15. "Исследование поведения Linux на SSD-накопителе"  +/
Сообщение от ret (ok) on 29-Ноя-10, 17:45 
> За цитированием из какой-то помойной книжки девяностых готов, про контроллер и озу,
>  стоящие в SSD, было великодушно забыто. Конечно, ось должна знать
> не только про SATA, но и про каждый электрон в ячейке
> флеша. Отож... синергизм флеша в линуксе... внушаеть...
> Сходите про ваймакс добавьте, которого ни в одном компьютере нет. Охота еще
> поржать.

А в чем товарищь сосбственно был неправ?, NAND и сейчас так работает, хотя уже 2010 год наступил.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

16. "Исследование поведения Linux на SSD-накопителе"  +/
Сообщение от Michael Shigorin guest on 22-Сен-11, 09:54 
Выравнивание начала разделов, -o discard.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Исследование поведения Linux на SSD-накопителе"  +1 +/
Сообщение от Piter_Ring email(ok) on 12-Авг-09, 00:32 
насколько мне извесно, такого рода параметры как чередование кластеров, скважность и тд давным давно вынесены с драйверов в контроллер самого винта, так что говорить о какой то существенной "оптимизации" просто нет смысла. Единственное в чем наблюдается разница между ссд и винтами - это линейность параметров передачи данных. У веников она зависит от цилиндра внутренний-внешний, а у флешек она постоянна для всего объема. Все остальное:  трындеть - не мешки ворочать. :))
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Исследование поведения Linux на SSD-накопителе"  +/
Сообщение от _Vitaly_ (ok) on 12-Авг-09, 08:17 
Угу. В свежей прошивке для OCZ на днях даже автоматическую дефрагментацию во время простоя прикрутили.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

11. "Исследование поведения Linux на SSD-накопителе"  +1 +/
Сообщение от User294 (ok) on 12-Авг-09, 09:40 
>Угу. В свежей прошивке для OCZ на днях даже автоматическую дефрагментацию во
>время простоя прикрутили.

Вот только это скорее всего совсем не та дефрагментация о которой вы могли подумать.Это скорее всего не переколупывание ФС с ее структурами.А всего лишь низкоуровневый фоновый garbage collector, работающий уровнем ниже (для него вообще файлов нет, есть блоки флеша) который в фоне перегруппирует полузанятые блоки, расчищая свободное место.Не для того чтобы скоростной последовательный доступ к данным обеспечить(с ним все ок и при фрагментации).А чтобы расчистить свободное место флеша от данных, чтобы при очередной записи не надо было стирать erase-блоки полузанятые данными, пыжиться по записи этих данных (ведь юзеру они нужны) и только потом производить запись того что попросили, просрав до этого массу времени на "левую" (с точки зрения юзера) read-modify-write активность(нужную только потому что флеш так работает - стирание только большими блоками и далеко не любая запись катит без стирания всего блока).Ежу понятно что просто запись в пустой блок - лучше чем чтение-патчинг-запись полузанятого блока.Ну вот фоновый gc и подготавливает плацдарм из пустых блоков которые не надо стирать и патчить.Альтернативный вариант - решать проблемы по мере их возникновения.Проще.Но чревато сильной просадкой записи когда "диск" подзабит и блоков в которые можно просто записать данные без дополнительных плясок с бубном - не оказалось.Собссно фоновый GC - изобретение достаточно древнее.Когда данные стали хранить в флеше, изобрели и фоновые GC.А то что какой-то там OCZ его сейчас релизовал - ну круто, ога.Можно продавать очевидный и всем давно известный фич как что-то крутое и новое (как всегда).

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

13. "Исследование поведения Linux на SSD-накопителе"  –1 +/
Сообщение от _Vitaly_ (ok) on 12-Авг-09, 09:53 
Да-да. А ссылки на подробные результаты тестов - это для лохов, которые даже КР573РФ2 вручную запрограммировать не могут.

И вообще, зачем нам простые пути, когда User294 может рассказать столько умных вещей? Вот автора статьи я тоже уважаю. Взял хороший SSD, ничего не намерял, зато долбанул генту и потом еще два раза ext4. Настоящий пацан!

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

17. "Исследование поведения Linux на SSD-накопителе"  +/
Сообщение от Michael Shigorin guest on 22-Сен-11, 10:18 
> Вот автора статьи я тоже уважаю.

Статья действительно слабенькая, как и комментарии... накатал с разбегу:

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. :)

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

18. "Исследование поведения Linux на SSD-накопителе"  +/
Сообщение от Michael Shigorin guest on 22-Сен-11, 11:53 
Из найденного по теме полезного (озадачился SSD во втором ноутбуке): http://www.bog.pp.ru/hard/SSD.html
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру