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?
It seems to be exiting cleanly with return code 1. I created a metadump, but it's 9.6GB. I suppose I can put up on a secure FTP or something like that, but it does seem a big large to shuffle around.
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.
In the case of directories, it blows away just directory but xfs_repair later on scans for orphan files, no? Or am I mistaken on how that works.
Thanks,
Viet
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
