Re: балансинг по жестким дискам

[Gena Makhomed]

On Monday, January 12, 2009 at 23:56:26, Olexander Shtepa wrote:

>> OS> Так что "ручная привязка" это уже оттюненый метод (насколько я понял).

>> только при 7 дисках для системы 7 одинаковых копий файла одного файла
>> будут 7-ю различными файлами, и каждый из них будет занимать память в кеше.

>> в случае использования RAID-1 - это будет 1 файл,
>> и если его часто запрашивают - он будет уже в кеше.

OS> Прямой кандидат на DirectIO, если условия задачи позволяют.

при использовании directio файл вообще не будет попадать в кеш.
а частоиспользуемые мелкие файлы лучше все-таки держать в кеше.

и как метод ручной привязки файлов к дискам не тюнить, при N
дисках - эффективность кэширования файлов в памяти средствами
операционной системы будет в N раз хуже, потому что 1 файл
будет представлен в памяти в N копиях. - и это неустранимо.

directio имеет смысл использовать только для (очень) больших файлов.

>> что-то мне подсказывает, что метод, который при выборе диска
>> для запроса "pick the disk whose head is closest" будет работать
>> более оптимально, чем метод привязки файлов к дискам.

OS> Если я не отстал от прогресса, то IDE/SATA диски имеют чисто логическую адресацию
OS> головка/дорожка/сектор и неимеют никакого отношения к физической топологии диска.
OS> Так что это довольно сомнительное свойство..

CHS адресация сейчас не используется, а LBA адресация имеет отношение
к физическому устройству жесткого диска - линейный адрес сектора указывает
положение сектора на пластине, - чем меньше адрес, тем ближе сектор
к краю (началу) диска.

OS> На счет SCSI/SAS - совершенно не в курсе, но сомневаюсь, так как современные диски
OS> имеют переменное число секторов на дорожку, перемещенные сектора - мозг вскипит
OS> всё это учитывать, это дело внутреннего контроллера диска.

seek - это операция позиционирования на дорожку. сколько физически секторов
на трек умещается - это совершенно не важно. зная LBA адреса двух секторов
можно вычислить "расстояние" между ними - чем меньше расстояние,
тем ближе треки на которых размещены эти сектора.

примерно это и происходит в /* Find the disk whose head is closest */
http://lxr.linux.no/linux+v2.6.28/drivers/md/raid1.c#L491

OS> Кстати, именно по этому должен иметь эффект использования очередей (NCQ в SATA),
OS> сам контроллер диска имеет всю физическую инфу и может распланировать процесс самым
OS> эффективным образом.

NCQ/TCQ будет работать еще эффективнее, если на один диск направить
запросы к секторам, что находятся в 1/3 от начала диска, на второй -
те, что надодятся ближе к центру диска, а на третий - те, что ближе
к концу диска. суммарная производительность такого массива будет выше,
чем если бы запросы были бы разбросаны по всем дискам случайным образом.

примерно именно этим и занимается код в функции read_balance
http://lxr.linux.no/linux+v2.6.28/drivers/md/raid1.c#L400

>> OS>  * This routine returns the disk from which the requested read should
>> OS>  * be done. There is a per-array 'next expected sequential IO' sector
>> OS>  * number - if this matches on the next IO then we use the last disk.

>> OS>  * There is also a per-disk 'last know head position' sector that is
>> OS>  * maintained from IRQ contexts, both the normal and the resync IO
>> OS>  * completion handlers update this position correctly. If there is no
>> OS>  * perfect sequential match then we pick the disk whose head is closest.

поэтому я считаю, - нет причин для performance degrade
при использовании software raid-1 в linux через mdraid.

и кроме того - я не вижу причин по которым "ручное" привязывание
файлов к дискам должно быть эффективнее чем код software raid-1.

-- 
Best regards,
 Gena