первая запись моей таблицы разделов:
$ sudo hexdump -Cv -n 16 -s 446 /dev/sda
000001be 80 01 01 00 83 fe ff ff 3f 00 00 00 81 1c 20 03 |........?..... .|
( -Cv описывает формат вывода, -n 16 запрашивает 16 байтов, а -s 446 пропускает первые 446 байтов).
Вы можете видеть, что мой первый раздел является основным разделом Linux и этот раздел начинается с сектора 63 (см., Например, [ здесь] [1] для структуры таблицы разделов).
Тогда я ожидал бы, что за исключением первых 63 секторов и других разделов, / dev / sda1 и / dev / sda точно такие же.
Но это не так, сектор # 2 в / dev / sda1 не совсем совпадает с сектором # 65 в / dev / sda (но они очень похожи, только 16 байтов отличаются):
$ sudo hexdump -Cv -n 512 -s 65b /dev/sda
00008200 00 20 19 00 90 03 64 00 2d 00 05 00 5a 2f 56 00 |. ....d.-...Z/V.|
00008210 b6 b1 16 00 00 00 00 00 02 00 00 00 02 00 00 00 |................|
00008220 00 80 00 00 00 80 00 00 00 20 00 00 d8 38 ee 4c |......... ...8.L|
00008230 9a 01 ef 4c 05 00 24 00 53 ef 01 00 01 00 00 00 |...L..$.S.......|
00008240 59 23 e9 4c 00 4e ed 00 00 00 00 00 01 00 00 00 |Y#.L.N..........|
00008250 00 00 00 00 0b 00 00 00 00 01 00 00 3c 00 00 00 |............<...|
00008260 42 02 00 00 7b 00 00 00 85 23 eb f2 71 67 44 f5 |B...{....#..qgD.|
00008270 bb 8f 6f f2 3a 59 ff 4d 55 62 75 6e 74 75 00 00 |..o.:Y.MUbuntu..|
00008280 00 00 00 00 00 00 00 00 2f 75 62 75 6e 74 75 00 |......../ubuntu.|
00008290 d8 3c df 5d 00 88 ff ff 52 d0 ef 1d 00 00 00 00 |.<.]....R.......|
000082a0 c0 40 51 b6 00 88 ff ff 00 4e c8 bb 00 88 ff ff |.@Q......N......|
000082b0 c0 f6 86 b8 00 88 ff ff 30 2e 0d a0 ff ff ff ff |........0.......|
000082c0 38 3d df 5d 00 88 ff ff 00 00 00 00 00 00 fe 03 |8=.]............|
000082d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000082e0 08 00 00 00 00 00 00 00 00 00 00 00 8a 53 d3 0e |.............S..|
000082f0 7c 7a 43 e4 8b fb ca e0 72 b7 fa c8 01 01 00 00 ||zC.....r.......|
00008300 00 00 00 00 00 00 00 00 16 4c 47 4b 0a f3 03 00 |.........LGK....|
00008310 04 00 00 00 00 00 00 00 00 00 00 00 fe 7f 00 00 |................|
00008320 24 b7 0c 00 fe 7f 00 00 01 00 00 00 22 37 0d 00 |$..........."7..|
00008330 ff 7f 00 00 01 00 00 00 23 37 0d 00 00 00 00 00 |........#7......|
00008340 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 |................|
00008350 00 00 00 00 00 00 00 00 00 00 00 00 1c 00 1c 00 |................|
00008360 01 00 00 00 e9 7f 00 00 00 00 00 00 00 00 00 00 |................|
00008370 00 00 00 00 04 00 00 00 9f 7d bb 00 00 00 00 00 |.........}......|
00008380 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008390 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000083a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000083b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000083c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000083d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000083e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000083f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
против
$ sudo hexdump -Cv -n 512 -s 2b /dev/sda1
00000400 00 20 19 00 90 03 64 00 2d 00 05 00 5a 2f 56 00 |. ....d.-...Z/V.|
00000410 b6 b1 16 00 00 00 00 00 02 00 00 00 02 00 00 00 |................|
00000420 00 80 00 00 00 80 00 00 00 20 00 00 df 76 ef 4c |......... ...v.L|
00000430 df 76 ef 4c 06 00 24 00 53 ef 01 00 01 00 00 00 |.v.L..$.S.......|
00000440 59 23 e9 4c 00 4e ed 00 00 00 00 00 01 00 00 00 |Y#.L.N..........|
00000450 0
linux
partitioning
Гийом Брунери
источник
источник
Ответы:
Приятная находка, так как я смог воспроизвести этот эффект и на моей системе. На моем сайте это происходит в / dev / hda, так что это не проблема SCSI.
Я считаю
whitequarkправильным, что это проблема с кешем. Вот моя интерпретация того, что произошло на вашем сайте ( обратите внимание, что я не уверен, что мое объяснение верно ):/ dev / sda1 используется. Таким образом, «синхронизация» обновляет суперблок каждый раз, когда журнал очищается (или аналогично). Таким образом, диск / dev / sda1 изменен.
Однако ядро не использует комбинированный кеш для / dev / sda и / dev / sda1, вместо этого оба «файла» сами по себе являются кешем. Обновление / dev / sda1 (синхронизация) для этого не делает недействительным кеш / dev / sda. Следовательно, чтение из / dev / sda показывает старое значение кэша (поэтому кэш не синхронизирован с жестким диском), в то время как / dev / sda1 показывает правильные (новые) значения.
Вот ситуация, которая видна на моей стороне. Я пришел сюда, предварительно выполнив несколько дампов в / dev / hda, поэтому он уже кешировал некоторые старые данные:
Хотя / dev / hda не показывает никаких обновлений, / dev / hda2 показывает некоторые изменения. Но когда я сбрасываю кеш и пытаюсь снова, все становится одинаково:
Краткое примечание о том, как воспроизвести:
fdisk -u -lчтобы найти, где начинается раздел. На моей стороне это 1975995hdparmстроку для вашего дискаисточник
После подобных тестов у меня не было различий. Может быть, этот конкретный сектор был написан между каждой свалкой.
Следующая команда сравнивает первые ~ 48 МБ того же сектора, извлеченного из / dev / sda и / dev / sda1:
$ diff <(sudo hexdump -Cv -n $((512*100000)) -s 0x7e00 /dev/sda | awk '{$1=""}1' ) <(sudo hexdump -Cv -n $((512*100000)) /dev/sda1 | awk '{$1=""}1' )Где 0x7e00 - смещение первого раздела.
источник