[вики] покритикуйте статью. 4k alignment

пофиксил ctyptsetup на cryptsetup.)

автору читать до просветления http://rlab.ru/doc/4k_hdd_for_linux.html

Читал ещё в начале года. И?

вот вместо твоей невнятности на вики лучше просто почитать статью и понять что к почему. а тебе - учиться писать понятно а не «умничать».

кстати в реальности можно и не заметить что есть AF на дисках. это было так заметно на ранних WD.
кстати возможно на некоторых дисках AF скрытое, просто никто не раскопал и по скорости не заметно.

>> software raid

* метаданные: в конце раздела

Вообще говоря, по умолчанию теперь в начале. Но оно выровнено.

>вот вместо твоей невнятности на вики лучше просто почитать статью и понять что к почему. а тебе - учиться писать понятно а не «умничать».

Вот если бы ты просмотрел хотя бы по диагонали, ты бы увидел, что в вики как раз конкретика для LVM, luks и mdadm, а невнятности как предисловие.

А в приведённой тобой ссылке хорошее объяснение и тесты, но для голой ФС.

>Вообще говоря, по умолчанию теперь в начале.

Не знал, спасибо. Уже нашёл в man mdadm, сейчас исправлю страницу

Я бы в ссылках всякие %BA%D0%B0 на нормальные буквы заменил

Дух старой школы жил только в «хакере», а теперь и на лорвики. «Ну что, чувак, сегодня мы с тобой забабахаем линукс на хард и будем самыми крутыми на районе. А дистр конечно возьмем самый четкий, восьмую мандриву...»

>Я бы в ссылках всякие %BA%D0%B0 на нормальные буквы заменил

Писал в домашнем mediawiki, у него поведение немного отличается. Пойду читать документацию к jamwiki

У меня кошерный debian squeeze. А если где фраза режет слух, можно и исправить - на то и вики ;) ИМНИП, одной звезды для лорвики достаточно.

>Я бы в ссылках всякие %BA%D0%B0 на нормальные буквы заменил

Зачем? %BA%D0%B0 куда красивее и органичнее смотрится.

>ИМНИП

Исли тебе не изменяет память? Или Иннагулюационный Мантровый НаноИмпульсный Преобразователь? Второе все же как-то более вероятно...

Я не про то. А про стиль изложения. Вот тебе для сравнения начало статьи про гимп из хакера 2000 года:

«GIMP'УЙ ДЕВЧОНОК!!!
Ты уже отрастил бороду? Что значит «упс, забыл»? Мы же договаривались, что будем косить под крутых художников-дизайнеров, а какой художник без бороды и длинных волос? Нет, я так не играю :(. Иди, отращивай бороду, обломист... Постой-ка, есть идея. Мы будем косить под графитчиков! Они ведь тоже художники :). Только без бород - как раз то, что нам надо.»

Знакомый слог?

Уже заменил. Только после # похоже никак...

Поправил. Можно в [ ] после пробела текст править ( в mediawiki - после | )

Знакомый, читал. Прррраклятое влияние маргиналов :). Не перебивается даже хужодественной и классической литературой.

Ну тут уж лень переписывать

Ещё могу предложить глянуть презентацию «Optimize Storage Performance with Red Hat Enterprise Linux» (Mike Snitzer, 09/03/2009), раздел «I/O Topology» — там кратко рассматривается суть topology-aware для дисковой подсистемы. Более детальное описание, правда, не искал.

Спасибо, уже читаю. Ещё в ту же степь немного устаревший «Recommendations for Aligning VMFS Partitions» для esx3. К 4.1 то же самое упоминается очень кратко и без картинок в «Performance Best Practices for VMware vSphere 4.1»

из статьи я так и не понял, как мне узнать, есть у меня эта проблема или нет? есть средства диагностики?

Точно, про самое главное и забыл :)

1) Если диск достаточно новый, а разделы выровнены по границам цилиндров

Т.е. если в выводе

fdisk -lu /dev/sda | grep '^\/' | while read disk start other; do
    if [ ! "$( echo $start % 2048 | bc )" -eq "0" ]; then
        echo "$disk not aligned";
    fi;
done

есть строки вида

/dev/sda1 not aligned

то раздел не выровнен, а если диск новый - то выравнивать было нужно

2) можно проверить скорость записи

dd if=/dev/zero of=/test.raw bs=128k count=800

если скорость меньше 100 МиБ/c, а диск новый ...

Вообще, проще посмотреть информацию о винте у производителя

В parted есть команды проверки.

> можно проверить скорость записи

Диск с AF соберёт данные в своём буфере, перегруппирует и запишет как ему удобнее. При линейной записи потерь почти не будет.

Если check, то её лучше применять с осторожностью. На разделе с software raid (metadata v0.90, в конце раздела; поверх рейда - ext) она сказала

Warning: Partition 1 is 534MB, but the file system is 524MB.

Ignore/Cancel? ^C

align-check

Я на своем WD green ничего не выравнивал. hdparm дает скорость 121МБ/с. Как мне узнать, есть у меня эта проблема, или нет?

Нет проблемы либо диск AF (Advanced Format). Для green 120 МиБ/с - нормальная скорость.

Спасибо, добавил в статью

Это да, но по случайной записи понять гораздо сложнее, если вообще возможно. Добавил примечание, что на advanced format дисках не сработает

Вроде бы не AF (ED15EADS)

