Em todos os discos magnéticos, a diferença de velocidade entre o primeiro e o último setor é perceptível, até um fator de dois ou três. Isto ainda é verdade com os novos discos multi-terabytes. Portanto, ainda faz sentido reservar os últimos cilindros do disco para arquivos usados com pouca frequência, principalmente backups.
Com um disco particionado, é trivial fazer isso, com a única ressalva de permitir futuras alterações de tamanho.
Mas minha configuração éLVM não particionado. Então eu preciso colocar dois grupos de volumes no mesmo hardware físico (um usando o início de um conjunto de discos, outro usando as extremidades) ou ter certeza de que um volume lógico prefere usar as extensões nos últimos cilindros do hardware . É possível? Temos algum controle sobre onde estará um LV?
Responder1
Eu realmente não concordo que esta seja uma grande preocupação na maioria das cargas de trabalho devido ao cache, às políticas de leitura antecipada e aos elevadores de disco que você pode usar, mas isso é possível com ressalvas.
A melhor maneira de resolver isso seria particionar fisicamente a mídia que você deseja alocar em 'pedaços' que você considera cada extremidade do disco que deseja separar.
Algo assim
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
Em seguida, crie um(s) grupo(s) de volumes. Neste exemplo, estou usando um grupo de volumes, mas pode ser mais fácil ter um VG 'lento' e um VG 'rápido'.
# pvcreate /dev/sda2
# pvcreate /dev/sda3
# vgcreate vg /dev/sda2 /dev/sda3
Em seguida, aloque seus LVs dos referidos volumes físicos.
# lvcreate -n myFastLV -L1TB vg /dev/sda2
# lvcreate -n mySlowLV -L1TB vg /dev/sda3
Advertências aqui: setores defeituosos podem ser substituídos silenciosamente pelo controlador de disco por uma 'reserva' geralmente localizada em outro lugar (que é totalmente independente do fabricante). Além disso, alguns discos mais sofisticados podem remapear internamente os setores de forma logicamente consistente com as reivindicações oferecidas, mas não estão fisicamente no lugar que você esperava que estivessem.
Finalmente, o problema de carga de trabalho que você está sugerindo (pipelining de arquivos enormes) é realmente um problema de carga de trabalho muito sequencial que teria maiores ganhos com o uso de técnicas de pré-alocação nos arquivos gravados (para mantê-los contíguos e não fragmentados).
Em seguida, defina políticas agressivas de leitura antecipada para ler áreas inteiras de setores adjacentes/próximos que provavelmente serão contíguos ao arquivo que você está lendo.
Uma abordagem mais refinada também poderia ser alcançada usando dmsetupo mapeamento dos setores físicos em qualquer ordem e estilo que você desejasse, mas isso não seria muito portátil e provavelmente exigiria mais esforço do que vale a pena no longo prazo (você precisaria de um script para reconstruir o mapeamento na inicialização, por exemplo).