Re: btrfs: poor performance on deleting many large files

[Duncan <1i5t5.duncan@cox.net>]

Christoph Anton Mitterer posted on Tue, 15 Dec 2015 00:25:05 +0100 as
excerpted:

> On Mon, 2015-12-14 at 22:30 +0100, Lionel Bouton wrote:
> 
>> I use noatime and nodiratime

> FYI: noatime implies nodiratime :-)

Was going to post that myself.  Is there some reason you:

a) use nodiratime when noatime is already enabled, despite the fact that 
the latter already includes the former, or

b) didn't sufficiently research the option (at least the current mount 
manpage documents that noatime includes nodiratime under both the noatime 
and nodiratime options, and at least some hint of that has been in the 
manpage for years as I recall reading it when I first read of nodiratime 
and checked whether my noatime options included it) before standardizing 
on it, or

c) might have actually been talking in general, and there's some mounts 
you don't actually choose to make noatime, but still want nodiratime, or

d) chose that isn't otherwise reflected in the above?  If so, please 
describe, as it could be a learning experience for me, and possibly 
others as well.

>> Finally Linus Torvalds has been quite vocal and consistent on the
>> general subject of the kernel not breaking user-space APIs no matter
>> what so I wouldn't have much hope for default kernel mount options
>> changes...

> He surely is right in general,... but when the point has been reached,
> where only a minority actually requires the feature... and the minority
> actually starts to suffer from that... it may change.

Generally speaking, the practical rule is that you don't break userspace, 
but that a break that isn't noticed and reported by someone within a few 
release cycles is considered OK, as obviously nobody who actually cares 
enough about the possibility of old userspace breaking on new kernels 
enough to test for it was (still) using that functionality anyway.  (This 
is sometimes known as the "if a tree falls in the forest and there's 
nobody around to hear it, did it actually fall", rule. =:^)

But if it's noticed and reported before the new behavior itself is locked 
into place by other userspace relying on it, the change in behavior must 
be reverted.  (There have actually been a few cases over the years where 
they went to rather exceptional lengths to make two otherwise 
incompatible userspace-exposed behaviors both continue to work for the 
userspace that expected that behavior, without actually coding in such 
obvious hacks as executable name conditionals or the like, as others have 
been known to do at times.  Sometimes these fixes do end up bending the 
rules a bit, particularly the no-policy-in-the-kernel rule, but they do 
reinforce the now userspace breakage rule.)

The possible workarounds include the handful of kernel compatibility 
options that when enabled continue otherwise userspace breaking behavior 
such as removing old kernel API procfs files and the like.

That practical rule does in effect make it possible to do userspace-
breaking changes if you wait around long enough that there's nobody who 
will complain still actually using the old behavior.


-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman