All of lore.kernel.org
 help / color / mirror / Atom feed
* User feedback: raise the default leaf size to 16k
@ 2013-02-13 10:33 Holger Hoffstaette
  2013-03-03 10:33 ` Brendan Hide
  0 siblings, 1 reply; 3+ messages in thread
From: Holger Hoffstaette @ 2013-02-13 10:33 UTC (permalink / raw)
  To: linux-btrfs


Hi,

after using btrfs with 3.7.x and default settings without any problems so
far (knock on wood!) I had to redo a 1TB filesystem and this time decided
to try two small changes:

- raise the leaf size to 16k
- use single metadata profile

After restoring the contents (~300GB, mix of large and small files) the
difference in behaviour on a single disk is *very* noticeable.
Therefore I want to suggest changing the default values accordingly. IMHO
the new behaviour - maybe including the single metadata redundancy - is
much more in line with behaviour that people expect out of the box. I
believe many cases where users report degrading performance over time can
be attributed to this. Whether single metadata is too much of a risk I
cannot judge, but please at least raise the default leaf size.

Just my 0.01€ of user feedback :)

thanks
Holger



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: User feedback: raise the default leaf size to 16k
  2013-02-13 10:33 User feedback: raise the default leaf size to 16k Holger Hoffstaette
@ 2013-03-03 10:33 ` Brendan Hide
  2013-03-03 16:36   ` Chris Mason
  0 siblings, 1 reply; 3+ messages in thread
From: Brendan Hide @ 2013-03-03 10:33 UTC (permalink / raw)
  To: Holger Hoffstaette; +Cc: linux-btrfs

On 2013/02/13 12:33 PM, Holger Hoffstaette wrote:
> - raise the leaf size to 16k
> - use single metadata profile
>
> ...
>
> the difference in behaviour on a single disk is *very* noticeable.
Did you try an isolated change of leaf size? I think the devs would be 
willing to look into the default size if it makes a dramatic difference 
on its own. Personally I think you are seeing an improvement more as a 
result of the metadata profile rather than the leafsize.

I don't think changing the default profile for metadata will be easily 
entertained as this is very important for protecting against corruption 
due to bitrot.

-- 
__________
Brendan Hide
http://swiftspirit.co.za/
http://www.webafrica.co.za/?AFF1E97


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: User feedback: raise the default leaf size to 16k
  2013-03-03 10:33 ` Brendan Hide
@ 2013-03-03 16:36   ` Chris Mason
  0 siblings, 0 replies; 3+ messages in thread
From: Chris Mason @ 2013-03-03 16:36 UTC (permalink / raw)
  To: Brendan Hide; +Cc: Holger Hoffstaette, linux-btrfs

On Sun, Mar 03, 2013 at 03:33:30AM -0700, Brendan Hide wrote:
> On 2013/02/13 12:33 PM, Holger Hoffstaette wrote:
> > - raise the leaf size to 16k
> > - use single metadata profile
> >
> > ...
> >
> > the difference in behaviour on a single disk is *very* noticeable.
> Did you try an isolated change of leaf size? I think the devs would be 
> willing to look into the default size if it makes a dramatic difference 
> on its own. Personally I think you are seeing an improvement more as a 
> result of the metadata profile rather than the leafsize.
> 
> I don't think changing the default profile for metadata will be easily 
> entertained as this is very important for protecting against corruption 
> due to bitrot.

The long term plan is to set the default size to 16K, since this does
cut down on metadata fragmentation.  But in some benchmarks, it adds lock
contention because we have fewer blocks to spread the locks over.

The 3.9 merge window has fixes for lock contention, so I need to
benchmark things again.

-chris

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-03-03 16:36 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-13 10:33 User feedback: raise the default leaf size to 16k Holger Hoffstaette
2013-03-03 10:33 ` Brendan Hide
2013-03-03 16:36   ` Chris Mason

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.