also sprach Andi Kleen <ak@xxxxxx> [2005.02.11.1429 +0100]:
> I've read explanations similar to mine several time on the
> list and also given them occasionally myself.
Again, not to be read as a personal attack, but your explanation is
not what I was looking for. It added very little to the description
I included in the first post.
> You could in theory by grepping the block device and searching for
> the data (it hasn't been physically destroyed unless there is
> parallel activity on the fs). But the XFS code can't find it
> anymore because the metadata connecting the inode to the file data
> is gone. That is why you see the 0s instead.
Right. So basically you are saying that it's not possible to get at
the data anymore other than through direct device access.
Maybe this is something that could be considered for future XFS
versions? A tool that can ignore the zeroing-precaution and simply
give access to the data the inode points to, even though it would
not normally connect the two.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@xxxxxxxxxxx
"our destiny exercises its influence over us even when, as yet,
we have not learned its nature; it is our future that lays down the
law of our today."
- friedrich nietzsche
signature.asc
Description: Digital signature
|