Как проверить, все ли записи на жесткий диск выровнены по секторам 4k?

Я использую Linux с 4 жесткими дисками, которые используют сектора 4k. Между моей файловой системой и необработанными устройствами есть несколько уровней: диски > Linux Raid 5 > dm-crypt > LVM.

каждый ресурс, который я нашел, объяснил, как настроить каждый слой, чтобы гарантировать, что записи поверх этого слоя будут выровнены по границе сектора 4k. Однако я не нашел ничего, что объясняет, как проверить, что записи, сделанные на жесткие диски, фактически происходят на границах 4k.

Я не заинтересован в повторном изучении моей настройки, чтобы использовать логику, чтобы определить, правильно ли она выровнена. Я хочу изучить, что на самом деле происходит при записи на диск.

Как я могу регистрировать или просматривать адреса и размер записей, которые делаются на мои жесткие диски, чтобы я мог убедиться, что они правильно выровнены?

25
задан Brian Pellin
22.12.2022 7:11 Количество просмотров материала 3537
Распечатать страницу

2 ответа

задал себе тот же вопрос некоторое время назад и просто сделал следующее:

написал с помощью оболочки пару раз довольно необычную строку в файл (что - то вроде "WackaWacka"), а затем просто искал с помощью шестнадцатеричного дампа (используется od) фактическое содержимое диска и проверено, было ли первое вхождение строки сохранено точно в начале блока 4k.

подсказка: не используйте редактор-он может создавать временные файлы, о которых вы не знаете который также может содержать строки. Сделайте это следующим образом:

 $ for i in 1 2 3 4 5 ...
 >  do
 >   echo "WackaWacka!"
 >  done > mytestfile

Итак .sh_history может содержать строку поиска, но не 5 раз подряд; -)

и затем, просто поиск:

 # sync
 # od -c /dev/sda | grep 'W   a   c   k   a'

Ну, это лучше всего делать на довольно пустом диске, чтобы избежать поиска по гигабайтам данных; -)

2
отвечен ktf 2022-12-23 14:59

написать блок 4k и смотреть, сколько данных читается / записывается с iostat (столбцы 'Blk_read' 'Blk_wrtn'). Если данные не выровнены, запись будет инициировать чтения сначала и вызовет более 4k записей.

вы должны быть осторожны, чтобы не измерить любые обновления метаданных... или просто заглушить их, сделав 1000s 4K пишет.... Поэтому убедитесь, что больше ничего не сканирует диски или не держит открытые файлы (я думаю lsof будет достаточно?), затем откройте новый файл, подожди, беги iostat, напишите 4k в файл, синхронизируйте запись (или просто подождите некоторое время?) затем проверьте iostat снова.

это, кажется, дает разумный выход для меня:

iostat  -d /dev/hdb3
dd if=/dev/urandom of=/mount/path/ofhdb3/tmptest bs=4k count=10000 conv=fdatasync
iostat  -d /dev/hdb3

Примечание iostat ' s man page утверждает, что сообщает в 512-байтовых блоках, и я вижу, что было написано чуть более 80000 дополнительных блоков, и никакие блоки не читались. Если ваше выравнивание выключено, вы увидите аналогичное количество чтений (так как для записи неправильно выровненного 4k требуется чтение двух затронутых блоков, их мутация и написание их обратно). На самом деле, выравнивание важно только для того, чтобы избежать такого чтения (так что это именно то, что вы хотите найти: читает ли триггер рабочей нагрузки записи?)

2
отвечен P.T. 2022-12-23 17:16

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Мы используем cookie. Это позволяет нам анализировать взаимодействие посетителей с сайтом и делать его лучше. Продолжая пользоваться сайтом, вы соглашаетесь с использованием файлов cookie. Политика конфиденциальности
Согласен
Вверх