[Ocfs2-users] Fwd: fsck fails & volume mount fails, is my data lost?

[Sunil Mushran]

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.