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
prev parent 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