lkml.org 
[lkml]   [2012]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: getdents - ext4 vs btrfs performance
On 3/13/2012 5:33 PM, Ted Ts'o wrote:
> Are you volunteering to spearhead the design and coding of such a
> thing? Run-time sorting is backwards compatible, and a heck of a lot
> easier to code and test...

Do you really think it is that much easier? Even if it is easier, it is
still an ugly kludge. It would be much better to fix the underlying
problem rather than try to paper over it.

> The reality is we'd probably want to implement run-time sorting
> *anyway*, for the vast majority of people who don't want to convert to
> a new incompatible file system format. (Even if you can do the
> conversion using e2fsck --- which is possible, but it would be even
> more code to write --- system administrators tend to be very
> conservative about such things, since they might need to boot an older
> kernel, or use a rescue CD that doesn't have an uptodate kernel or
> file system utilities, etc.)

The same argument could have been made against the current htree
implementation when it was added. I think it carries just as little
weight now as it did then. People who care about the added performance
the new feature provides can use it, those who don't, won't. Eventually
it will become ubiquitous.

> We would still have to implement the case where hash collisions *do*
> exist, though, and make sure the right thing happens in that case.
> Even if the chance of that happening is 1 in 2**32, with enough
> deployed systems (i.e., every Android handset, etc.) it's going to
> happen in real life.

Sure it will happen, but if we read one extra block 1 in 4 billion
times, nobody is going to notice.



\
 
 \ /
  Last update: 2012-03-14 15:31    [W:0.120 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site