Date:	Sun, 20 Sep 2015 12:41:48 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Theodore Ts'o <tytso@....edu>,
	Greg KH <gregkh@...uxfoundation.org>,
	Josh Boyer <jwboyer@...oraproject.org>,
	Eric Curtin <ericcurtin17@...il.com>,
	Austin S Hemmelgarn <ahferroin7@...il.com>,
	Steve Calfee <stevecalfee@...il.com>,
	Valentina Manea <valentina.manea.m@...il.com>,
	Shuah Khan <shuah.kh@...sung.com>,
	USB list <linux-usb@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: First kernel patch (optimization)

Am 20.09.2015 um 04:21 schrieb Theodore Ts'o:
> On Sat, Sep 19, 2015 at 07:47:22PM +0200, Alexander Holler wrote:

> Perhaps not so surprisingly, over a decade later, it is not currently
> at the top of the priority list of any of the current file system or
> VFS developers, as far as I know.  One of the reasons for that is that
> there are a number of other ways of achieving the same functionality.
> These include using tmpfs, or using file system level encryption.
> They require a bit more system administrator setup than just being
> able to set the FS_SECR_FL flag, true, but just because it's more
> convenient doesn't mean that it's worth doing.

Again, I don't think that encryption is an alternative. Besides that 
there is always the thread that strong encrytion will become regulated, 
there is also the very real thread that someone might end up in jail 
when using encryption and throwing away the key to delete stuff. E.g., 
as to my knowledge, in the UK you might end up in jail if you don't hand 
out a password. So what happens if you've deleted the key and are really 
unable to hand it out and the people which have an interest in what 
you've once stored don't believe you?

> So.... this is a feature request.  It's a reasonable feature request,
> in that if someone would like to pay $$$ for some consultant to
> implement it in a way that is bug-free, I suspect it could go
> upstream.  Someone who was very motivated and with the sufficient
> skills could also invest their own effort to make a patch that can go
> upstream too.  You've elected not, to because you believe it would
> take you months of "unpaid time".  That's purely within your rights to
> do.  But you don't have the right to try to tell other people what
> work to do on their behalf --- not unless you are paying their salary.

First I haven't request that someone implements it for me. Besides that 
what you're describing is what maintainers do all the time. Of course, 
it's their job to request quality, but, in my humble opinion, very often 
they are requesting stuff just to request something.

And that "month of unpaid time" was for sure a cynical exaggeration I've 
done while having been angry. In fact I believe the way I've outlined 
with the ugly code (proof of concept) could be implemented by someone 
like you in a weekend. For me it needs quiet some more time because I 
had and still have almost zero knowledge about all locks and whatever 
else is used in the filesystem code. But nevertheless I was able to fix 
up a lot of stuff during another afternoon. E.g. I've added checks if a 
file is in use or if AT_WIPE was called on a directory and then returned 
errors in those cases. Unfortunately the code changed in 4.2 and that 
patch doesn't apply anymore and now, because I don't really need those 
implementation details (I'm aware of the problems of my patch), I've 
thrown the patch into the waste bin. Besides that my concept doesn't 
work on BTRFS what I'm currently using for various reasons (mainly 
compression) on most of my systems. And I have no idea if it ever will 
(because I don't know why discard on BTRFS doesn't really discard what I 
think it should discard. ;) ).


> Seeing that the weight of the other file system developers are against
> the patch, it's never gone into the mainline Linux kernel, even though
> I could have forced the feature into ext4.  However, this patch is in
> active use in practically every single data center kernel for Google,
> and it's in use in at least one other very large publically traded
> company that uses cluster file systems such as Hadoopfs.  And if
> someone wants a copy of the FALLOC_FL_NO_HIDE_STALE patch for ext4,
> I'm happy to give it to them.  But it hasn't gone upstream, and I'm OK
> with that.

Sure, but please don't forget its quiet some difference if someone does 
stuff without being paid and all he earns are unfriendly comments. In 
fact I still don't care much about if any code from me ends up in 
mainline, but I dislike quiet a lot the tone used by many maintainers to 
refuse things someone offered in a good believe.

E.g. recently I've read that a maintainer requested that patch posters 
should be aware of his calendar (like conferences he visits, merge 
windows he has to care for and similar stuff. ?!?

> As far as what you want to do next, you have a personal "proof of
> concept" patch that seems to work well enough for you.  Great!  I'm
> sure you can keep using it for your own purposes.  If you can convince
> someone with the skills to get the patch to an upstreamable state, it
> is my judgement that this is doable, so this puts your feature in a
> much better state than the FALLOC_FL_NO_HIDE_STALE flag.  However,
> there is still a non-trivial amount of work left to do to turn your
> "proof of concept" patch into something that is upstremable, including
> changing the interface to using the FS_SECRM_FL flag.  And your
> whining that other people should change *their* priorities to match
> *yours* is not likely to help.

Besides that I have absolutely no knowledge about 
FALLOC_FL_NO_HIDE_STALE or the FS_SECRM_FL flag, I've never whined. I've 
complained about the tone very often used on this list. And it doesn't 
help if you are suggesting I'm whining. It just proves my assumption, at 
least in my eyes.

Thanks for the discussion.

Alexander Holler

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

Powered by blists - more mailing lists