LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This 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


Reply
  Search this Thread
Old 01-20-2014, 11:58 AM   #1
DrBenzo
LQ Newbie
 
Registered: Oct 2007
Posts: 7

Rep: Reputation: 0
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 09:25 AM. Reason: too complicated question
 
Old 01-23-2014, 09:26 AM   #2
DrBenzo
LQ Newbie
 
Registered: Oct 2007
Posts: 7

Original Poster
Rep: Reputation: 0
push
 
Old 01-23-2014, 01:06 PM   #3
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,602

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241
fsck doesn't "zero-fill". Ever.

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.

Last edited by jpollard; 01-23-2014 at 01:08 PM.
 
Old 01-23-2014, 06:00 PM   #4
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 14,833

Rep: Reputation: 1820Reputation: 1820Reputation: 1820Reputation: 1820Reputation: 1820Reputation: 1820Reputation: 1820Reputation: 1820Reputation: 1820Reputation: 1820Reputation: 1820
Quote:
Originally Posted by DrBenzo View Post
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.
 
Old 01-24-2014, 08:19 AM   #5
DrBenzo
LQ Newbie
 
Registered: Oct 2007
Posts: 7

Original Poster
Rep: Reputation: 0
Question

Quote:
Originally Posted by jpollard View Post
fsck doesn't "zero-fill". Ever.

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?
 
Old 01-24-2014, 08:44 AM   #6
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,602

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241
A failing disk can result in lots of things.

Very likely that is what is happening.

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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
ext4 won't mount - fsck required - 2nd fsck in less than a week td3201 Linux - General 1 09-10-2012 01:07 AM
Very slow software RAID5/LVM array - which drive is dying? The Belgain Linux - Software 9 05-16-2011 05:17 AM
Wanted safe way to fsck (mounted) LVM partition minrich Linux - General 5 01-10-2010 07:06 PM
Assistance using fsck to recover ext3 LVM partition fiberfarm Fedora 1 11-01-2006 09:49 PM
Hard drive dying. Need to move Linux partition over. Fear58 Linux - General 3 01-29-2005 06:14 PM


All times are GMT -5. The time now is 10:11 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration