public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Russell Cattelan <cattelan@thebarn.com>
Cc: Timothy Shimmin <tes@sgi.com>, xfs@oss.sgi.com
Subject: Re: [PATCH] (and bad attr2 bug) - pack xfs_sb_t for 64-bit arches
Date: Wed, 22 Nov 2006 10:38:16 -0600	[thread overview]
Message-ID: <45647CF8.8020104@sandeen.net> (raw)
In-Reply-To: <1164212695.19915.65.camel@xenon.msp.redhat.com>

Russell Cattelan wrote:
> On Wed, 2006-11-22 at 09:44 -0600, Eric Sandeen wrote:
>> Timothy Shimmin wrote:
>>> Thanks, Russell.
>>>
>>> I've been going thru the irc and just started looking at the patch.
>>> I'll get back to you about it tomorrow.
>>>
>>> I agree it would be good to have the fixed forkoff for data btree roots
>>> as the first fix. And look into redoing the btree root for a later change.
>> My only question is, how much does this defeat the purpose of attr2?
> Well from the standpoint that attr2 currently corrupts inodes anything
> to prevent that is good, since  currently attr2 can't be used at all.
> When the di_u is extent based the attr2 code works as expected, giving
> space to which ever segment gets there first.The attr2 code should still
> be a big win for most file/dir inodes since they are probably able to do
> their block mapping with local or extent mode.

yeah, that;s rpobqably true.

> The number of inodes that get pushed to btree mode should be a small %
> of the
> total number of inodes, especially on a root file system. So while attr2
> is
> not as efficient as it could be for that segment of the inodes the rest
> of inodes
> do benefit from attr2
> 
> By fixing the initial size calculation at least things like SElinux
> which is adding one attr won't cause the attr segment to flip to extents
> immediately.
> The second attr will cause the flip but not the first one.

I'd say this part (fixing up proper space for the initial attr fork 
setup) should probably go in soon if it gets good reviews (with the 
removal of the extra tests, as we discussed on irc last night).  I think 
this proper change stands on its own just fine.

the rest of the patch... I'd rather not confuse the functional changes 
with your rearrangement of return locations (the new gotos etc) but 
that's just me.

I think the bytesfit() fixup is probably good too, with your short-term 
addition of "if forkoff exists with btree data then it cannot move"

-Eric

> 
>> -Eric
>>

  reply	other threads:[~2006-11-22 16:39 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 [this message]
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
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=45647CF8.8020104@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=cattelan@thebarn.com \
    --cc=tes@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox