From: Timothy Shimmin <tes@sgi.com>
To: David Chinner <dgc@sgi.com>
Cc: "bnaujok@sgi.com via BugWorks" <bnaujok@sgi.com>,
xfs-dev <xfs-dev@sgi.com>, xfs-oss <xfs@oss.sgi.com>,
asg-qa <asgqa@sgi.com>
Subject: Re: REVIEW XFSQA test out xfs_attr_shortform_bytesfit attr2/attr1 fix
Date: Mon, 14 Apr 2008 13:56:46 +1000 [thread overview]
Message-ID: <4802D5FE.80005@sgi.com> (raw)
In-Reply-To: <20080414032229.GV103491721@sgi.com>
Hi Dave,
David Chinner wrote:
> On Mon, Apr 14, 2008 at 11:35:36AM +1000, Timothy Shimmin wrote:
>> Hi Dave and Barry,
>>
>> David Chinner wrote:
>>> On Wed, Apr 09, 2008 at 06:10:36PM +1000, Timothy Shimmin wrote:
>>>> Hi there,
>>>>
>>>> A test to test out Eric's fix for xfs_attr_shortform_bytesfit
>>>> bug when going from attr2 to attr1.
>>>>
>>>> With TOT kernel, without patch, one can see the corrupted inline
>>>> dirents. With patch, all is well.
>>>>
>>>> The 186.out _should_ be output'ing ATTR2 for the db version
>>>> command but I'm awaiting Barry's xfsprogs checkin to fix that one -
>>>> and then I will regenerate it.
>>> Really? I'm seeing it fail with ATTR2 in the xfs_db output...
>>>
>> That's what I used to see until I updated to TOT kernel.
>> That's weird.
>
> It's likely due to Eric's change to make sb_badfeatures2 =
> sb_features2. That will make userspace pick up the attr2 feature
> properly regardless of where it is. Perhaps xfs_db is b0rked
> w.r.t. reporting attr vs attr2....
>
> Cheers,
>
> Dave.
I'm not sure, but with Barry's latest checkins, all seems well
and I'm now getting the attr2 output as expected.
Which just leaves the ATTR and ATTR2 output when I add an EA
to a file on an ATTR2 file-system.
It is naturally the kernel that is doing this.
The existing behaviour prior to ATTR2, was to
turn on ATTR as soon as one added an EA to a file (added by doucette).
> xfs_bmap_add_attrfork
....
> if (!xfs_sb_version_hasattr(&mp->m_sb) ||
> (!xfs_sb_version_hasattr2(&mp->m_sb) && version == 2)) {
> __int64_t sbfields = 0;
>
> spin_lock(&mp->m_sb_lock);
> if (!xfs_sb_version_hasattr(&mp->m_sb)) {
> xfs_sb_version_addattr(&mp->m_sb);
> sbfields |= XFS_SB_VERSIONNUM;
> }
> if (!xfs_sb_version_hasattr2(&mp->m_sb) && version == 2) {
> xfs_sb_version_addattr2(&mp->m_sb);
> sbfields |= (XFS_SB_VERSIONNUM | XFS_SB_FEATURES2);
> }
So I would say it is intentional and we are preserving the behaviour of
knowing if we have EAs in use or not.
I guess it seems a bit redundant but it may well cause less problems in
doing so and doesn't hurt.
--Tim
next prev parent reply other threads:[~2008-04-14 3:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-09 8:10 REVIEW XFSQA test out xfs_attr_shortform_bytesfit attr2/attr1 fix Timothy Shimmin
2008-04-10 5:36 ` David Chinner
2008-04-14 1:35 ` Timothy Shimmin
2008-04-14 1:46 ` Barry Naujok
2008-04-14 3:22 ` David Chinner
2008-04-14 3:56 ` Timothy Shimmin [this message]
2008-04-14 4:23 ` Timothy Shimmin
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=4802D5FE.80005@sgi.com \
--to=tes@sgi.com \
--cc=asgqa@sgi.com \
--cc=bnaujok@sgi.com \
--cc=dgc@sgi.com \
--cc=xfs-dev@sgi.com \
--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.