David J N Begley writes:
=> - either the metadata has not been updated, in which case you point to the
=> old file data (as opposed to "random" raw data from any file); or,
=>
=> - the meta data has been updated, and points to the correct new file data
=> (because it was flushed to disk before the metadata).
XFS' journaling is there to protect the _metadata_. It seems a little
harsh to give you back zeroed files after a crash, but the point is
that although your new data may not be as intact as you'd hoped, the
filesystem as a whole _is_ (and no filesystem check is required).
So each change XFS makes to metadata is written to the log before the
coresponding change is made in the filesystem. When each transaction
(which may affect several blocks of metadata) is completed, the log
entry is done with.
If the machine dies part way though a transaction, the log is used to
complete the transaction so that the filesystem is consistent.
XFS will never (1) give you back the old crud left on disk - that would
be a secuity hole. So whenever you're reading something that you
haven't written, you'll get zeroes.
If the file has been extended & not yet written, you'll get zeroes. If
blocks have been allocated and not filled, you'll get zeroes. The
metadata change is preserved, but unfortunately not the data - that's
just the way it works.
You could go look through your old data for things you'd lost, but
XFS doesn't go out of its way to make that easy (2).
Hope that explains it. I think people shy away from answering this as
it really has been done to death. I hope there's something decent in
the FAQ. If not, maybe someone could propose wording for a new entry?
If you want _really_ accurate info, I'm sorry to say the best approach
is to go read the code (serious guru stuff down there though).
----
(1) IIRC, unwritten extents can violate this, but there's a restriction
on that so root needs to allow that behaviour.
(2) there's no xfs_undelete - that's what backups are for
-------------------------------------------------------
Daniel Moore dxm@xxxxxxx 5248209
R&D Software Engineer Phone: +61-3-98348209
SGI Australian Software Group Fax: +61-3-98132378
-------------------------------------------------------
|