The OpenNET Project / Index page

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



"Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Заметили полезную информацию ? Пожалуйста добавьте в FAQ на WIKI.
. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/
Сообщение от Аноним (-), 11-Янв-12, 19:02 
> Минимальный блок для записи - 128K вроде как.

Минимальный блок для записи у флеша - страница. Обычно 1...4Кб у nand-флешек из которых делается все и вся, от карт памяти до могучих ssd.

> Сколько там размер сектора? 512b.

Да хрен тебе, теоретик. У флеша нет 512-байтовых секторов. Совсем. Они эмулируются совершенно адскими высерами контроллера с read-modify-write. Кстати это же объясняет почему у некоторых господ иногда странно теряются данные. Вплоть до того что на картах памяти и юсб флехах с FATом изредка у некоторых господ очень неудачно слетает все что угодно, вплоть до таблицы разделов. Если таблица разделов попала в тот же erase-block что и например кусок FAT и питальник неудачно слетел, так что read-modify-write срубился в самом начале, кусок с MBR и таблицей разделов может и не успеть записаться. И если то что FAT должен был пострадать за то что перезаписывался в этотм момент - логично, то вот то что MBR пострадает лишь за то что его угораздило жить в том же erase block - куда менее очевидный и намного менее приятный факт :). По этой причине кстати фабричный формат на флешках и картах довольно характерно выравнивает ФС на характернуые величины, кратные 2^N, по размеру erase-block разумеется.

> Вот и получаем что для изменения одного битика нужно переписать
> целый блок. В современных ssd конечно cow, но писать всё-равно будет
> одним блоком, правда на другой чип.

А тут ты как ни странно не прогнал. Проблема только в том что один хрен загаженный блок стирать придется. Не сейчас, так потом. Единственное чего можно выиграть в стирании его не сей момент а в фоне - скорость записи. Это как езда по дороге со снегом. Если перед тобой медленно тащится снегоуборщик - понятно какая скорость езды получится. А если он заранее проехал, скорость будет другой :)

> Э? Когда сделаете домашку по математике сходите на сайт микрона и почитайте
> даташиты на память. Вот вам картинка для затравки: http://xxx.org.ua/cdm.png

Гражданин, не наглей, да? Я не только читал гору даташитов на всевозможный флеш, я еще и программировать эти самые чипы флеша умею. Вплоть до того что я лично реализовал процедуру зашивки нескольких чипов, покурив даташиты, когда приспичило. Приколись, а? Если ты такой умный и даже даташитами козыряешь - ну покажи, в каком месте ты 512 байтные сектора у флеша углядел, для начала.

[...]
>> И дольше, и wearing в 2 раза увеличивается - ssd подохнет
>> быстрее.
> Это пусть у контроллера голова болит, они шибко умные нынче пошли.

Умнота контроллера не отменяет вполне характерного устройства чипов флеша на уровне весьма базовой физики лежащей в процессе их работы. Этой физике можно подыграть даже через призму контроллера флеша.

>> А еще в винде архаичный ntfs, как ты понимаешь, процент времени потраченый
>> на педалинг огромных битовых карт и прочих бестолковостей на ssd будет
>> роялить еще больше. Поэтому древность и костыльность структур ФС и тут
>> вам будет икаться от души.
> Только почему-то на этой самой ntfs всё работает хер знает когда, показывает
> пиковую производительность,

Меня интересует в основном средняя производительность и worst case, а не пиковая. Пиковая скорость записи в моей системе - несколько Гб в секунду (ram cache hit). Да, кстати линь намного умнее делает. В лине буфером ФС является почти вся свободная память прямо сразу (линь при необходимости просто урезает этот буфер на ходу), тогда как винда отращивает дисковый буфер крайне неохотно. Поэтому в лине dvd-iso sized чушка у меня просто улетает в буфер. Мгновенно. В винде ... хаха, ну ты понял. Половина в буфер влазит а дальше все, жопа. Полфайла быстро пишется, а потом... потом там уже половина исохи ждет своей записи на винч, а буфер уже кончился. И хотя оперативы еще свободно как грязи, винда не спешит отращивать буфера. Пусть лучше юзер 30 секунд ффтыкает на то как это сливается на диск, а прога будет заблочена пока в буфере еще места под данные не появится ;)

> а в лину псе только сейчас осознали что что-то не так в консерватории.
> Неужели так долго копили на ssd для тестов? :)

Линукс мало того что умнее с дисковыми буферами работает, так еще и можно например своп на ссдшник засунуть, без риска в момент его протереть. Поставить минимальную агрессию свопинга, чтобы своп юзался как нечто на крайний случай, когда совсем прижало. И большую часть времени такой своп не будет протирать флеху с ее лимитами на число перезаписей. А вот виндовозный своп флешатину до дыр протрет довольно быстро и я как-то не в курсе - а в винде можно рулить агрессивностью свопа как в лине? А то дефолтная логика там вообще как во времена вин95, видимо с тех пор не менялось. Хотя для машин с 4гб памяти логичны совсем иные настройки чем для машин с 16Мб. В итоге винды позорно тормозят при переключении между увесистыми задачами на машине с совершенно любым количеством оперативки. Хоть 16 гиг воткни, а все-равно несколько гб фуфла в своп сольется при активном использовании. Даже если еще с десяток гигов памяти свободно и вообще нет повода гадить в своп.

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

Оглавление
Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..., opennews, 10-Янв-12, 20:55  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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