Re: Atomic non-durable file write API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 28, 2010 at 11:31 PM, Neil Brown <neilb@xxxxxxx> 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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux