la première entrée de ma table de partition est:
$ 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 décrit le format de sortie, -n 16 demande 16 octets et -s 446 saute les 446 premiers octets)
Vous pouvez voir que ma première partition est une partition Linux primaire et que cette partition commence au secteur 63 (voir par exemple [ ici] [1] pour la structure de la table de partition).
Je m'attendrais alors à ce qu'à l'exception des 63 premiers secteurs et des autres partitions, / dev / sda1 et / dev / sda soient exactement les mêmes.
Mais ce n'est pas le cas, le secteur # 2 de / dev / sda1 n'est pas exactement le même que le secteur # 65 de / dev / sda (mais ils sont très similaires, seuls 16 octets sont différents):
$ 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 |................|
contre
$ 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
la source
la source
Réponses:
Belle découverte, car j'ai également pu reproduire cet effet sur mon système. Sur mon site, cela se produit sur / dev / hda, donc ce n'est pas un problème SCSI.
Je pense qu'il
whitequarkest juste qu'il s'agit d'un problème de cache. Voici mon interprétation de ce qui s'est passé sur votre site ( notez cependant que je ne suis pas sûr que mon explication soit correcte ):/ dev / sda1 est en cours d'utilisation. "Sync" met donc à jour le superbloc chaque fois que le journal est vidé (ou similaire). Le disque / dev / sda1 est donc modifié.
Cependant, le noyau n'utilise pas de cache combiné pour / dev / sda et / dev / sda1, au lieu de cela les deux "fichiers" sont du cache à lui seul. La mise à jour de / dev / sda1 (synchronisation) à cet effet n'invalide pas le cache de / dev / sda. Par conséquent, la lecture de / dev / sda montre l'ancienne valeur de cache (donc le cache n'est pas synchronisé avec le disque dur) tandis que / dev / sda1 affiche les valeurs (nouvelles) correctes.
Voici la situation vue de mon côté. Je suis venu ici après avoir fait quelques vidages avant sur / dev / hda, donc il avait déjà mis en cache d'anciennes données:
Alors que / dev / hda n'affiche aucune mise à jour, / dev / hda2 montre quelques modifications. Mais quand je vide les caches et réessaye, tout se passe comme suit:
Brève note sur la façon de se reproduire:
fdisk -u -lpour trouver où la partition commence. A mes côtés c'est 1975995hdparmligne pour votre lecteurla source
Après avoir fait des tests similaires, je n'ai eu aucune différence. Il se peut que ce secteur particulier ait été écrit entre chaque vidage.
La commande suivante compare les premiers ~ 48 Mo du même secteur extraits de / dev / sda et / 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' )Où 0x7e00 est le décalage de la première partition.
la source