lkml.org 
[lkml]   [2015]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: First kernel patch (optimization)
From
Date
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



\
 
 \ /
  Last update: 2015-09-20 13:01    [W:0.770 / U:0.720 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site