Message-ID: <AANLkTinkHQ2tqAzqo77Bg_iyyYWUE72V85rTQqsEH4Nc@mail.gmail.com>
Date:	Tue, 28 Dec 2010 23:54:33 +0100
From:	Olaf van der Spek <olafvdspek@...il.com>
To:	Neil Brown <neilb@...e.de>
Cc:	Christian Stroetmann <stroetmann@...olinux.com>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-ext4@...r.kernel.org, "Ted Ts'o" <tytso@....edu>,
	Nick Piggin <npiggin@...il.com>
Subject: Re: Atomic non-durable file write API

On Tue, Dec 28, 2010 at 11:31 PM, Neil Brown <neilb@...e.de> wrote:
>> True, but all those exceptions (IMO) should be (proven to be) no problem.
>> I'd prefer designs that don't have such exceptions. I may not be able
>> to think of a concrete problem right now, but that doesn't mean such
>> problems don't exist.
>
> Very true.  But until such problems are described an understood, there is not
> a lot of point trying to implement a solution.  Premature implementation,
> like premature optimisation, is unlikely to be fruitful.  I know this from
> experience.

The problems seem clear. The implications not yet.

>>
>> I also don't understand why providing this feature is such a
>> (performance) problem.
>> Surely the people that claim this should be able to explain why.
>
> Without a concrete design, it is hard to assess the performance impact.  I
> would guess that those who anticipate a significant performance impact are
> assuming a more feature-full implementation than you are, and they are
> probably doing that because they feel that you need the extra features to
> meet the actual needs (and so suggest those needs a best met by a DBMS rather
> than a file-system).
> Of course this is just guess work.  With concreted reference points it is
> hard to be sure.

True, I don't understand why people say it will cause a performance
hit but then don't want to tell why.

>>
>> > You seem to be asking for the ability to atomically change the data in a file
>> > without changing the metadata.  I cannot see why you would want this.  Maybe
>> > you could give an explicit use-case??
>>
>> Where losing meta-data is bad? That should be obvious.
>> Or where losing file owner is bad? Still thinking about that one.
>
> This is a bit left-field, but I think that losing metadata is always a good
> thing.  A file should contain data - nothing else.  At all.  Owner and access
> permissions should be based on location as dictated by external policy....
> but yeah - off topic.

In that case meta-data shouldn't be supported in the first place.

> Clearly maintaining metadata by creating a new file and renaming in-place is
> easy for root (chown/chmod/etc).  So you are presumably envisaging situations
> where a non-root user has write access to a file that they don't own, and
> they want to make an atomic data-update to that file.
> Sorry, but I think that allowing non-owners to write to a file is a really
> really bad idea and providing extra support for that use-case is completely
> unjustifiable.

Isn't it quite common?
Is preserving other meta-data really easy enough to be sure most apps do it?

> If you want multiple people to be able to update some data you should have
> some way to ask the owner to make an update.  That could be:
>  - setuid program
>  - daemon which authenticates requests
>  - distributed workflow tool like 'git' where you speak to the owner
>    and ask them to pull updates.
>
> and there are probably other options.  But un-mediated writes to a file you
> don't own?  Just say NO!

Wouldn't that make Linux user groups quite useless?

Olaf
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists