public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Monnerie <michael.monnerie@is.it-management.at>
To: xfs@oss.sgi.com
Subject: Re: xfs_repair 3.1.1 doesnt repair broken filesystem [solved]
Date: Tue, 18 May 2010 13:42:13 +0200	[thread overview]
Message-ID: <201005181342.17267@zmi.at> (raw)
In-Reply-To: <4BF2739B.6000509@email.it>


[-- Attachment #1.1: Type: Text/Plain, Size: 1534 bytes --]

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/

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

      reply	other threads:[~2010-05-18 11:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-18  7:53 xfs_repair 3.1.1 doesnt repair broken filesystem Michael Monnerie
2010-05-18 10:16 ` Emmanuel Florac
2010-05-18 11:01 ` Default User
2010-05-18 11:42   ` Michael Monnerie [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201005181342.17267@zmi.at \
    --to=michael.monnerie@is.it-management.at \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox