pierwszy wpis w mojej tablicy partycji to:
$ 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 opisuje format wyjściowy, -n 16 prosi o 16 bajtów, a -s 446 pomija pierwsze 446 bajtów)
Widać, że moja pierwsza partycja jest podstawową partycją Linuksa i że ta partycja zaczyna się od sektora 63 (patrz na przykład [ tutaj] [1] dla struktury tabeli partycji).
Spodziewałbym się wtedy, że oprócz pierwszych 63 sektorów i innych partycji, / dev / sda1 i / dev / sda są dokładnie takie same.
Ale tak nie jest, sektor nr 2 / dev / sda1 nie jest dokładnie taki sam jak sektor nr 65 / dev / sda (ale są one bardzo podobne, różni się tylko 16 bajtami):
$ 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 |[email protected]......|
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 |................|
przeciw
$ 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
Guillaume Brunerie
źródło
źródło
Odpowiedzi:
Niezłe odkrycie, ponieważ mogłem również odtworzyć ten efekt w moim systemie. Na mojej stronie dzieje się to na / dev / hda, więc nie jest to problem SCSI.
Myślę, że
whitequarkma rację, że jest to problem z pamięcią podręczną. Oto moja interpretacja tego, co wydarzyło się na twojej stronie ( pamiętaj, że nie jestem pewien, czy moje wyjaśnienie jest prawidłowe ):/ dev / sda1 jest w użyciu. Dlatego „synchronizacja” aktualizuje superblok za każdym razem, gdy dziennik jest opróżniany (lub podobny). Tak więc dysk / dev / sda1 został zmieniony.
Jednak jądro nie używa połączonej pamięci podręcznej dla / dev / sda i / dev / sda1, zamiast tego oba „pliki” same są buforowane. Aktualizacja / dev / sda1 (sync) w związku z tym nie unieważnia pamięci podręcznej / dev / sda. Dlatego odczyt z / dev / sda pokazuje starą wartość pamięci podręcznej (więc pamięć podręczna nie jest zsynchronizowana z dyskiem twardym), podczas gdy / dev / sda1 pokazuje prawidłowe (nowe) wartości.
Oto sytuacja widziana po mojej stronie. Przyszedłem tutaj, robiąc kilka zrzutów przed / dev / hda, więc już buforowałem niektóre stare dane:
Chociaż / dev / hda nie pokazuje żadnej aktualizacji, / dev / hda2 pokazuje pewne zmiany. Ale kiedy opróżniam skrzynki i próbuję ponownie, wszystko pokazuje się tak samo:
Krótka uwaga na temat reprodukcji:
fdisk -u -laby znaleźć miejsce, w którym zaczyna się partycja. Po mojej stronie jest 1975995hdparmlinię dla swojego dyskuźródło
Po wykonaniu podobnych testów nie otrzymałem żadnych różnic. Być może ten sektor został zapisany między każdym zrzutem.
Następujące polecenie porównuje pierwsze ~ 48 MB tego samego sektora wyodrębnionego z / dev / sda i / 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' )Gdzie 0x7e00 jest przesunięciem pierwszej partycji.
źródło