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@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
