Bonjour, je viens poster ici dans l'espoir d'obtenir l'aide d'un expert du BRTFS, depuis quelques jours mon disque de 8To est inaccessible, j'ai déjà été confronté à des problèmes avec le Brtfs par le passé, j'ai essayé toutes les commandes courantes qui d'habitude fonctionnent,
sauf pour ce cas-ci.
Si quelqu'un a une idée de ce qu'il se passe sur ma partition, merci d'avance
Pour gagner du temps voici les commandes que j'ai tentées avec les sorties : (je n'ai pas inclus : "sudo btrfs rescue chunk-recover -y -v /dev/sdb1__" car cela prends une douzaine d'heures à s’exécuter et j'ai oublié de noter la sortie mais elle ne fonctionne pas au final, la réparation échoue, je l’ai tentée deux fois)
Les Superblocks sont valides apparemment , j’ai effectué un** Zero-log*__ et **new UUID__
Je n’ai pas de deuxième disque de 8To sous la main sinon j’aurais pu faire un btrfs restore, j’ai testé elle fonctionne
La réparation avec Gparted à bien sur échoué elle aussi.
La commande Scrub ne fonctionne pas car le disque ne se monte pas (j’ai essayé la commande Mkdir avant le Mount pour créer un point de montage, echec : **mount: /mnt/A-Archives: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error.*__
Infos : sudo fdisk -l
Disque /dev/sdb : 7,28 TiB, 8001563222016 octets, 15628053168 secteurs
Disk model: 004-2CX188
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 1BE9D4A1-AE39-40EE-A84F-E2C783F9566E
Périphérique Début Fin Secteurs Taille Type
/dev/sdb1 2048 15628052479 15628050432 7,3T Système de fichiers Linux
1-sudo mount -t btrfs -o usebackuproot /dev/sdb1 /mnt/A-Archives
mount: /mnt/A-Archives: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error.
2-sudo btrfs rescue super-recover -y -v /dev/sdb1
All Devices:
Device: id = 1, name = /dev/sdb1
Before Recovering:
[All good supers]:
device name = /dev/sdb1
superblock bytenr = 65536
device name = /dev/sdb1
device name = /dev/sdb1
superblock bytenr = 67108864
superblock bytenr = 274877906944
[All bad supers]:
All supers are valid, no need to recover
3-sudo btrfs rescue chunk-recover -y -v /dev/sdb1 : Échec à la fin
4-sudo btrfs check --repair --force --init-csum-tree --init-extent-tree --check-data-csum --clear-ino-cache -p /dev/sdb1
enabling repair mode
Creating a new CRC tree
Opening filesystem to check…
parent transid verify failed on 30474240 wanted 28329 found 28333
parent transid verify failed on 30474240 wanted 28329 found 28333
parent transid verify failed on 30474240 wanted 28329 found 28333
Ignoring transid failure
Checking filesystem on /dev/sdb1
UUID: adea4f4a-d5f0-45ff-a38a-baf5ef14238d
ERROR: Corrupted fs, no valid METADATA block group found
Celle ci donne une sortie longue et redondante, je met des extraits pour ne pas alourdir la page : 5-sudo btrfs check --repair --check-data-csum -p /dev/sdb1
_Starting repair.
Opening filesystem to check…
parent transid verify failed on 30474240 wanted 28329 found 28333
parent transid verify failed on 30474240 wanted 28329 found 28333
parent transid verify failed on 30474240 wanted 28329 found 28333
Ignoring transid failure
Checking filesystem on /dev/sdb1
chunk uuid 90b2575e-cfc3-4405-8b96-1d89cd8706e7
item 0 key (22020096 EXTENT_ITEM 16384) itemoff 16232 itemsize 51
refs 1 gen 676 flags TREE_BLOCK
tree block key (256 UNKNOWN.0 0) level 0
tree block backref root CHUNK_TREE
item 1 key (22020096 BLOCK_GROUP_ITEM 8388608) itemoff 16208 itemsize 24
block group used 16384 chunk_objectid 256 flags SYSTEM|DUP
item 2 key (30408704 BLOCK_GROUP_ITEM 1073741824) itemoff 16184 itemsize 24
block group used 425984 chunk_objectid 256 flags METADATA|DUP
item 3 key (30490624 METADATA_ITEM 0) itemoff 16151 itemsize 33
refs 1 gen 28333 flags TREE_BLOCK
tree block skinny level 0
tree block backref root EXTENT_TREE
item 4 key (30818304 METADATA_ITEM 0) itemoff 16118 itemsize 33
refs 1 gen 28333 flags TREE_BLOCK
tree block skinny level 0
tree block backref root EXTENT_TREE
item 30 key (15062794240 BLOCK_GROUP_ITEM 1073741824) itemoff 15269 itemsize 24
block group used 0 chunk_objectid 256 flags DATA|single
item 31 key (20431503360 BLOCK_GROUP_ITEM 1073741824) itemoff 15245 itemsize 24
block group used 0 chunk_objectid 256 flags DATA|single
item 32 key (25800212480 BLOCK_GROUP_ITEM 1073741824) itemoff 15221 itemsize 24
block group used 0 chunk_objectid 256 flags DATA|single
failed to repair damaged filesystem, aborting
6-sudo btrfs check --repair --force --init-csum-tree --init-extent-tree -p /dev/sdb1
enabling repair mode
Creating a new CRC tree
Opening filesystem to check…
parent transid verify failed on 30474240 wanted 28329 found 28333
parent transid verify failed on 30474240 wanted 28329 found 28333
parent transid verify failed on 30474240 wanted 28329 found 28333
Ignoring transid failure
Checking filesystem on /dev/sdb1
UUID: adea4f4a-d5f0-45ff-a38a-baf5ef14238d
Creating a new extent tree
Reinitialize checksum tree
kernel-shared/ctree.c:2453: split_leaf: BUG_ON 1
triggered, value 1
btrfs(+0x185e9)[0x560097b6f5e9]
btrfs(+0x18ad1)[0x560097b6fad1]
btrfs(+0x1f122)[0x560097b76122]
btrfs(btrfs_search_slot+0xf3f)[0x560097b772c0]
btrfs(btrfs_csum_file_block+0x24b)[0x560097b7f831]
btrfs(+0x7ef03)[0x560097bd5f03]
btrfs(fill_csum_tree+0x26f)[0x560097bd036f]
btrfs(+0x664b1)[0x560097bbd4b1]
btrfs(main+0x328)[0x560097b6eee8]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7fcad9515d90]
/lib/x86_64-linux-gnu/libc.so.6(libc_start_main+0x80)[0x7fcad9515e40]
btrfs(_start+0x25)[0x560097b6ef25]
Abandon_
# Le père du problème ?
Posté par rycks . Évalué à 6. Dernière modification le 05 juillet 2023 à 09:13.
Au début, quel a été la source du problème ? car là je vois un empilement de commandes les unes après les autres mais aucune idée de savoir par exemple s'il y a une panne mécanique du disque.
Donc, quand ça commence à foirer il faut commencer par chercher dans les messages kernel:
Dans votre cas peut-être que vous trouverez des infos "plus loin dans l'historique" donc je commencerait par faire un
À la recherche d'un truc de ce genre (exemples tirés d'un log local mais sans aucune relation avec votre problème)
eric.linuxfr@sud-ouest.org
[^] # Re: Le père du problème ?
Posté par jeremyb14 . Évalué à 2.
Bonjour,
En effet je n'ai pas pensé à checker les logs (bien que je suis très loin de savoir les interpréter, mon niveau est Novice), de mon coté la défaillance à eue lieu sans raison apparente, j'ai allumé ma session Linux un soir (que je partage en dualboot avec un W10 pour la session jeux) et mon disque externe (branché dans une Station d’accueil 4 ports ) refusait de se monter.
Le CrystalDiskInfo ne donne rien de suspect coté Hardware.(j'ai acheté ce disque neuf il y a 2 ans)
Voici les retours commandes que vous m'avez suggéré :
Pour dmesg j'ai isolé ce qui touche à mon disque, Sdc1 pour cette session (hier c’était sdb1, ça alterne une fois sur deux, j'ai un deuxième disque de 6To en NTFS, aujourd'hui c'est lui Sdb1)
La défaillance date du 30 juin mais le log ne remonte pas avant le 2 juillet
1-dmesg :
_scsi 7:0:0:0: Direct-Access WDC WD60 PURZ-85ZUFY1 0125 PQ: 0 ANSI: 6
[ 2.974765] scsi 7:0:0:1: Direct-Access ST8000DM 004-2CX188 0125 PQ: 0 ANSI: 6
[ 2.975074] sd 7:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16).
[ 2.975085] sd 7:0:0:0: Attached scsi generic sg1 type 0
[ 2.975167] sd 7:0:0:0: [sdb] 11721045168 512-byte logical blocks: (6.00 TB/5.46 TiB)
[ 2.975169] sd 7:0:0:0: [sdb] 4096-byte physical blocks
[ 2.975180] sd 7:0:0:1: Attached scsi generic sg2 type 0
[ 2.975298] sd 7:0:0:0: [sdb] Write Protect is off
[ 2.975301] sd 7:0:0:0: [sdb] Mode Sense: 67 00 10 08
[ 2.975444] sd 7:0:0:1: [sdc] Very big device. Trying to use READ CAPACITY(16).
[ 2.975568] sd 7:0:0:0: [sdb] No Caching mode page found
[ 2.975574] fbcon: Taking over console
[ 2.975578] sd 7:0:0:0: [sdb] Assuming drive cache: write through
[ 2.975658] Console: switching
[ 2.975659] sd 7:0:0:1: [sdc] 15628053168 512-byte logical blocks: (8.00 TB/7.28 TiB)
[ 2.975659] to colour frame buffer device 160x45
[ 2.975661] sd 7:0:0:1: [sdc] 4096-byte physical blocks
[ 2.975786] sd 7:0:0:1: [sdc] Write Protect is off
[ 2.975788] sd 7:0:0:1: [sdc] Mode Sense: 67 00 10 08
[ 2.975912] sd 7:0:0:1: [sdc] No Caching mode page found
[ 2.975914] sd 7:0:0:1: [sdc] Assuming drive cache: write through
[ 3.051091] sdb: sdb1
[ 3.051475] sdc: sdc1
[ 3.051797] sd 7:0:0:0: [sdb] Attached SCSI disk
[ 3.052154] sd 7:0:0:1: [sdc] Attached SCSI disk
[ 3.212571] ata6: SATA link down (SStatus 0 SControl 330)
__26.676386] BTRFS info (device sdc1): disk space caching is enabled
[ 26.676389] BTRFS info (device sdc1): has skinny extents
[ 26.718311] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
[ 26.731791] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
[ 26.733455] BTRFS error (device sdc1): open_ctree failed
[ 37.848337] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: errors=remount-ro. Quota mode: none.
_
2-zgrep sdb /var/log/kern.log***
_
/var/log/kern.log:Jul 2 12:47:08 jeremyPC2023 kernel: [54690.407946] BTRFS: device label A-Archives devid 1 transid 28330 /dev/sdb1 scanned by systemd-udevd (18701)
/var/log/kern.log:Jul 2 23:58:19 jeremyPC2023 kernel: [ 2.938994] sd 6:0:0:1: [sdb] Very big device. Trying to use READ CAPACITY(16).
/var/log/kern.log:Jul 2 23:58:19 jeremyPC2023 kernel: [ 2.939179] sd 6:0:0:1: [sdb] 15628053168 512-byte logical blocks: (8.00 TB/7.28 TiB)
/var/log/kern.log:Jul 2 23:58:19 jeremyPC2023 kernel: [ 2.939181] sd 6:0:0:1: [sdb] 4096-byte physical blocks
/var/log/kern.log:Jul 2 23:58:19 jeremyPC2023 kernel: [ 2.939302] sd 6:0:0:1: [sdb] Write Protect is off
/var/log/kern.log:Jul 2 23:58:19 jeremyPC2023 kernel: [ 2.939304] sd 6:0:0:1: [sdb] Mode Sense: 67 00 10 08
/var/log/kern.log:Jul 2 23:58:19 jeremyPC2023 kernel: [ 2.939424] sd 6:0:0:1: [sdb] No Caching mode page found
/var/log/kern.log:Jul 2 23:58:19 jeremyPC2023 kernel: [ 2.939432] sd 6:0:0:1: [sdb] Assuming drive cache: write through
/var/log/kern.log:Jul 2 23:58:19 jeremyPC2023 kernel: [ 2.989498] sdb: sdb1
/var/log/kern.log:Jul 2 23:58:19 jeremyPC2023 kernel: [ 2.989981] sd 6:0:0:1: [sdb] Attached SCSI disk
/var/log/kern.log:Jul 2 23:58:19 jeremyPC2023 kernel: [ 6.773027] BTRFS: device label A-Archives devid 1 transid 28330 /dev/sdb1 scanned by btrfs (417)
/var/log/kern.log:Jul 2 23:58:21 jeremyPC2023 kernel: [ 11.994347] BTRFS info (device sdb1): disk space caching is enabled
/var/log/kern.log:Jul 2 23:58:21 jeremyPC2023 kernel: [ 11.994350] BTRFS info (device sdb1): has skinny extents
/var/log/kern.log:Jul 2 23:58:21 jeremyPC2023 kernel: [ 12.086844] BTRFS error (device sdb1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
/var/log/kern.log:Jul 2 23:58:21 jeremyPC2023 kernel: [ 12.100330] BTRFS error (device sdb1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
/var/log/kern.log:Jul 2 23:58:21 jeremyPC2023 kernel: [ 12.102324] BTRFS error (device sdb1): open_ctree failed
/var/log/kern.log:Jul 2 22:08:44 jeremyPC2023 kernel: [ 630.693434] BTRFS: device label A-Archives devid 1 transid 28330 /dev/sdb1 scanned by pool-udisksd (6660)
/var/log/kern.log:Jul 2 22:08:44 jeremyPC2023 kernel: [ 630.693952] BTRFS info (device sdb1): disk space caching is enabled
/var/log/kern.log:Jul 2 22:08:44 jeremyPC2023 kernel: [ 630.693955] BTRFS info (device sdb1): has skinny extents
/var/log/kern.log:Jul 2 22:08:44 jeremyPC2023 kernel: [ 630.959435] BTRFS error (device sdb1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
/var/log/kern.log:Jul 2 22:08:44 jeremyPC2023 kernel: [ 630.959693] BTRFS error (device sdb1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
/var/log/kern.log:Jul 2 22:08:44 jeremyPC2023 kernel: [ 630.960966] BTRFS error (device sdb1): open_ctree failed
/var/log/kern.log:Jul 2 22:09:17 jeremyPC2023 kernel: [ 664.315369] BTRFS: device label A-Archives devid 1 transid 28330 /dev/sdb1 scanned by pool-udisksd (7173)
/var/log/kern.log:Jul 2 22:09:17 jeremyPC2023 kernel: [ 664.315850] BTRFS info (device sdb1): disk space caching is enabled
/var/log/kern.log:Jul 2 22:09:17 jeremyPC2023 kernel: [ 664.315852] BTRFS info (device sdb1): has skinny extents
/var/log/kern.log:Jul 2 22:09:17 jeremyPC2023 kernel: [ 664.329975] BTRFS error (device sdb1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
/var/log/kern.log:Jul 2 22:09:17 jeremyPC2023 kernel: [ 664.330210] BTRFS error (device sdb1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
/var/log/kern.log:Jul 2 22:09:17 jeremyPC2023 kernel: [ 664.331684] BTRFS error (device sdb1): open_ctree failed
/var/log/kern.log:Jul 2 22:09:34 jeremyPC2023 kernel: [ 681.187993] BTRFS: device label A-Archives devid 1 transid 28330 /dev/sdb1 scanned by pool-udisksd (7233)
/var/log/kern.log:Jul 2 22:09:34 jeremyPC2023 kernel: [ 681.188663] BTRFS info (device sdb1): disk space caching is enabled
/var/log/kern.log:Jul 2 22:09:34 jeremyPC2023 kernel: [ 681.188665] BTRFS info (device sdb1): has skinny extents
/var/log/kern.log:Jul 2 22:09:34 jeremyPC2023 kernel: [ 681.211017] BTRFS error (device sdb1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
/var/log/kern.log:Jul 2 22:09:34 jeremyPC2023 kernel: [ 681.211260] BTRFS error (device sdb1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
/var/log/kern.log:Jul 2 22:09:34 jeremyPC2023 kernel: [ 681.212497] BTRFS error (device sdb1): open_ctree failed
/var/log/kern.log:Jul 2 22:19:56 jeremyPC2023 kernel: [ 3.039347] sd 6:0:0:1: [sdb] Very big device. Trying to use READ CAPACITY(16).
/var/log/kern.log:Jul 2 22:19:56 jeremyPC2023 kernel: [ 3.039720] sd 6:0:0:1: [sdb] 15628053168 512-byte logical blocks: (8.00 TB/7.28 TiB)
/var/log/kern.log:Jul 2 22:19:56 jeremyPC2023 kernel: [ 3.039724] sd 6:0:0:1: [sdb] 4096-byte physical blocks
/var/log/kern.log:Jul 2 22:19:56 jeremyPC2023 kernel: [ 3.039871] sd 6:0:0:1: [sdb] Write Protect is off
/var/log/kern.log:Jul 2 22:19:56 jeremyPC2023 kernel: [ 3.039875] sd 6:0:0:1: [sdb] Mode Sense: 67 00 10 08
/var/log/kern.log:Jul 2 22:19:56 jeremyPC2023 kernel: [ 3.040018] sd 6:0:0:1: [sdb] No Caching mode page found
/var/log/kern.log:Jul 2 22:19:56 jeremyPC2023 kernel: [ 3.040022] sd 6:0:0:1: [sdb] Assuming drive cache: write through
/var/log/kern.log:Jul 2 22:19:56 jeremyPC2023 kernel: [ 3.082511] sdb: sdb1
/var/log/kern.log:Jul 2 22:19:56 jeremyPC2023 kernel: [ 3.083167] sd 6:0:0:1: [sdb] Attached SCSI disk
/var/log/kern.log:Jul 2 22:19:56 jeremyPC2023 kernel: [ 7.705268] BTRFS: device label A-Archives devid 1 transid 28330 /dev/sdb1 scanned by btrfs (421)
/var/log/kern.log:Jul 2 22:19:59 jeremyPC2023 kernel: [ 12.469824] BTRFS info (device sdb1): disk space caching is enabled
/var/log/kern.log:Jul 2 22:19:59 jeremyPC2023 kernel: [ 12.469827] BTRFS info (device sdb1): has skinny extents
/var/log/kern.log:Jul 2 22:19:59 jeremyPC2023 kernel: [ 12.580399] BTRFS error (device sdb1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
/var/log/kern.log:Jul 2 22:19:59 jeremyPC2023 kernel: [ 12.593885] BTRFS error (device sdb1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
/var/log/kern.log:Jul 2 22:19:59 jeremyPC2023 kernel: [ 12.595630] BTRFS error (device sdb1): open_ctree failed_
3-grep sdc /var/log/kern.log
Jul 2 23:58:19 jeremyPC2023 kernel: [ 3.198201] sdc: sdc1
Jul 2 22:19:56 jeremyPC2023 kernel: [ 3.202338] sdc: sdc1
Jul 3 23:34:52 jeremyPC2023 kernel: [ 2.943500] sdc: sdc1
Jul 3 23:34:52 jeremyPC2023 kernel: [ 6.539830] BTRFS: device label A-Archives devid 1 transid 28332 /dev/sdc1 scanned by btrfs (414)
Jul 3 23:34:54 jeremyPC2023 kernel: [ 10.754295] BTRFS info (device sdc1): disk space caching is enabled
Jul 3 23:34:54 jeremyPC2023 kernel: [ 10.754298] BTRFS info (device sdc1): has skinny extents
Jul 3 23:34:54 jeremyPC2023 kernel: [ 10.922314] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
Jul 3 23:34:54 jeremyPC2023 kernel: [ 10.935802] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
Jul 3 23:34:54 jeremyPC2023 kernel: [ 10.937675] BTRFS error (device sdc1): open_ctree failed
Jul 3 21:36:17 jeremyPC2023 kernel: [ 92.014773] BTRFS: device label A-Archives devid 1 transid 28332 /dev/sdc1 scanned by pool-udisksd (6183)
Jul 3 21:36:17 jeremyPC2023 kernel: [ 92.015195] BTRFS info (device sdc1): disk space caching is enabled
Jul 3 21:36:17 jeremyPC2023 kernel: [ 92.015196] BTRFS info (device sdc1): has skinny extents
Jul 3 21:36:17 jeremyPC2023 kernel: [ 92.044555] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
Jul 3 21:36:17 jeremyPC2023 kernel: [ 92.044856] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
Jul 3 21:36:17 jeremyPC2023 kernel: [ 92.047729] BTRFS error (device sdc1): open_ctree failed
Jul 3 23:28:06 jeremyPC2023 kernel: [ 6800.379936] BTRFS: device label A-Archives devid 1 transid 28332 /dev/sdc1 scanned by systemd-udevd (13379)
Jul 3 23:29:28 jeremyPC2023 kernel: [ 6883.164589] BTRFS info (device sdc1): disk space caching is enabled
Jul 3 23:29:28 jeremyPC2023 kernel: [ 6883.164593] BTRFS info (device sdc1): has skinny extents
Jul 3 23:29:28 jeremyPC2023 kernel: [ 6883.216975] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
Jul 3 23:29:28 jeremyPC2023 kernel: [ 6883.230472] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
Jul 3 23:29:28 jeremyPC2023 kernel: [ 6883.233280] BTRFS error (device sdc1): open_ctree failed
Jul 3 23:33:11 jeremyPC2023 kernel: [ 7105.717625] BTRFS: device label A-Archives devid 1 transid 28333 /dev/sdc1 scanned by systemd-udevd (113571)
Jul 4 00:02:11 jeremyPC2023 kernel: [ 8846.278032] BTRFS info (device sdc1): disk space caching is enabled
Jul 4 00:02:11 jeremyPC2023 kernel: [ 8846.278036] BTRFS info (device sdc1): has skinny extents
Jul 4 00:02:12 jeremyPC2023 kernel: [ 8847.226343] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
Jul 4 00:02:12 jeremyPC2023 kernel: [ 8847.239645] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
Jul 4 00:02:12 jeremyPC2023 kernel: [ 8847.241927] BTRFS error (device sdc1): open_ctree failed
Jul 4 00:03:58 jeremyPC2023 kernel: [ 8952.805943] BTRFS: device label A-Archives devid 1 transid 28333 /dev/sdc1 scanned by mount (117634)
Jul 4 00:03:58 jeremyPC2023 kernel: [ 8952.806684] BTRFS warning (device sdc1): 'usebackuproot' is deprecated, use 'rescue=usebackuproot' instead
Jul 4 00:03:58 jeremyPC2023 kernel: [ 8952.806686] BTRFS info (device sdc1): trying to use backup root at mount time
Jul 4 00:03:58 jeremyPC2023 kernel: [ 8952.806688] BTRFS info (device sdc1): disk space caching is enabled
Jul 4 00:03:58 jeremyPC2023 kernel: [ 8952.806688] BTRFS info (device sdc1): has skinny extents
Jul 4 00:03:58 jeremyPC2023 kernel: [ 8952.819308] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
Jul 4 00:03:58 jeremyPC2023 kernel: [ 8952.819525] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
Jul 4 00:03:58 jeremyPC2023 kernel: [ 8952.819947] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
Jul 4 00:03:58 jeremyPC2023 kernel: [ 8952.820159] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
Jul 4 00:03:58 jeremyPC2023 kernel: [ 8952.820161] BTRFS error (device sdc1): parent transid verify failed on 33406976 wanted 28330 found 28332
Jul 4 00:03:58 jeremyPC2023 kernel: [ 8952.845977] BTRFS error (device sdc1): parent transid verify failed on 33406976 wanted 28330 found 28332
Jul 4 00:03:58 jeremyPC2023 kernel: [ 8952.845980] BTRFS warning (device sdc1): couldn't read tree root
Jul 4 00:03:58 jeremyPC2023 kernel: [ 8952.845982] BTRFS error (device sdc1): parent transid verify failed on 33505280 wanted 28331 found 28333
Jul 4 00:03:58 jeremyPC2023 kernel: [ 8952.846496] BTRFS error (device sdc1): parent transid verify failed on 33505280 wanted 28331 found 28333
Jul 4 00:03:58 jeremyPC2023 kernel: [ 8952.846497] BTRFS warning (device sdc1): couldn't read tree root
Jul 4 00:03:58 jeremyPC2023 kernel: [ 8952.847848] BTRFS error (device sdc1): open_ctree failed
Jul 4 00:10:24 jeremyPC2023 kernel: [ 9339.195256] BTRFS: device label A-Archives devid 1 transid 28333 /dev/sdc1 scanned by systemd-udevd (117707)
Jul 4 00:19:32 jeremyPC2023 kernel: [ 9886.937632] BTRFS info (device sdc1): disk space caching is enabled
Jul 4 00:19:32 jeremyPC2023 kernel: [ 9886.937635] BTRFS info (device sdc1): has skinny extents
Jul 4 00:19:32 jeremyPC2023 kernel: [ 9886.950106] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
Jul 4 00:19:32 jeremyPC2023 kernel: [ 9886.950324] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
Jul 4 00:19:32 jeremyPC2023 kernel: [ 9886.951671] BTRFS error (device sdc1): open_ctree failed
Jul 4 02:11:53 jeremyPC2023 kernel: [16627.597670] BTRFS: device label A-Archives devid 1 transid 28333 /dev/sdc1 scanned by systemd-udevd (119355)
Jul 4 04:27:00 jeremyPC2023 kernel: [24734.701219] BTRFS info (device sdc1): disk space caching is enabled
Jul 4 04:27:00 jeremyPC2023 kernel: [24734.701223] BTRFS info (device sdc1): has skinny extents
Jul 4 04:27:00 jeremyPC2023 kernel: [24734.982338] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
Jul 4 04:27:00 jeremyPC2023 kernel: [24734.995960] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
Jul 4 04:27:00 jeremyPC2023 kernel: [24734.997902] BTRFS error (device sdc1): open_ctree failed
Jul 4 22:51:45 jeremyPC2023 kernel: [ 3.046156] sdc: sdc1
Jul 5 09:18:56 jeremyPC2023 kernel: [ 3.051475] sdc: sdc1
Jul 5 09:18:56 jeremyPC2023 kernel: [ 6.000464] BTRFS: device label A-Archives devid 1 transid 28333 /dev/sdc1 scanned by btrfs (416)
Jul 5 09:19:14 jeremyPC2023 kernel: [ 26.676386] BTRFS info (device sdc1): disk space caching is enabled
Jul 5 09:19:14 jeremyPC2023 kernel: [ 26.676389] BTRFS info (device sdc1): has skinny extents
Jul 5 09:19:14 jeremyPC2023 kernel: [ 26.718311] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
Jul 5 09:19:14 jeremyPC2023 kernel: [ 26.731791] BTRFS error (device sdc1): parent transid verify failed on 1005360775168 wanted 26215 found 26208
Jul 5 09:19:14 jeremyPC2023 kernel: [ 26.733455] BTRFS error (device sdc1): open_ctree failed
[^] # Re: Le père du problème ?
Posté par lem__mel . Évalué à 2. Dernière modification le 05 juillet 2023 à 11:42.
le problème est que je ne vois pas d'erreur matériel et tout semble logiciel (au niveau de BRTFS).
Tout d'abord il faut être sûr de démarrer avec un disque opérationnel et ne rien écrire sur le disque fautif.
Ensuite il est possible de tomber sur un bug de btrfs mais c'est peu probable, donc il faut se poser au moins les questions suivantes :
- que s'est-il passé avant de constater le problème ?
- une mise à jour de Windows ? Une mise à jour du BIOS ? Une coupure d'électricité ?
- peut-être des paramètres au niveau du BIOS ont changé ? (ceux des disques AHCI, SCSI, whatever) ?
- peut-être est-ce plutôt un problème trouvant sa source ailleurs ? (par exemple la RAM via https://www.system-rescue.org/)
- y-a-t-il des erreurs SMART qui sont remontées ? (https://doc.ubuntu-fr.org/smartmontools)
- quel type de disque dur est-ce ? N'y-a-t-il pas des problèmes matériels ou de fiabilités enregistrés relatif à votre disque sur internet ou les forums du constructeur ?
- quelle est la distribution utilisée ? Est-elle en version stable ? La version du noyau est-elle fiable ? Le message d'erreur n'existe-t-il pas quelque part sur le net associé à une version du noyau ?
En bref il y a plein d'axes de recherche.
Bon courage.
[^] # Re: Le père du problème ?
Posté par jeremyb14 . Évalué à 3.
Merci bien pour ces pistes, le matériel n'est pas en cause j'ai vérifié
je suis tombé sur un autre forum sur quelqu'un ayant eu le même cas que moi et cela venait d'une mise à jours du Kernel Linux qui ne prenait pas en charge certaines fonctions avancées du Brtfs
ceci dit j'ai essayé de monter mon disque sur W10 avec WinBrtfs et aussi sur un live USB d'une version Linux Mint antérieure, l'erreur persiste donc je pense que je peux éliminer cette piste.
C'est pourquoi j'ai besoins d'un expert de ce syteme de fichiers, il doit bien exister une commande spécifique pour ma situation ?
Ce qui est sur c'est que une fois ce problème réglé, je formate mon disque et repasse en NTFS, j'ai jamais eu autant de galères depuis que je suis en BRTFS (ça plante comme ça une fois par ans et sans raison apparente, il m'a lair bien fragile quand même ! ) car au moins avec le NTFS oui on perd des fichiers de temps en temps par corruption du fs mais au moins on conserve l’accès à sa partition !
je vais enquêter avec votre chek-list :
-que s'est-il passé avant de constater le problème ?
Rien, la routine quotidienne
- une mise à jour de Windows ? Une mise à jour du BIOS ? Une coupure d'électricité ?
Pas de coupure, pas de MAJ du Bios, Windows n'interagit pas avec ce disque normalement ! (je n'ai installé WinBrtfs que hier pour tester)
- peut-être des paramètres au niveau du BIOS ont changé ? (ceux des disques AHCI, SCSI, whatever) ?
non
- peut-être est-ce plutôt un problème trouvant sa source ailleurs ? (par exemple la RAM via https://www.system-rescue.org/)
_A voir, je ferais un vidage de la Ram avec Ccleaner
- y-a-t-il des erreurs SMART qui sont remontées ? (https://doc.ubuntu-fr.org/smartmontools)
non
- quel type de disque dur est-ce ? N'y-a-t-il pas des problèmes matériels ou de fiabilités enregistrés relatif à votre disque sur internet ou les forums du constructeur ?
Type : ST8000DM004-2CX188 / SATA/600
- quelle est la distribution utilisée ? Est-elle en version stable ? La version du noyau est-elle fiable ? Le message d'erreur n'existe-t-il pas quelque part sur le net associé à une version du noyau ?
-Version stable et à jour de Linux Mint 21.1,
je regarderais si il existe des bugs entre le noyau actuel et le Brtfs
[^] # Re: Le père du problème ?
Posté par lem__mel . Évalué à 3.
Étant donné qu'il s'agit de Linux Mint, il faut jeter un œil dans les rapports de bug dans LinuxMint/Ubuntu/Debian.
Mais comme dit avant il y a peu de chances que ce soit un bug dans BTRFS (on n'a pas tous la « chance » de tomber le premier sur un bug) ; il doit y avoir quelque chose qui a provoqué cela. Il est possible d'étudier les logs Windows car si le matériel a changé de comportement/paramétrage, alors cela figurera dedans également.
Est-il possible de monter ce disque dans un autre PC et de le démarrer avec un autre Linux ? (e.g. RescueLinux)
Ensuite pour ce qui est de réparer le FS (ce qui est la réelle question), je ne peux guère aider ; par le passé je tentais de récupérer ce qui était récupérable, puis je repartais à zéro (en ayant tranché sur la cause de l'erreur de disque ; à chaque fois cela a été matériel donc la faute du disque, une fois cela était l'alimentation de la carte mère - était-ce la carte ? l'alim ? je ne sais pas - qui était en tort).
PS : je ne connais pas ccleaner mais RescueLinux avec le composant memtest est fiable (déjà utilisé par le passé ; c'est juste long).
PPS : souvent quand je cherche la cause d'un problème que je rencontre et que je ne trouve rien de pertinent (mais en ayant vraiment bien cherché), c'est que le problème vient de mon côté.
[^] # Re: Le père du problème ?
Posté par jeremyb14 . Évalué à 2.
Merci je vais m'y pencher ce soir, je vous tient au courant
[^] # Re: Le père du problème ?
Posté par NeoX . Évalué à 5.
je vois dans ces logs que tu travailles sur sd*b1, alors que les logs ralent sur sdc*1
[^] # Re: Le père du problème ?
Posté par jeremyb14 . Évalué à 3.
oui parce que j'ai deux disques dans une station d'acceuil, le 8TO Brtfs et le 6To NTFS, à chaque démmarage de session l'un et l'autre intervertissent leur ID (sdc1 / sdb1)
# on dirait une erreur pas triviale du tout
Posté par Luc-Skywalker . Évalué à 2.
c'est le message d'erreur. Je n'ai pas trouvé de solution évidente après une rapide recherche avec les mots clefs "parent transid verify failed". Il y a pourtant pas mal de sujets qui abordent le problème. Mais ceux qui sont marqués comme [solved] sont plutôt anciens et les sujets récents sont sans solutions. Mais c'est peut être à approfondir.
Sinon, je dirais que ton disque est peut être définitivement endommagé.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: on dirait une erreur pas triviale du tout
Posté par jeremyb14 . Évalué à 1.
oui en effet, cette erreur marque aussi la fin de mon experience avec le BRTFS, je repasse au NTFS.
Existe-t-il un outil pour pouvoir parcourir une arborescence BRTFS d'une partition non montable ?
Par ce que j'ai juste besoins de récuper quelques centaines de fichiers, le reste est sauvegardé dans le Cloud.
# Idée conne en passant...
Posté par rycks . Évalué à 4.
Hummm,
comme ce sont des disques externes, est-ce qu'à tout hasard le pb ne proviendrait il pas du câble, de la prise, ou d'un truc du genre ?
Le pb c'est que maintenant que l'erreur existe c'est trop tard et il faut essayer de s'en sortir
Donc il faut de l'espace disque (au moins 6 To donc)
Faire une image disque (mais c'est peut-être trop tard vu que vous avez déjà lancé plein de commandes un peu à l'aveugle pour essayer de corriger le pb) -> dd if=disque_hs of=image_disque (ou of=nouveau_disque_physique)
travailler sur l'image disque pour essayer de réparer le pb
eric.linuxfr@sud-ouest.org
[^] # Re: Idée conne en passant...
Posté par jeremyb14 . Évalué à 1.
mes deux disques internes sont branchés dans une station FANTEC QB-35US3-6G que j’avais acheté justement pour réduire les sources potentiels de corruptions et pour ce qui est de faire une image disque ou un Brtfs restore, hélas je n'ai pas d'autre disque de 8to sous la main, surtout que mon disque est remplis à 99% (il n'y a que 19go de libres dessus )
Et pour mon deuxieme disque NTFS de 6TO et bien il est déja à 50% remplis.
Si j’avais un outils pour parcourir mon arborescence je pourrais extraire les fichiers que je n’ai pas eu le temps de synchroniser dans ma sauvegarde en ligne.
J'ai déjà été confronté à ce type de corruption du Brtfs et les commandes citées plus haut fonctionnaient d'habitude.
[^] # Re: Idée conne en passant...
Posté par hitmanu . Évalué à 3.
il n’y a peut-être pas assez de place pour effectuer une réparation de ton disque, les 19go son sûrement pour root.
Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.
[^] # Re: Idée conne en passant...
Posté par jeremyb14 . Évalué à 2.
oui c'est une piste sérieuse, j'ai du copier le fichier de trop qui a vérouillé la partition, comment faire ?
[^] # Re: Idée conne en passant...
Posté par Marc Quinton . Évalué à 4.
exact, de mémoire je crois avoir eu une défaillance avec cette problématique de partition pleine et pour terminer un disque HS ; ca peut se tester facilement sur une PF virtualisée.
c'est tout de même excessif d'avoir un système corrompu après avoir "trop écrit" sur une partition BTRFS.
[^] # Re: Idée conne en passant...
Posté par jeremyb14 . Évalué à 3.
je suis d'accords,c'est abusé si c'est ça
et ça explique pourquoi dans les précédents cas j'arrivais à corriger, parce que mon disque n'était pas aussi plein.
c'est quoi une PF virtualisée? c'est une VM non ? j'ai VMWare Workstation si c'est ça je pourrais en monter une.
[^] # Re: Idée conne en passant...
Posté par Marc Quinton . Évalué à 3.
encore une idée en passant par là (lien) :
btrfsck --init-extent-tree /dev/sd?
[^] # Re: Idée conne en passant...
Posté par jeremyb14 . Évalué à 3.
Merci ! j'ai essayé toute les commandes et j'ai les mêmes sorties, celle ci est intéressante :
sudo btrfs-find-root /dev/sdc1
_parent transid verify failed on 30474240 wanted 28329 found 28333
parent transid verify failed on 30474240 wanted 28329 found 28333
WARNING: could not setup extent tree, skipping it
Superblock thinks the generation is 28333
Superblock thinks the level is 1
Found tree root at 33505280 gen 28333 level 1
Well block 33406976(gen: 28332 level: 1) seems good, but generation/level doesn't match, want gen: 28333 level: 1
_
je ne sais pas ce que cela veut dire, évidemment, quant à : sudo btrfsck --init-extent-tree /dev/sdc1
je l’avais déjà faite elle échoue, voici des extraits des résultats (très long ! ) :
_Starting repair.
Opening filesystem to check…
parent transid verify failed on 30474240 wanted 28329 found 28333
parent transid verify failed on 30474240 wanted 28329 found 28333
parent transid verify failed on 30474240 wanted 28329 found 28333
Ignoring transid failure
Checking filesystem on /dev/sdc1
UUID: adea4f4a-d5f0-45ff-a38a-baf5ef14238d
Creating a new extent tree
Failed to find [33406976, 168, 16384]
btrfs unable to find ref byte nr 33505280 parent 0 root 1 owner 1 offset 0
path->slots[0]: 27 path->nodes[0]:
leaf 30425088 items 187 free space 6895 generation 28334 owner EXTENT_TREE
leaf 30425088 flags 0x0() backref revision 1
fs uuid adea4f4a-d5f0-45ff-a38a-baf5ef14238d
chunk uuid 90b2575e-cfc3-4405-8b96-1d89cd8706e7
item 0 key (22020096 BLOCK_GROUP_ITEM 8388608) itemoff 16259 itemsize 24
block group used 0 chunk_objectid 256 flags SYSTEM|DUP
item 1 key (30408704 BLOCK_GROUP_ITEM 1073741824) itemoff 16235 itemsize 24
block group used 16384 chunk_objectid 256 flags METADATA|DUP
item 2 key (30425088 METADATA_ITEM 0) itemoff 16202 itemsize 33
refs 1 gen 28334 flags TREE_BLOCK
tree block skinny level 0
tree block backref root EXTENT_TREE
item 3 key (30474240 METADATA_ITEM 1) itemoff 16169 itemsize 33
ect,,,
item 328 key (2310722813952 BLOCK_GROUP_ITEM 1073741824) itemoff 8387 itemsize 24
block group used 0 chunk_objectid 256 flags DATA|single
item 329 key (2311796555776 BLOCK_GROUP_ITEM 1073741824) itemoff 8363 itemsize 24
block group used 0 chunk_objectid 256 flags DATA|single
item 330 key (2312870297600 BLOCK_GROUP_ITEM 1073741824) itemoff 8339 itemsize 24
block group used 0 chunk_objectid 256 flags DATA|single
item 331 key (2313944039424 BLOCK_GROUP_ITEM 1073741824) itemoff 8315 itemsize 24
block group used 0 chunk_objectid 256 flags DATA|single
[1/7] checking root items… skipped
[2/7] checking extents
parent transid verify failed on 1005345538048 wanted 26215 found 26208
Ignoring transid failure
parent transid verify failed on 1005352157184 wanted 26215 found 26208
Ignoring transid failure
parent transid verify failed on 1005360775168 wanted 26215 found 26208
Ignoring transid failure
parent transid verify failed on 1005341835264 wanted 26215 found 26211
Ignoring transid failure
parent transid verify failed on 1005341835264 wanted 26215 found 26211
Ignoring transid failure
parent transid verify failed on 1005345538048 wanted 26215 found 26208
Ignoring transid failure
parent transid verify failed on 1005352157184 wanted 26215 found 26208
Ignoring transid failure
parent transid verify failed on 1005360775168 wanted 26215 found 26208
Ignoring transid failure
parent transid verify failed on 1005347192832 wanted 26215 found 26208
Ignoring transid failure
parent transid verify failed on 1005352665088 wanted 26215 found 26208
Ignoring transid failure
parent transid verify failed on 1005337755648 wanted 26215 found 26208
parent transid verify failed on 1005337755648 wanted 26215 found 26208
parent transid verify failed on 1005337755648 wanted 26215 found 26208
Ignoring transid failure
ref mismatch on [22020096 16384] extent item 0, found 1
tree backref 22020096 root 3 not found in extent tree
backpointer mismatch on [22020096 16384]
adding new tree backref on start 22020096 len 16384 parent 0 root 3
Failed to find [34734080, 168, 16384]
btrfs unable to find ref byte nr 35110912 parent 0 root 1 owner 0 offset 0
path->slots[0]: 30 path->nodes[0]:
leaf 33652736 items 190 free space 6703 generation 28335 owner EXTENT_TREE
leaf 33652736 flags 0x0() backref revision 1
fs uuid adea4f4a-d5f0-45ff-a38a-baf5ef14238d
chunk uuid 90b2575e-cfc3-4405-8b96-1d89cd8706e7
item 0 key (22020096 EXTENT_ITEM 16384) itemoff 16232 itemsize 51
refs 1 gen 676 flags TREE_BLOCK
tree block key (256 UNKNOWN.0 0) level 0
tree block backref root CHUNK_TREE
item 1 key (22020096 BLOCK_GROUP_ITEM 8388608) itemoff 16208 itemsize 24
block group used 16384 chunk_objectid 256 flags SYSTEM|DUP
item 2 key (30408704 BLOCK_GROUP_ITEM 1073741824) itemoff 16184 itemsize 24
block group used 425984 chunk_objectid 256 flags METADATA|DUP
item 3 key (30490624 METADATA_ITEM 0) itemoff 16151 itemsize 33_
# À tout hasard...
Posté par ni66 . Évalué à 3.
[^] # Re: À tout hasard...
Posté par jeremyb14 . Évalué à 1.
Hélas déja essayé : mount: /mnt/A-Archives: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error.
[^] # Re: À tout hasard...
Posté par jeremyb14 . Évalué à 2. Dernière modification le 06 juillet 2023 à 14:15.
La commande sudo btrfs check /dev/sdb1
me donne au final :
ERROR: errors found in extent allocation tree or chunk allocation
[3/7] checking free space cache
cache and super generation don't match, space cache will be invalidated
_
_ERROR: errors found in fs roots
found 7979657719808 bytes used, error(s) found
total csum bytes: 7775052220
total tree bytes: 8508260352
total fs tree bytes: 179781632
total extent tree bytes: 425984
btree space waste bytes: 462126238
file data blocks allocated: 8019437592576
referenced 8019437592576
# ça se complique
Posté par jeremyb14 . Évalué à 3.
Je viens d'apprendre que ma sauvegarde en ligne à été corrompue à 55%, c'est 15 ans de travail qui partent à la poubelle
Mon disque de 8 TO est désormais la seule copie intégrale de ce travail d’archivage,
Je vais le garder le temps de trouver comment réparer ce fichus système de fichiers, cela doit bien être possible, c'est sois-disant le FS du futur !
Sinon il me reste plus qu’a acheter un second disque de 8To et de tenter le Brtfs Restore (j’avais commencé à le lancer et ça fonctionne)
[^] # Re: ça se complique
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
Btrfs le système de fichier du futur… on est peut-être un peu trop technophile en l'affirmant. Ça apporte de nouveaux algorithmes, des tas de possibilités d'arrangement encore mieux que zfs, mais ça reste de l'archi-expérimental. Un système de fichier qui vient avec encore des avertissements « peinture fraîche, » il vaut mieux se méfier (affirme le type qui a choisi cette technologie pour ses sauvegardes).
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: ça se complique
Posté par jeremyb14 . Évalué à 4.
oui c'est vrai quoique nouveau nouveau, il existe depuis plus de 10 ans maintenant
Ce qui manque à mon sens c'est une GUI de gestion pour les néophytes (même si Gparted le prends en charge, cela se cantonne à des fonctions basiques)
# Tentative de récup
Posté par jeremyb14 . Évalué à 3.
J'ai lancé un sudo btrfs restore -i /dev/sdb1_ sur mon second disque NTFS de 6To (que je vide au fur et a mesure) pour voir ce que je peux déjà récupérer avec un peu de chance je pourrais compléter ce qui manque avec mon demi-backup en ligne.
je m'attends à 20% de perte , j'ai beaucoup de fichiers qui engendrent cette erreur pendant la restauration : failed: Invalid argument_
Une question mais si les 6TO venaient à étre remplis avant la fin du Restore, est-il possible de continuer sur un autre disque ?
# Récup-suite
Posté par jeremyb14 . Évalué à 1.
La commande sudo btrfs restore -i /dev/sdb1 continue avec succès pour l'instant, déjà 1 TO de récupéré et pas tant de fichiers perdus que ça, actuellement c'est un ratio de 0.1% de perte.
Je remarque que les erreurs proviennent de fichiers avec un long noms et la présence de ? ou ! dans le nom.
ça va prendre 48h au moins pour récupérer les 6TO/8TO, si quelqu’un me lit et connaît une solution pour restaurer les 2TO manquants à la fin sur un autre disque.Je remarque que la commande btrfs restore procède de façon séquentielle et alphabétique, j'ai cherché en vain un moyen de faire une sélection de l'arborescence que l'on veut restaurer.
Par exemple mon disque contient 7 dossiers majeurs A,B,C,D,E,F,G, les dossiers de A à E vont être copiés sur le disque de 6TO et j'aimerais pouvoir par la suite copier seulement F et G sur un autre disque.
Est-ce seulement possible ? j'ai vu que l'on pouvait créer des sous-volumes avec des dossiers et ensuite copier ces mêmes sous-volumes de façon sélective.
Faute de solution je devrais tout recommencer une fois que j'aurais trouvé un autre disque de 8TO
[^] # Re: Récup-suite
Posté par rycks . Évalué à 3.
Ou alors vous déplacez les fichiers restaurés du disque de 6To vers un autre disque … comme ça vous faites de la place au fur et à mesure !
eric.linuxfr@sud-ouest.org
[^] # Re: Récup-suite
Posté par jeremyb14 . Évalué à 1.
oui j'y ai pensé,ce serait une excellente solution mais du coup le Btrfs restore ne vas récrire ce qui à été déplacé ?
je vais essayer je verrais bien, merci !
# Demander au dev
Posté par seb.B . Évalué à 2.
Comme toi il y a une dizaine d'année j'ai eu un soucis sur un disque btrfs. Dans l'attente qu'une solution soit trouvée j'ai fais un dd de ce disque que j'ai gardé précieusement.
Un jour je me suis rendu sur le salon btrfs sur IRC et je suis tombé sur des dev qui m'ont résolu le problème à l'aide de commandes plus obscures les unes que les autres. Les données que j'avais cloné en totalité un an plus tôt ont toutes pu être récupérées sans problème.
A essayer peut-être,le salon IRC semble toujours actif #btrfs…
[^] # Re: Demander au dev
Posté par jeremyb14 . Évalué à 1. Dernière modification le 07 juillet 2023 à 21:46.
Merci ! je vais attendre que le Restore soit terminé ( Pourquoi vous n’avez pas choisi cette solution à l’époque?), je l'ai lancé hier et il est toujours en cours D’âpres les logs je suis en train de récupérer 99,8%, je vais avoir quelques centaines de fichiers perdus mais sur les 550 000 de ma partition c’est acceptable
Par curiosité j’irais voir si le salon IRC existe toujours pour leurs soumettre le lien vers ce post afin qu’ils identifie le problème car même si je repasse sur du NTFS cela m’intéresse en tant que technicien de comprendre et si ils y'en a qui ont les réponses ce sont bien les Devs.
Je fais de l’archivage depuis 15 ans et les 10 premières années j’ai été sur du NTFS, jamais je n’ai eu ma partition bloquée de la sorte, quelques corruptions de fichiers inévitables (suite au Chkdsk) mais rien de grave, par contre ces 5 dernières années de travail sur Brtfs, j’ai eu ce problème une fois par ans et même si j'arrive au final à presque tout récupérer la perte de temps n'est pas acceptable.
Edit ; je viens de ckecker le serveur IRC #Brtfs, personne dedans
Je n'utilise jamais IRC, j'ai pris le premier client que j'ai trouvé : Hexchat
[^] # Re: Demander au dev
Posté par Tonton Th (Mastodon) . Évalué à 2.
Réseau https://libera.chat/ canal #btrfs : 358 users
[^] # Re: Demander au dev
Posté par jeremyb14 . Évalué à 1.
Merci ! J’espère avoir une explication même si je pense que le plantage est du à un trop plein de mon disque, ce qui empêché la réparation , j'envisage de reformater en activant la compression par defaut avec_ -o compress=zstd_ dans etc/fstab
Par contre j'aimerais savoir pourquoi lors de la restauration j'ai des fichiers irrécupérables avec cette sortie : "Invalid argument", je restaure présentement sur un disque NTFS, peut-être une histoire de caractères spéciaux ?
# Récupération 100%-Réponse des devs
Posté par jeremyb14 . Évalué à 3. Dernière modification le 08 juillet 2023 à 15:27.
Bon j'ai repris le btrfs restore depuis le début après avoir formaté mon disque de 6TO en BRTFS au lieu du NTFS, je vais pouvoir récupérer 100% des fichiers car je me suis aperçu que les erreurs de récupération (invalid argurment) que j'avais sur 0.2% de mes données étaient du à des caractères spéciaux dans le nom de fichiers.Je dois donc faire une restauration sur un disque Brtfs car NTFS ne comprends pas les caractères spéciaux.
J'ai eu une réponse d'un dev brtfs :
Question : Cause primaire de l'erreur "parent transid verify failed"
"C'est probablement le pont USB/SATA qui pose problème."
Question : Pourquoi mon second disque NTFS n'est pas impacté alors qu'il est branché dans la même station d'acceuil ?
"Les autres systèmes de fichiers ne repèrent pas toujours les écritures abandonnées - btrfs effectue beaucoup de vérifications de la cohérence interne et détecte les problèmes plus tôt que les autres systèmes de fichiers. (Il est également très bon pour repérer la mauvaise mémoire vive, par exemple)."
Question : Pourquoi la réparation à été impossible ?
"Parce que les outils de réparation ne peuvent pas réparer une défaillance transidirectionnelle."
Voila l'info importante étant que les outils de réparations BRTFS ne peuvent rien face à une erreur de type : parent transid verify failed
-Question : si le disque est trop plein, est-ce que BRTFS peux planter ?
Non
Je pense que ce post est clos, merci à ceux qui auront pris le temps de me répondre.Portez vous bien
[^] # Re: Récupération 100%-Réponse des devs
Posté par mahikeulbody . Évalué à 2.
Du coup, on peut conclure que BTRFS n'est pas en cause ?
Ça collerait plus avec ma propre expérience de ce système de fichiers (plusieurs grappes de disques en RAID1), sans souci depuis plusieurs années.
[^] # Re: Récupération 100%-Réponse des devs
Posté par jeremyb14 . Évalué à 1.
oui ! c'est bien le cable USB qui à causé une erreur fatale
# GUI de gestion BRTFS sous windows !
Posté par jeremyb14 . Évalué à 2.
Petit PS mais je viens d'installer WinBRTFS sous W10 et il y a une GUI de gestion ! C'est un comble quand même en sachant qu'il n'y en a pas sous Linux !
[^] # Re: GUI de gestion BRTFS sous windows !
Posté par Mikis . Évalué à 3.
Il y a : btrfs-assistant (installation à la mano, pas triviale mais accessible en suivant la doc).
Pour ton autre message plus haut, la compression est très efficace mais dépend évidement du type de fichier. Vu que tu as un problème de place, le moindre petit giga récupéré te sera utile de toutes façons.
Les conseilleurs n'étant pas les payeurs : cela vaut peut-être le coût (le coup aussi) d'investir dans un disque plus gros et de passer celui ci en sauvegarde locale. Même si quelque soit la taille du disque, son destin est de devenir trop petit.
[^] # Re: GUI de gestion BRTFS sous windows !
Posté par jeremyb14 . Évalué à 2.
Merci je ne connaissais pas Btrfs Assistant, je vais tester
vous avez raison pour le disque, j'avais prévu de toute façon une fois restauré, de le débrancher et de le ranger bien au chaud
Je vais continuer l'archivage sur le 6To en attendant que le prix des 16 To baisse.
Du coup je garde BRTFS car il est supérieur au NTFS en terme de restauration et de prévention,
le dev avait raison, j'ai vérifié et j'ai perdu des données sur le second disque NTFS à cause du cable USB ( ça c'est pareil terminé la station d'acceuil USB, je repasse sur de l'interne SATA), sauf que contrairement au BRTFS pas de moyen de restaurer les fichiers avec leur noms et l’arborescence (les solutions de recouvrement de fichiers type Recuva, Stellar,R-studio,ect n'inclus pas l'arborescence ni le nom d'origine, ce qui est impraticable quand on à beaucoup de fichiers)
C’est la principale raison pour laquelle je vais rester sur BRTFS, (et petit plus mais il gère les caractères spéciaux dans les noms de fichiers)
J'ai activé la compression avant de lancer btrfs restore, je verrais à la fin la différence.
[^] # Re: GUI de gestion BRTFS sous windows !
Posté par mahikeulbody . Évalué à 3. Dernière modification le 09 juillet 2023 à 07:34.
Sur Manjaro (et sans doute aussi sur Arch), c'est dans les dépôts officiels.
Ca aide mais ça ne prend encore en charge qu'un petit sous-ensemble des commandes BTRFS.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.