xfs_repair 3.1.1 doesnt repair broken filesystem [solved]

[Michael Monnerie]

On Dienstag, 18. Mai 2010 Default User wrote:
> I think you have created the filesystem with -o inode64 and now you
>  are  remounting it without -o inode64.
> After you created one file or directory with the inode64 option you
>  NEED  to always specify inode64 option at subsequent mounts or you
>  won't be able to access such files/directories.
> (Not sure if forgetting to use the option can even cause data
>  corruption  upon write. Might inode32 writes overwrite the
>  inaccessible inode64 files/dirs? XFS developers might know this.)
 
Ah! You're absolutely right, inode64 did the trick.

Isn't it a kind of bug? Of course normally you would mount filesystems 
from fstab, but for a temporary one like this I didn't do that. Still, 
having xfs issuing not even a warning smells like a bug, even if they 
might say it's a "feature by design".

So if you have an external 2TB drive from a friend and mount it on your 
PC, you can't tell if inode64 was used or not? And if you mount without 
that option you could destroy contents? In my case it was "easy" to see 
there are fs problems, but what if such inodes are only used in subdirs? 
Even with this "easy seeable" problem I didn't have the idea of a 
missing inode64 option.

-- 
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services
http://proteger.at [gesprochen: Prot-e-schee]
Tel: 0660 / 415 65 31

// Wir haben im Moment zwei Häuser zu verkaufen:
// http://zmi.at/langegg/
// http://zmi.at/haus2009/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20100518/6f08d599/attachment.sig>