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
|