Re: Problem with XFS on USB 2TB HD

[Kevin Richter <xfs@pzystorm.de>]

Thanks a lot for your responses.

> I don't have a solution to your problem unfortunately.  Keep in mind you
> posted this problem on a weekend, and one week before Christmas no less.
>  Your timing is not optimal for receiving a prompt response.  It's
> possible you may have to wait until Monday for help. :(

No problem at all. It can wait. My backup drive has indeed no real
important stuff on it - just 100% backups from other disks.
I'd just use this issue as an opportunity to try out the xfs repair
functionality.


>> It is a problem with the interaction of LUKS, XFS and USB?
>
> You are encrypting the external drive? That would explain the
> garbage then - a single bit error in a sector will render it
> completely incorrect....

Yes, I do.
aes-cbc-essiv:sha256
If the connection breaks while writing a block, only this block should
be garbled? This should be 256 bit in this case, shouldn't it?


>> ERROR: The filesystem has valuable metadata changes in a log which
>> > needs to be replayed.
> Given this message, you'll have to run xfs_repair with the zero log
> option ( -L ). This is dangerous, but it can't get much worse anyway.
> 
> Run xfs_repair -L /device , you should be able to mount your filesystem
> afterwards, however any data under change at the time of failure will
> most probably be lost.

OK, if there is no way around...

xfs_repair -L /dev/mapper/backup has run a few minutes and has printed a
lot of screens. After lines like

disconnected inode 4083355215, moving to lost+found
disconnected dir inode 4083355216, moving to lost+found

or

Phase 7 - verify and correct link counts...
resetting inode 128 nlinks from 2 to 3
...
b767c6f0: Badness in key lookup (length)
bp=(bno 0, len 4096 bytes) key=(bno 0, len 512 bytes)
done

it has succeeded in this way, that it is now at least possible to mount
the volume. But there is only the lost+found folder in there which
contains again a lot of folders and files named with numbers. Looking
deeper in these directories all the names of further files or
directories are preserved. Phew! Only the fs structure in the first
level seems to be garbled.

Checking the size of the lost+found folder, (nearly) everything seems to
be there.

Now I am asking myself: If only one 256 bit block is garbled (f. ex.
because of a terminated usb connection) all the directory and file names
in the first level gets garbled? Wicked!



Cheers,
Kevin

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs