Luckily the files that I want to recover have metadata in them that will help me rebuild their names. So I'm okay with blowing away the directory inodes. I guess I wish there was a flag that I can pass to say that xfs_repair can junk those for me instead of having to do it manually each time.
So, the compressed metadump file is 2.4G. Any suggestions on where I should put it, and who I send it to?
On Tue, Oct 8, 2013 at 1:23 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
On Mon, Oct 07, 2013 at 01:09:09PM -0700, Viet Nguyen wrote:Right, that's blocks that are being detected as corrupt when they
> Thanks. That seemed to fix that bug.
>
> Now I'm getting a lot of this:
> xfs_da_do_buf(2): XFS_CORRUPTION_ERROR
are read. You can ignore that for now.
That's a corrupted block list of some kind - it should junk the
> fatal error -- can't read block 8388608 for directory inode 8628218
inode.
> Then xfs_repair exits.
I'm not sure why that happens. Is it exiting cleanly or crashing?
Can you take a metadump of the filesystem and provide it for someone
to debug the problems it causes repair?
That marks the inode as "free" which effectively junks it and then
> What I've been doing is what I saw in the FAQ where I would use xfs_db and
> write core.mode 0 for these inodes. But there are just so many of them. And
> is that even the right thing to do?
xfs_repair will free all it's extents next time it is run. Basically
you are removing the files from the filesystem and making them
unrecoverable.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
