khaije rock wrote: > 90% of my way through the recovery and it turns out that each of the > more volume-wide rdump attemps were chocking at the same specific > point: a symlink pointing to a directory on a different filesystem > that then descended back into the ocfs volume. > > Looking like this: > debugfs: stat lossless.from_folks > Inode: 258749 Mode: 0777 Generation: 667446219 (0x27c86bcb) > FS Generation: 781535612 (0x2e95497c) > Type: Symbolic Link Attr: 0x0 Flags: Valid > User: 1000 (khaije) Group: 1000 (khaije) Size: 68 > Links: 1 Clusters: 0 > ctime: 0x49f5b25d -- Mon Apr 27 09:25:49 2009 > atime: 0x49f5b25d -- Mon Apr 27 09:25:49 2009 > mtime: 0x4994683e -- Thu Feb 12 13:19:42 2009 > dtime: 0x0 -- Wed Dec 31 19:00:00 1969 > ctime_nsec: 0x0a0f5a36 -- 168778294 > atime_nsec: 0x00000000 -- 0 > mtime_nsec: 0x00000000 -- 0 > Last Extblk: 0 > Sub Alloc Slot: 0 Sub Alloc Bit: 699 > Fast Symlink Destination: > /home/khaije/documents/shared_multimedia/audio/music/lossy.from_folks > > > I'm guessing this either added enough directories to the path to > exceed rdump's threshold or that it had problems manipulating the > combination of local and non-local filesystems. I would simply delete > it but debugfs.ocfs2 doesn't seem to allow that. (I'm not sure why I > didn't just use a relative path symlink since the target is in the > same directory) > > Anyway by avoiding that symlink I was able to make a full recovery.
(r)dump is not handling fast symlinks correctly. I'll have that fixed. Thanks for debugging. _______________________________________________ Ocfs2-users mailing list Ocfs2-users@oss.oracle.com http://oss.oracle.com/mailman/listinfo/ocfs2-users
