| View previous topic :: View next topic |
| Author |
Message |
gammanu
n00b
Joined: 15 Mar 2006
Posts: 6
|
 Posted: Fri Jan 08, 2010 4:57 am Post subject: [ext4] partition corrompu irrécupérable ??? |
 |
|
Bonjour,
Cela fait maintenant environ une semaine que j'essaie de monter une de mes partition qui s'est corrompu lors d'une coupure de courant.
Pour commencer, ma configuration :
J'ai un serveur sous gentoo linux (linux-2.6.28-hardened-r9)
avec une carte raid (areca ARC-1261ML) et 16 disque d'1,5To branché dessus en raid6 materiel.
la partition incriminé est en ext4.
Elle est mise directement à la racine d'un disque virtuel du raid vu par linux comme /dev/sdb
Elle fait 7,5 To et contient entre 3 et 4To de donnée actuellement
Je n'utilise pas LVM ni LVM2
J'ai des données importante dessus dont je n'ai aucune sauvegarde récentes.
Maintenant passons au différente commandes que j'ai essayer pour réparer tout ça et les messages d'erreurs correspondants.
Avant toutes choses, j'ai fait une vérification du coté de l'interface dédié de la carte raid (Check Volume Set) qui n'a donné aucune erreur
par contre e2fsck lui à trouvé des erreur en pagaille et j'ai fait l'erreur (je pense) de le laisser "corriger" ce qu'il a trouvé avant toute sauvegarde (7.5To ça ne se sauvegarde pas facilement...)
quelques détail sur mon système (4U est le nom de ma machine)
| Code: |
4U ~ # blkid
/dev/sdb: LABEL="infiniTera" UUID="c1ab56e5-6255-46af-b22f-0bfdb0f2cefe" TYPE="ext4"
/dev/sdc1: LABEL="SSD" UUID="68b0fc49-7b03-4158-bc1e-f548a4f7d390" TYPE="ext4"
|
la partition SSD ou /dev/sdc1 est ma partition système qui ne c'est pas corrompu lors de la coupure de courant.
la partition infiniTera ou /dev/sdb est celle qui pause problème. elle est normalement monté dans /terabay
| Code: |
4U ~ # cat /etc/fstab
LABEL=SSD / ext4 noatime,nodiratime,async,commit=100 0 1
LABEL=infiniTera /terabay ext4 noatime 0 1
shm /dev/shm tmpfs nodev,nosuid,noexec 0 0
/dev/shm /tmp tmpfs defaults,nosuid,nodev,noexec 0 0
none /var/tmp/portage tmpfs uid=250,gid=250,mode=775 0 0
none /chroot/dns/proc proc defaults 0 0
|
(pas de swap, mon système à toujours tourné comme ça, avec ses 4Go de ram)
| Code: |
4U ~ # dumpe2fs /dev/sdb
dumpe2fs 1.41.9 (22-Aug-2009)
Filesystem volume name: infiniTera
Last mounted on: <not available>
Filesystem UUID: c1ab56e5-6255-46af-b22f-0bfdb0f2cefe
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: not clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 457768960
Block count: 1831054400
Reserved block count: 18310544
Free blocks: 761412113
Free inodes: 455340703
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 587
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
RAID stripe width: 224
Flex block group size: 16
Filesystem created: Thu Oct 29 03:16:52 2009
Last mount time: Thu Dec 17 03:22:25 2009
Last write time: Fri Jan 8 05:43:08 2010
Mount count: 31
Maximum mount count: 34
Last checked: Thu Oct 29 03:16:52 2009
Check interval: 15552000 (6 months)
Next check after: Tue Apr 27 04:16:52 2010
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Default directory hash: half_md4
Directory Hash Seed: b6f1ca05-006b-4ce6-bbd1-993b6a8c6d26
Journal backup: inode blocks
ext2fs_read_bb_inode: A block group is missing an inode table
Group 0: (Blocks 0-32767)
Checksum 0x0000, unused inodes 0
Primary superblock at 0, Group descriptors at 1-437
Reserved GDT blocks at 438-1024
Block bitmap at 0 (+0), Inode bitmap at 0 (+0)
Inode table at 0-511
0 free blocks, 0 free inodes, 0 directories
Group 1: (Blocks 32768-65535)
Checksum 0x0000, unused inodes 0
Backup superblock at 32768, Group descriptors at 32769-33205
Reserved GDT blocks at 33206-33792
Block bitmap at 0 (+4294934528), Inode bitmap at 0 (+4294934528)
Inode table at 0-511 (+4294934528)
0 free blocks, 0 free inodes, 0 directories
Group 2: (Blocks 65536-98303)
Checksum 0x0000, unused inodes 0
Block bitmap at 0 (+4294901760), Inode bitmap at 0 (+4294901760)
Inode table at 0-511 (+4294901760)
0 free blocks, 0 free inodes, 0 directories
[...]
Group 21: (Blocks 688128-720895)
Checksum 0x0000, unused inodes 0
Block bitmap at 0 (+4294279168), Inode bitmap at 0 (+4294279168)
Inode table at 0-511 (+4294279168)
0 free blocks, 0 free inodes, 0 directories
Group 22: (Blocks 720896-753663) [INODE_UNINIT, ITABLE_ZEROED]
Checksum 0x0000, unused inodes 0
Block bitmap at 524294 (+4294770694), Inode bitmap at 524310 (+4294770710)
Inode table at 527392-527903 (+4294773792)
0 free blocks, 8192 free inodes, 0 directories
[...]
Group 17341: (Blocks 568229888-568262655) [ITABLE_ZEROED]
Checksum 0xf67e, unused inodes 8188
Block bitmap at 567803917 (+4294541325), Inode bitmap at 567803933 (+4294541341)
Inode table at 567810592-567811103 (+4294548000)
4063 free blocks, 8192 free inodes, 0 directories, 8188 unused inodes
[...]
Group 55875: (Blocks 1830912000-1830944767) [INODE_UNINIT]
Checksum 0xa6a7, unused inodes 16084
Block bitmap at 1653050381 (+4117105677), Inode bitmap at 1861586816 (+30674816)
Inode table at 1653050414-1653050925 (+4117105710)
33450 free blocks, 54762 free inodes, 33708 directories, 16084 unused inodes
Group 55876: (Blocks 1830944768-1830977535) [BLOCK_UNINIT, ITABLE_ZEROED]
Checksum 0xed25, unused inodes 12170
Block bitmap at 1516733388 (+3980755916), Inode bitmap at 2720696919 (+889752151)
Inode table at 1653046122-1653046633 (+4117068650)
61325 free blocks, 30846 free inodes, 31594 directories, 12170 unused inodes
Group 55877: (Blocks 1830977536-1831010303) [INODE_UNINIT, ITABLE_ZEROED]
Checksum 0x01e1, unused inodes 59733
Block bitmap at 1378253674 (+3842243434), Inode bitmap at 623567103 (+3087556863)
Inode table at 1376086793-1376087304 (+3840076553)
46895 free blocks, 24688 free inodes, 31627 directories, 59733 unused inodes
Group 55878: (Blocks 1831010304-1831043071) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
Checksum 0xc060, unused inodes 32768
Block bitmap at 2209131859 (+378121555), Inode bitmap at 2106286331 (+275276027)
Inode table at 1653050381-1653050892 (+4117007373)
49000 free blocks, 55518 free inodes, 37999 directories, 32768 unused inodes
Group 55879: (Blocks 1831043072-1831054399) [BLOCK_UNINIT]
Checksum 0x0203, unused inodes 36271
Block bitmap at 1514574959 (+3978499183), Inode bitmap at 2144689752 (+313646680)
Inode table at 1376088809-1376089320 (+3840013033)
65333 free blocks, 60330 free inodes, 35788 directories, 36271 unused inodes
dumpe2fs: /dev/sdb: error reading bitmaps: Can't read an inode bitmap
|
j'ai le dump complet si vous voulez mais je doute qu'avec 17Mo de dump cela apporte plus.
En prenant un superblock de rechange ( j'ai testé avec d'autre plus petit j'obtiens la même chose :
| Code: |
4U ~ # dumpe2fs -o superblock=512000000 /dev/sdb
dumpe2fs 1.41.9 (22-Aug-2009)
Filesystem volume name: infiniTera
Last mounted on: <not available>
Filesystem UUID: c1ab56e5-6255-46af-b22f-0bfdb0f2cefe
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: not clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 457768960
Block count: 1831054400
Reserved block count: 18310544
Free blocks: 761412113
Free inodes: 455340703
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 587
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
RAID stripe width: 224
Flex block group size: 16
Filesystem created: Thu Oct 29 03:16:52 2009
Last mount time: Thu Dec 17 03:22:25 2009
Last write time: Tue Dec 29 17:31:59 2009
Mount count: 31
Maximum mount count: 34
Last checked: Thu Oct 29 03:16:52 2009
Check interval: 15552000 (6 months)
Next check after: Tue Apr 27 04:16:52 2010
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Default directory hash: half_md4
Directory Hash Seed: b6f1ca05-006b-4ce6-bbd1-993b6a8c6d26
Journal backup: inode blocks
[...]
Group 55876: (Blocks 1830944768-1830977535) [ITABLE_ZEROED]
Checksum 0xed25, unused inodes 0
Block bitmap at 1516733388 (+3980755916), Inode bitmap at 2720696919 (+889752151)
Inode table at 1653046122-1653046633 (+4117068650)
61325 free blocks, 30846 free inodes, 31594 directories
Group 55877: (Blocks 1830977536-1831010303) [ITABLE_ZEROED]
Checksum 0x01e1, unused inodes 0
Block bitmap at 1378253674 (+3842243434), Inode bitmap at 623567103 (+3087556863)
Inode table at 1376086793-1376087304 (+3840076553)
46895 free blocks, 24688 free inodes, 31627 directories
Group 55878: (Blocks 1831010304-1831043071) [ITABLE_ZEROED]
Checksum 0xc060, unused inodes 0
Block bitmap at 2209131859 (+378121555), Inode bitmap at 2106286331 (+275276027)
Inode table at 1653050381-1653050892 (+4117007373)
49000 free blocks, 55518 free inodes, 37999 directories
Group 55879: (Blocks 1831043072-1831054399)
Checksum 0x0203, unused inodes 0
Block bitmap at 1514574959 (+3978499183), Inode bitmap at 2144689752 (+313646680)
Inode table at 1376088809-1376089320 (+3840013033)
65333 free blocks, 60330 free inodes, 35788 directories
dumpe2fs: /dev/sdb: error reading bitmaps: Can't read an inode bitmap
|
j'aurais peutêtre du commencé par ça mais :
| Code: |
4U ~ # mount /terabay/
mount: wrong fs type, bad option, bad superblock on /dev/sdb,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
4U ~ # mount /dev/sdb /terabay/
mount: wrong fs type, bad option, bad superblock on /dev/sdb,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
4U ~ # mount -t ext4 /dev/sdb /terabay/
mount: wrong fs type, bad option, bad superblock on /dev/sdb,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
|
| Code: |
4U ~ # dmesg | tail
[ 22.555143] sky2 eth0: Link is up at 1000 Mbps, full duplex, flow control both
[ 32.755460] warning: `named' uses 32-bit capabilities (legacy support in use)
[ 40.531555] grsec: mount of /lib64/splash/cache to /lib64/splash/tmp by /bin/mount[mount:6883] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:4917] uid/euid:0/0 gid/egid:0/0
[ 40.544451] grsec: unmount of cachedir by /bin/umount[umount:6889] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:4917] uid/euid:0/0 gid/egid:0/0
[ 4113.956172] EXT4-fs: ext4_check_descriptors: Checksum for group 0 failed (61599!=0)
[ 4113.956175] EXT4-fs: group descriptors corrupted!
[ 4125.212514] EXT4-fs: ext4_check_descriptors: Checksum for group 0 failed (61599!=0)
[ 4125.212517] EXT4-fs: group descriptors corrupted!
[ 4133.558272] EXT4-fs: ext4_check_descriptors: Checksum for group 0 failed (61599!=0)
[ 4133.558275] EXT4-fs: group descriptors corrupted!
|
dans d'autre cas (console de récupération root et non boot terminé je crois (mais sans garantie)
dmesg | tail me donnait :
| Code: | | [ Un nombre] VFS: Can't find ext4 filesystem on dev sdb |
| Code: |
4U ~ # fsck.ext4 /dev/sdb
e2fsck 1.41.9 (22-Aug-2009)
fsck.ext4: Group descriptors look bad... trying backup blocks...
fsck.ext4: Bad magic number in super-block when using the backup blocks
fsck.ext4: going back to original superblock
fsck.ext4: Device or resource busy while trying to open /dev/sdb
Filesystem mounted or opened exclusively by another program?
|
| Code: |
4U ~ # fuser -v -m /dev/sdb
4U ~ #
|
pourtant fuser me rend la main sans rien trouver.
| Code: |
4U ~ # e2fsck -f -y -b 98304 /dev/sdb
e2fsck 1.41.9 (22-Aug-2009)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
|
Cette commande à pourtant marché pendant 2jours mais maintenant le super bloc de secours n'est plus valide visiblement
avec un autre superblock :
| Code: |
4U ~ # e2fsck -f -y -b 294912 /dev/sdb
e2fsck 1.41.9 (22-Aug-2009)
One or more block group descriptor checksums are invalid. Fix? yes
Group descriptor 0 checksum is invalid. FIXED.
Group descriptor 1 checksum is invalid. FIXED.
Group descriptor 2 checksum is invalid. FIXED.
Group descriptor 3 checksum is invalid. FIXED.
[...]
Group descriptor 40319 checksum is invalid. FIXED.
Group descriptor 40320 checksum is invalid. FIXED.
Inode bitmap for group 40321 is not in group. (block 3942577393)
Relocate? yes
Group descriptor 40321 checksum is invalid. FIXED.
Group descriptor 40322 checksum is invalid. FIXED.
Inode bitmap for group 40323 is not in group. (block 4119855093)
Relocate? yes
Group descriptor 40323 checksum is invalid. FIXED.
Group descriptor 40324 checksum is invalid. FIXED.
Inode bitmap for group 40325 is not in group. (block 2952572409)
Relocate? yes
Group descriptor 40325 checksum is invalid. FIXED.
Inode bitmap for group 40326 is not in group. (block 3059245545)
Relocate? yes
[...]
Group descriptor 40688 checksum is invalid. FIXED.
Block bitmap for group 40689 is not in group. (block 2217561867)
Relocate? yes
Inode bitmap for group 40689 is not in group. (block 2240637522)
Relocate? yes
Inode table for group 40689 is not in group. (block 2208269439)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate? yes
Group descriptor 40689 checksum is invalid. FIXED.
Block bitmap for group 40690 is not in group. (block 2160945937)
Relocate? yes
Inode bitmap for group 40690 is not in group. (block 3277948633)
Relocate? yes
Inode table for group 40690 is not in group. (block 2208269407)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate? yes
Group descriptor 40690 checksum is invalid. FIXED.
Inode bitmap for group 40691 is not in group. (block 3681400391)
Relocate? yes
[...]
Group descriptor 55876 checksum is invalid. FIXED.
Group descriptor 55877 checksum is invalid. FIXED.
Block bitmap for group 55878 is not in group. (block 2209131859)
Relocate? yes
Inode bitmap for group 55878 is not in group. (block 2106286331)
Relocate? yes
Group descriptor 55878 checksum is invalid. FIXED.
Inode bitmap for group 55879 is not in group. (block 2144689752)
Relocate? yes
Group descriptor 55879 checksum is invalid. FIXED.
Resize inode not valid. Recreate? yes
Pass 1: Checking inodes, blocks, and sizes
^CGroup 40334's inode table at 568738732 conflicts with some other fs block.
Relocate? yes
Group 40335's block bitmap at 572930793 conflicts with some other fs block.
Relocate? yes
Group 40336's block bitmap at 428098378 conflicts with some other fs block.
Relocate? yes
Group 40353's inode table at 696675278 conflicts with some other fs block.
Relocate? yes
Group 40366's inode table at 566578028 conflicts with some other fs block.
Relocate? yes
Group 40386's block bitmap at 426003275 conflicts with some other fs block.
Relocate? yes
Group 40389's inode table at 705121131 conflicts with some other fs block.
Relocate? yes
[...]
Group 55878's inode table at 1653050381 conflicts with some other fs block.
Relocate? yes
Group 55879's inode table at 1376088809 conflicts with some other fs block.
Relocate? yes
Group 55879's block bitmap at 1514574959 conflicts with some other fs block.
Relocate? yes
infiniTera: e2fsck canceled.
infiniTera: ***** FILE SYSTEM WAS MODIFIED *****
infiniTera: ********** WARNING: Filesystem still has errors **********
e2fsck: Inode bitmap not loaded while setting block group checksum info
4U ~ #
|
(j'ai en effet annulé sinon, ça moulinerait encore et toujours)
Globalement j'ai essayé tout ce qui se trouve là :
http://forum.ubuntu-fr.org/viewtopic.php?id=263050
et là :
http://markmail.org/message/3w5tbyaiho7os4fr#query:ext4%20recover+page:1+mid:3w5tbyaiho7os4fr+state:results
sans succès.
J'ai aussi essayer d'utiliser testDisk 6.11-r1 (qui gère l'ext4 depuis cette version)
le soft vois ma partition mais je n'arrive pas à lui faire la réparer ou accéder à des fichiers ou quoi que ce soit du genre...
voici le dump TestDisk :
| Code: |
4U ~ # cat testdisk.log
Fri Jan 8 06:37:02 2010
Command line: TestDisk
TestDisk 6.11, Data Recovery Utility, April 2009
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
OS: Linux, kernel 2.6.28-hardened-r9 (#22 SMP Tue Oct 27 04:44:48 CET 2009)
Compiler: GCC 4.3 - Jan 8 2010 04:50:30
ext2fs lib: 1.41.9, ntfs lib: 10:0:0, reiserfs lib: 0.3.1-rc8, ewf lib: none
/dev/sdc: LBA, HPA, LBA48, DCO support
/dev/sdc: size 62533296 sectors
/dev/sdc: user_max 62533296 sectors
/dev/sdc: native_max 62533296 sectors
/dev/sdc: dco 62533296 sectors
Warning: can't get size for Disk /dev/mapper/control - 0 B - CHS 1 1 1, sector size=512
Hard disk list
Disk /dev/sda - 4999 GB / 4656 GiB - CHS 75985 255 63, sector size=4096 - Areca nextgen
Disk /dev/sdb - 7499 GB / 6984 GiB - CHS 911822 255 63, sector size=512 - Areca InfiniTera
Disk /dev/sdc - 32 GB / 29 GiB - CHS 3892 255 63, sector size=512 - ATA OCZ-VERTEX
Partition table type (auto): None
Disk /dev/sdb - 7499 GB / 6984 GiB - Areca InfiniTera
Partition table type: None
Analyse Disk /dev/sdb - 7499 GB / 6984 GiB - CHS 911822 255 63
recover_EXT2: s_block_group_nr=0/55879, s_mnt_count=31/34, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 1831054400
recover_EXT2: part_size 14648435200
Current partition structure:
P ext4 0 0 1 911822 234 28 14648435200 [infiniTera]
search_part()
Disk /dev/sdb - 7499 GB / 6984 GiB - CHS 911822 255 63
recover_EXT2: s_block_group_nr=0/55879, s_mnt_count=31/34, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 1831054400
recover_EXT2: part_size 14648435200
ext4 0 0 1 911822 234 28 14648435200 [infiniTera]
EXT4 Large file Sparse superblock, 7499 GB / 6984 GiB
Search for partition aborted
Results
P ext4 0 0 1 911822 234 28 14648435200 [infiniTera]
EXT4 Large file Sparse superblock, 7499 GB / 6984 GiB
dir_partition inode=2
P ext4 0 0 1 911822 234 28 14648435200 [infiniTera]
EXT4 Large file Sparse superblock, 7499 GB / 6984 GiB
ext2fs_dir_iterate failed with error 2133571387.
Directory /
interface_write()
P ext4 0 0 1 911822 234 28 14648435200 [infiniTera]
Write isn't available because the partition table type "None" has been selected.
Interface Advanced
recover_EXT2: s_block_group_nr=0/55879, s_mnt_count=31/34, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 1831054400
recover_EXT2: part_size 14648435200
P ext4 0 0 1 911822 234 28 14648435200 [infiniTera]
EXT4 Large file Sparse superblock, 7499 GB / 6984 GiB
search_superblock
recover_EXT2: s_block_group_nr=0/55879, s_mnt_count=31/34, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 1831054400
recover_EXT2: part_size 14648435200
Ext2 superblock found at sector 2 (block=0, blocksize=4096)
block_group_nr 9
recover_EXT2: "e2fsck -b 294912 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=9/55879, s_mnt_count=31/34, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 1831054400
recover_EXT2: part_size 14648435200
Ext2 superblock found at sector 2359296 (block=294912, blocksize=4096)
block_group_nr 25
recover_EXT2: "e2fsck -b 819200 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=25/55879, s_mnt_count=31/34, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 1831054400
recover_EXT2: part_size 14648435200
Ext2 superblock found at sector 6553600 (block=819200, blocksize=4096)
[...]
block_group_nr 729
recover_EXT2: "e2fsck -b 23887872 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=729/55879, s_mnt_count=31/34, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 1831054400
recover_EXT2: part_size 14648435200
Ext2 superblock found at sector 191102976 (block=23887872, blocksize=4096)
ext4 0 0 1 911822 234 28 14648435200 [infiniTera]
superblock 0, blocksize=4096 [infiniTera]
superblock 294912, blocksize=4096 [infiniTera]
superblock 819200, blocksize=4096 [infiniTera]
superblock 884736, blocksize=4096 [infiniTera]
superblock 1605632, blocksize=4096 [infiniTera]
superblock 2654208, blocksize=4096 [infiniTera]
superblock 7962624, blocksize=4096 [infiniTera]
superblock 11239424, blocksize=4096 [infiniTera]
superblock 20480000, blocksize=4096 [infiniTera]
superblock 23887872, blocksize=4096 [infiniTera]
TestDisk exited normally.
|
Je suis à court d'idée... si vous avez des solution permettant idéalement de réparer ma partition, ce serais idéal, sinon à défaut d'accéder a mes fichier
si possible avec nom... et arborescence.
PS : peu de temps avant la coupure j'avais copié 900Go de données, celles si ne sont pas importante, je peux les récupéré par ailleur. Donc si les données corrompu sont seullement les dernière écrite, ce n'est pas génant.
Tous mes espoirs sont suspendu à vos lèvres (ou a vos doigts sur le clavier) je vous laisse maintenant la parole. |
|
| Back to top |
|
 |
El_Goretto
Moderator
Joined: 29 May 2004
Posts: 3174
Location: Paris
|
| Posted: Fri Jan 08, 2010 11:24 am Post subject: |
|
|
Alors non, je n'ai pas d'aide précise à t'apporter, par contre il faut ABSOLUMENT que tu suives un minimum les changelog et les forums...
Parce que les débuts de ext4 ont été tumultueux, et ça a été notoire que des corruptions de données se sont produites sur les séries pre 2.6.29.
Perso, pour avoir un petit hardened aussi, sachant que j'ai aussi la machine en ext4, après ma première frayeur, j'ai bien suivi les évolution du kernel vanilla, quitte à passer par un noyau fait main grsec comme on en a parlé >>>ici<<<.
Et je me disais bien qu'un fou furieux avec des données sur des partitions de tailles monstrueuses avec un FS tout récent sur des noyaux buggés, j'avais déjà vu çà quelque part.... ben j'ai retrouvé où.
Ca fait mal au luc pour toi, mais bor...el, tu peux pas dire que t'étais pas prévenu 
_________________
-TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT) |
|
| Back to top |
|
|
razer
l33t
Joined: 08 Oct 2004
Posts: 893
Location: Paris - France
|
| Posted: Fri Jan 08, 2010 5:40 pm Post subject: Re: [ext4] partition corrompu irrécupérable ??? |
|
|
| gammanu wrote: | ...
16 disque d'1,5To branché dessus en raid6 materiel.
...
J'ai des données importante dessus dont je n'ai aucune sauvegarde récentes.
...
|
Je sais pas vraiment l'origine de ton problème, mais à quoi sert donc du RAID6 si on ne peut pas récupérer des données  |
|
| Back to top |
|
|
El_Goretto
Moderator
Joined: 29 May 2004
Posts: 3174
Location: Paris
|
| Posted: Fri Jan 08, 2010 6:29 pm Post subject: |
|
|
@razer: go RTFM sur le RAID et sur la notion de FS 
RAID c'est la couche "physique+", au dessus ya le FS et encore au dessus, les données. Au dessous, les disques.
Le RAID n'a JAMAIS dispensé de faire un backup des données, il est seulement là pour permettre une tolérance aux pannes de disques.
_________________
-TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT) |
|
| Back to top |
|
|
razer
l33t
Joined: 08 Oct 2004
Posts: 893
Location: Paris - France
|
| Posted: Sat Jan 09, 2010 8:26 am Post subject: |
|
|
| El_Goretto wrote: | | RTFM sur le RAID |
Arf
Même pas besoin de manuel pour réaliser que mon cerveau a raisonné à l'envers sur ce coup  |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
French
