From: Eric Sandeen <sandeen@sandeen.net>
To: xfs@oss.sgi.com
Subject: Re: [PATCH] (and bad attr2 bug) - pack xfs_sb_t for 64-bit arches
Date: Thu, 17 May 2007 09:41:40 -0500 [thread overview]
Message-ID: <464C69A4.6050605@sandeen.net> (raw)
In-Reply-To: <455CB54F.8080901@sandeen.net>
Eric Sandeen wrote:
> see also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212201
>
> Bugzilla Bug 212201: Cannot build sysem with XFS file system.
>
> I turned on attr2 in FC6 at nathan's suggestion, for selinux goodness
> with more efficient xattr space usage.
>
> But, many reports that this was totally broken in fc6, on x86_64.
Although it turned out to be a different issue, not the packing issue,
is the packing/alignment (below) still something that needs to be fixed...?
-Eric
> Install went ok, but on reboot the filesystem was found to be corrupt.
>
> The filesystem was also found to be marked w/ attr1, not attr2....
>
> If you do a fresh mkfs.xfs on x86_64, with -i attr=2, and dump out the
> superblock (or look at it with xfs_db) you will find that although the
> versionnum says that there is a morebits bit, the features2 flag is 0.
>
> if you dd/hexdump the superblock, you will find the attr2 flag, but at
> the wrong offset.
>
> This is because the xfs_sb_t struct is padded out to 64 bits on 64-bit
> arches, and the xfs_xlatesb() routine and xfs_sb_info[] array take this
> padding to mean that the last item is 4 bytes bigger than it is, and
> treats sb_features2 as 8 bytes not four. This then gets endian-flipped out...
>
> I can't quite figure out how this winds up causing problems if you stay
> on the x86_64 arch, as I'd expect that if the offset is wrong, it should
> at least be consistently wrong. And in fact if you do mkfs,mount,xfs_info,
> it will tell you that you do have attr2. But somewhere along the line thing
> go wrong, and post-install, post-reboot, the filesystem thinks it is attr1,
> and is therefore corrupt.
>
> I think that maybe some accesses are post-xfs_xlatesb, while others
> may access the un-flipped sb directly? Or maybe this is sb logging
> code that has messed things up? Not sure... needs more investigation.
>
> In any case, dd does not lie, and this patch for the kernel, and a
> corresponding one for userspace, at least make "mkfs.xfs -i attr=2"
> puts the features2 flag in the right place, as shown by inspection via dd.
>
> Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
>
> Index: linux-2.6.18/fs/xfs/xfs_sb.h
> ===================================================================
> --- linux-2.6.18.orig/fs/xfs/xfs_sb.h
> +++ linux-2.6.18/fs/xfs/xfs_sb.h
> @@ -149,7 +149,7 @@ typedef struct xfs_sb
> __uint16_t sb_logsectsize; /* sector size for the log, bytes */
> __uint32_t sb_logsunit; /* stripe unit size for the log */
> __uint32_t sb_features2; /* additional feature bits */
> -} xfs_sb_t;
> +} __attribute__ ((packed)) xfs_sb_t;
>
> /*
> * Sequence number values for the fields.
>
>
>
next prev parent reply other threads:[~2007-05-17 14:41 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-16 19:00 [PATCH] (and bad attr2 bug) - pack xfs_sb_t for 64-bit arches Eric Sandeen
2006-11-16 22:10 ` Eric Sandeen
2006-11-20 3:50 ` Eric Sandeen
2006-11-21 4:02 ` Eric Sandeen
2006-11-22 1:02 ` Russell Cattelan
2006-11-22 8:59 ` Timothy Shimmin
2006-11-22 15:44 ` Eric Sandeen
2006-11-22 16:24 ` Russell Cattelan
2006-11-22 16:38 ` Eric Sandeen
2006-11-23 7:09 ` Timothy Shimmin
2006-11-23 17:37 ` Russell Cattelan
2006-11-24 4:47 ` Timothy Shimmin
2006-11-27 12:50 ` Tim Shimmin
2006-11-29 9:56 ` [PATCH] attr2 patch for data btrees & attr 2 was: " Timothy Shimmin
2006-11-23 22:49 ` [PATCH] " David Chinner
2006-11-16 22:45 ` David Chinner
2006-11-16 22:55 ` Eric Sandeen
2006-11-17 15:53 ` Russell Cattelan
2006-11-17 1:08 ` Timothy Shimmin
2006-11-17 2:39 ` David Chinner
2006-11-17 4:11 ` Timothy Shimmin
2006-11-17 5:55 ` David Chinner
2006-11-17 6:34 ` sandeen
2006-11-17 6:52 ` Nathan Scott
2006-11-17 15:20 ` sandeen
2006-11-19 23:11 ` Nathan Scott
2006-11-20 1:39 ` Eric Sandeen
2006-11-20 3:00 ` Nathan Scott
2006-11-20 3:32 ` Eric Sandeen
2006-11-20 3:37 ` Nathan Scott
2006-11-17 6:58 ` David Chinner
2006-11-17 23:49 ` Eric Sandeen
2007-05-17 14:41 ` Eric Sandeen [this message]
2007-05-21 7:42 ` David Chinner
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=464C69A4.6050605@sandeen.net \
--to=sandeen@sandeen.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.