fsck.ext4 zero-filled Files on a lvm-partition because of dying drive
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
fsck.ext4 zero-filled Files on a lvm-partition because of dying drive
Hello,
I did a fsck.ext4 on a unmountet filesystem:
Code:
fsck -yv /dev/data/GrandCentralStation
After this the files had the right size, names and even the right rights and ownerships!
The only problem is, that those files have all been zero-filled by fsck, so they are now useless...
I checked many files with a Hex-Editor and every larger file has only zeros as "data".
So my question is now: Is there some way to "undo" the fsck?
Can i repair the fs by using the journal and backup-superblock (iīm not sure how to this correct right now, either by using fsck options i didnīt read yet, or by using file-carvers like ext4magic, testdisk/photorec, scalpel).
Best Regards
DrBenzo
Last edited by DrBenzo; 01-23-2014 at 08:25 AM.
Reason: too complicated question
What it does is repair pointers to damaged blocks.
What very likely happened is that the damaged blocks could not be read to be relocated by the drive - but fsck forced the pointers to blocks, which were likely already zero filled.
Alternatively (and it depends on the filesystem and driver) fsck didn't zero fill, but left holes in the file for the damaged blocks. Such holes are always filled with null pages in memory when read.
Exactly which scenario occurred can be identified by a file system debugger. Holes in file (also referred to as "sparse file allocations") will be identified by missing metadata pointers. The file size information is stored in the inode, but bad blocks removed by the driver will not be identified.
But there is little chance of recovery from a failing disk.
So my question is now: Is there some way to "undo" the fsck?
Can i repair the fs by using the journal and backup-superblock (iīm not sure how to this correct right now, either by using fsck options i didnīt read yet, or by using file-carvers like ext4magic, testdisk/photorec, scalpel).
Nope.
The journal has already been run, and all the superblocks would have been "cleaned". I've never seen what you describe, but I agree with @jpollard that sparse files looks a good bet - would explain the apparent zero data.
Some of the forensics tools might help, but they are slooooooow, and can (do) result in partial files in extreme situations. fsck is designed to recover the integrity of the filesystem itself - backups are for data.
What it does is repair pointers to damaged blocks.
What very likely happened is that the damaged blocks could not be read to be relocated by the drive - but fsck forced the pointers to blocks, which were likely already zero filled.
Alternatively (and it depends on the filesystem and driver) fsck didn't zero fill, but left holes in the file for the damaged blocks. Such holes are always filled with null pages in memory when read.
Exactly which scenario occurred can be identified by a file system debugger. Holes in file (also referred to as "sparse file allocations") will be identified by missing metadata pointers. The file size information is stored in the inode, but bad blocks removed by the driver will not be identified.
But there is little chance of recovery from a failing disk.
Thanks for reply!
There are not only holes in the files, the files are one big "black hole" whithout any data left. Before i ran fsck i could read many of the files without problems. After the fsck run there where ~1TB of empty files, can this be done with what you described?
If you have a head crash, you tend to only have one chance at retrieving data - That is because of damage to the read head causing damage to the disk as it reads... Thus a second read gets nothing.
I was able to recover data ONCE in such a situation - I copied the disk, but in the process scraped off nearly all the oxide from the disk being read. This was a LONG time ago when "removable packs" were cheaper than a whole drive, and drives were the size of washing machines.
My last attempt was a 2TB disk starting to go bad... Didn't get much at all.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.