Re: currupted files filling with zeros after power failure

[Martin Steigerwald <Martin@lichtvoll.de>]

Am Montag 24 Juli 2006 18:03 schrieb Pascal GREGIS:

[ files with zero at the end after switching off the computer abruptly)

> I didn't think XFS could be subject to this type of problem, however
> here isn't really the reason of my mail.

Hello Pascal,

it is. Cause it does not do data journaling and it doesn't ensure that the 
data that belongs to a metadata change (i.e. enlarge a file) makes it to 
the disk before the metadate change. Read about "Journaling options and 
write latency" in

http://www-128.ibm.com/developerworks/library/l-fs8.html

to find out more about this. XFS behaves like ext3 with "data=writeback". 

This is the fastest mode of operation. "data=ordered" => writing data 
before metadata is slightly slower and "data=journal" => data journalling 
is twice as slow. AFAIK only Reiser4 (and the commercial WAFL) can do 
fast data journaling by use of its wandering logs feature:

http://en.wikipedia.org/wiki/Wandering_log

> What I would like to know is what can I do to resolve this problem? Is
> XFS able to recover my file with its right content, at least a
> consistent content, not only \0 characters? I made some tries with
> xfs_repair and it didn't repair it, once it put me some inodes in
> lost+found but id didn't repair my corrupted file. Maybe xfs_db could
> help, I don't know.

I think you can't fix it without changing XFS to support either data 
journaling or writing data before metadata.

BTW seen from the metadata side the files are not corrupted. The 
filesystem structure is still fine. Any application that relies on the 
integrity of the file contents will have a problem tough. Its a speed 
versus data safety issue unless you use some kind of wandering logs or a 
another approach which doesn't require writing data twice.

Still with data journaling you may get a certain granularity depending on 
its implementation, maybe a 4K (page granularity) write (data + metadata) 
made it through, while some more writes where missing. Ideally either a 
write *as issued* by the application will make it through completely or 
not at all.

An additional approach is having some sort of data journaling in the 
application which should know best about the integrity of its own data. 
Many databases and servers take some precautions to ensure data integrity 
in case of a crash.

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7