Во всех магнитных дисках разница в скорости между первым и последним сектором заметна, до двух-трехкратного увеличения. Это справедливо и для новых многотерабайтных дисков. Поэтому все еще имеет смысл резервировать последние цилиндры диска для редко используемых файлов, особенно резервных копий.
При наличии разделов на диске это сделать несложно, с единственной оговоркой: необходимо учесть возможность изменения размера в будущем.
Но моя конфигурациянеразделенный LVM. Поэтому мне нужно либо разместить две группы томов на одном физическом оборудовании (одну, используя начало набора дисков, другую, используя концы), либо убедиться, что логический том предпочитает использовать расширения в последних цилиндрах оборудования. Возможно ли это? Есть ли у нас какой-то контроль над тем, где будет находиться LV?
решение1
Я не совсем согласен, что это представляет собой серьезную проблему для большинства рабочих нагрузок из-за кэширования, политик упреждающего чтения и дисковых подъемников, которые вы можете использовать, но это возможно с оговорками.
Лучшим способом решения этой проблемы будет физическое разбиение носителя, который вы хотите выделить, на «фрагменты», которые вы рассматриваете на каждом конце диска, который вы хотите разделить.
Что-то вроде этого
Number Start End Size Type File system Flags
1 1049kB 1075MB 1074MB primary ext4 boot
2 1075MB 4TB 4TB primary lvm # My fast partition
3 4TB 8TB 4TB primary lvm # My slow partition
Затем создайте группу(ы) томов. В этом примере я использую одну группу томов, но может быть проще иметь «медленную» VG и «быструю» VG.
# pvcreate /dev/sda2
# pvcreate /dev/sda3
# vgcreate vg /dev/sda2 /dev/sda3
Затем распределите ваши LV из указанных физических объемов.
# lvcreate -n myFastLV -L1TB vg /dev/sda2
# lvcreate -n mySlowLV -L1TB vg /dev/sda3
Предостережения здесь таковы, что плохие сектора могут быть молча заменены контроллером диска на «резерв», часто расположенный в другом месте (который полностью независим от производителя). Кроме того, некоторые более навороченные диски могут внутренне переназначать сектора в том, что логически соответствует заявленным, но физически они не находятся там, где вы ожидали.
Наконец, проблемная рабочая нагрузка, которую вы предлагаете (конвейерная обработка огромных файлов), на самом деле является проблемой очень последовательной рабочей нагрузки, которая могла бы получить больший выигрыш от использования методов предварительного выделения памяти для записанных файлов (чтобы они оставались непрерывными и не фрагментировались).
Затем установите агрессивные политики упреждающего чтения, чтобы считывать целые полосы смежных/предстоящих секторов, которые, скорее всего, будут смежными с файлом, который вы читаете.
Более детальный подход можно реализовать, используя dmsetupсопоставление физических секторов в любом порядке и способом, но это не будет достаточно портативным и, вероятно, потребует больше усилий, чем пользы в долгосрочной перспективе (например, вам понадобится скрипт для перестроения сопоставления при загрузке).