ЕМНИП, 4k секторы в WD пошли с 2 Тб и больше

1ТБ тоже есть. у меня где-то такой в шкафу пылится (некуда ставить)

глянул на модель - WD10EARS

Лёгким движением руки Вики превращается... превращается Вики... в журнал «Хакер» для Линукс!

Выровнял разделы, как было 40mb/s так и осталось.

как было 40mb/s так и осталось.

с таким старым винтом эта информация не актуальна.

Ничо так статья. Не шедевр, но нормалёк. В суть проблемы вводит, самые основные советы даёт, читается нормально. Моя оценка - твёрдая четвёрка. Вместо «лучше больше, чтобы исключить кеш» я бы написал про sysctl vm.drop_caches=3 :)

> dd if=/dev/zero of=/home/test.raw bs=128k count=800
У меня моментально отработало. Тест не годится - некоторые ФС (у меня ext4) могут «лениво» заполнять файлы нулями.

> некоторые ФС (у меня ext4) могут «лениво» заполнять файлы нулями.
Почему у меня не заполняет?

Сделал еще раз. Действительно наверно не заполняет, но судя по звуку - пишет на диск уже _после_ отработки dd, т.е. заполняет кеш. У меня вот что получается:
800+0 записей считано
800+0 записей написано
скопировано 104857600 байт (105 MB), 0,207396 c, 506 MB/c

а вот для диска без таблицы разделов это актуально? т.е. у меня на весь терабайт без таблицы разделов накатано XFS. диск, правда, WD Green Adwanced Format. запись гигабайта dd if=/dev/zero of=/terabyte/test.raw bs=128k count=8000 показала 71Mb/s, что ввиду утверждения выше про нормальную скорость в 120 мегабайт несколько странно и печально

> Сделал еще раз. Действительно наверно не заполняет, но судя по звуку - пишет на диск уже _после_ отработки dd, т.е. заполняет кеш.
Можешь использовать time (dd ... ; sync) в таком случае. У тебя, наверное, много оперативки.

У тебя, наверное, много оперативки.

не совсем, тут дело в

vm.dirty_background_ratio = 5
vm.dirty_background_bytes = 0
vm.dirty_ratio = 10
vm.dirty_bytes = 0
vm.dirty_writeback_centisecs = 500
vm.dirty_expire_centisecs = 3000

Т.е. 2-х гиг оперативы хватит чтобы при дефолтных настройках 100 метров влезло со свистом :)

Вместо «лучше больше, чтобы исключить кеш» я бы написал про sysctl vm.drop_caches=3

Насколько я понял из Documentation/filesystems/proc.txt, эта команда просто очищает кэш от чистых объектов. Т.е. если сначала sync, а затем это sysctl, то кэш будет пустой.

Есть вариант лучше: параметр oflag=direct к dd. Для чтения - iflag=direct. Посмотри презентацию, которую рекомендовал GotF. Очень интересная информация, второй день читаю запоем. Там много конкретики и постоянно отсылки на документацию ядра. Из хомячьего синдрома на всякий случай выкачал все pdf redhat'овских саммитов :)

>а вот для диска без таблицы разделов это актуально?

Для диска без раздела не должно быть актуально, за одним исключением. Электроника винта может сама транслировать адреса, обычно это выставляется джампером, см.

1) www.redhat.com/f/pdf/summit/msnitzer_1120_optimize_storage.pdf
2) http://rlab.ru/doc/4k_hdd_for_linux.html

И ещё есть параметр /sys/block/$DEVICE/alignment_offset (не знаю, окажет ли он влияние на уже созданные разделы и ФС)

запись гигабайта dd if=/dev/zero of=/terabyte/test.raw bs=128k count=8000 показала 71Mb/s, что ввиду утверждения выше про нормальную скорость в 120 мегабайт несколько странно и печально

Ну, если честно на гринах 120 МиБ/с в начале диска, а в конце скатывается в 75-80. Если данных на разделе уже много и файл получается фрагментированным, скорость будет ещё меньше.

GotF, огромное спасибо! Эти презентации с redhat summit'ов - нереально полезный источник информации! Главное, в отличие от большинства книг, там всё сжато, сразу видно что ещё не знаешь, и - ссылки на документацию ядра :)

Кстати, на прошлой неделе как раз прошёл summit 2011, наверняка там тоже есть что почитать

wget -r -l1 -A.pdf http://www.redhat.com/summit/2011/presentations/

эта команда просто очищает кэш от чистых объектов

А нам это и надо :). Сравни dd после drop_caches и с O_DIRECT. Думаю будет одно и то же.

Очень интересная информация

спасибо, посмотрю.

>А нам это и надо :)

На запись? Как раз в пустой кэш всё влезет с запасом. Но на всякий случай сравню

что и требовалось доказать :)

jb:~# dd if=/dev/zero of=/test.raw bs=128k count=2400 oflag=direct
2400+0 записей считано
2400+0 записей написано
 скопировано 314572800 байт (315 MB), 3,85988 c, 81,5 MB/c
jb:~# rm /test.raw 
jb:~# sync
jb:~# sync
jb:~# sysctl -w vm.drop_caches=3
vm.drop_caches = 3
jb:~# dd if=/dev/zero of=/test.raw bs=128k count=2400 
2400+0 записей считано
2400+0 записей написано
 скопировано 314572800 байт (315 MB), 0,761303 c, 413 MB/c