WDxxEARS и выравнивание разделов

При использовании свежих fdisk и parted о проблеме выравнивания можно забыть.

На FreeBSD используется класс GEOM Nop: http://forum.ixbt.com/topic.cgi?id=11:40759-167#4922

Использовал parted. еще раз внимательно на первое сообщение!

разделы изначально создавались: первый - выровненый по 4к, второй - НЕ выровненый!!!

ясен пень parted орал, что раздел не выровнен и не будет максимальной производительности... но это было сделано умышленно, для тестов.

скорость чтения и записи идентична! что я делаю не так? хочу увидеть падение производительности на НЕвыровненом разделе!

УМВР ЧЯДНТ?

fdisk -l в студию.

fdisk не работает с gpt

parted /dev/sdb unit s print

Model: ATA WDC WD10EARS-003 (scsi)
Disk /dev/sdb: 1953525168s
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
1 2048s 4098047s 4096000s fat32
2 4098050s 8194049s 4096000s fat32

чтото странное. а почему она должна падать? по идее, она _может_ падать, но необязательно. насколько я помню.

дело имено в конкретных моделях винтов с физическими секторами 4к.

http://habrahabr.ru/company/paragon/blog/97436/

я пытаюсь добиться описанного эффекта, и ничего не выходит.

может быть проблема в том, что винт оптимизирует запросы при последовательном доступе? ничего другого в голову не приходит

в результате и чтение и запись проходят на одинаковой скорости
Как вы скорость чтения/записи измеряли?

файловый менеджер, с отключенной системной функцией копирования. сейчас linux не установлен, так что замеры проводил под оффтопиком. для начала записал 1,8Гб файл на каждый из разделов. скорость около 95Мб/с. Затем в FAR копирование в nul, около 103 Мб/с. кэш здесь ни при делах(если операцию провести на одном разделе 2 раза подряд, то винт вообще признаков активности не подает, а скорость достигает 250мб/с). на слух нормальное линейное чтение, как при тесте поверхности

> винт оптимизирует запросы при последовательном доступе?

Независимо от того, сколько ты считал секторов последовательно, физически считывается только один «лишний».

ну ладно... а на записи?

чтобы записать кластер, которы физически лежит на двух секторах, на считать 2 сектора, изменить и снова записать! и?

Ок, поясняю на пальцах. Берём последовательные операции по 4096 байт.

Если раздел расположен правильно, то количество считанных физических секторов равно количеству операций, пенальти нет.

В другом случае при чтении/записи 4096 байт будет считано/записано 8192 (4096+4096). Проигрыш в скорости двукратный. Читаем/пишем последовательно 40960 байт (10 секторов) - будет считано/записано 40960+8192. Проигрыш в скорости 20%. Читаем/пишем последовательно 409600 байт (100 секторов) - будет считано/записано 409600+8192. Проигрыш в скорости 3%.

здесь немного не согласен на счет +8192. согласен с +4096.

и это при условии что данные пишутся последовательно. а это далеко не всегда так.

мы ушли от темы. каким способом протестировать второй раздел и увидеть падение скорости? НА ПРАКТИКЕ.

Да, с +8192 это мой прогон. Вобщем смысл в том, что если ты обрабатываешь одной операцией много последовательных данных, то проигрыш незначителен. Значительным он будет, если ты будешь работать каждый раз с 4кб. Тогда каждый сектор будет считан дважды, вместо одного раза.

мы ушли от темы. каким способом протестировать второй раздел и увидеть падение скорости? НА ПРАКТИКЕ.

Очевидно же: взять прогу с описанным поведением и проверить. Для получения списка прог см. любой тематический обзор.