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
