Re: [PATCH 00/23] per device dirty throttling -v8

[Ingo Molnar <mingo@elte.hu>]

* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > you try to put the blame into distribution makers' shoes but in 
> > reality, had the kernel stepped forward with a neat .config option 
> > sooner (combined with a neat boot option as well to turn it off), 
> > we'd have had noatime systems 10 years ago. A new entry into 
> > relnotes and done. It's
> 
> Sorry Ingo, having been in the distribution business for over ten 
> years I have to disagree. Kernel options that magically totally change 
> the kernel API and behaviour are exactly what a vendor does *NOT* want 
> to have.

it's default off of course. A distro can turn it on or off.

> > Distro makers did not dare to do this sooner because some kernel 
> > developers came forward with these mostly bogus arguments ... The 
> > impact of atime is far better understood by the kernel community, so 
> > it is the responsibility of _us_ to signal such things towards 
> > distributors, not the other way around.
> 
> You are trying to put a bogus divide between kernel community and 
> developer community. Yet you know perfectly well that a large part of 
> the kernel community yourself included work for distribution vendors 
> and are actively building the distribution kernels.

i've periodically pushed for a noatime distro kernel for like ... 5-10
years and last time this argument came up [i brought it up 6 months ago]
most of the distro kernel developer actually recommended using noatime,
but it took only 1-2 kernel developers to come out with the
'compatibility' and 'compliance' boogeyman to scare the distro userspace
people away from changing /etc/fstab.

so yes, things like this needs a clear message from the kernel folks,
and a kernel option for that is a pretty good way of doing it.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/