Re: dropping inode keyed locks in mod_dav_fs

[Stefan Fritsch <sf...@sfritsch.de>]

On Friday 23 October 2009, Stefan Fritsch wrote:
> On Thursday 22 October 2009, Joe Orton wrote:
> > > Is the performance improvement of inode keyed locking so large
> > > that it  is worth the hassle? If mod_dav_fs used filename keyed
> > > locking entirely, there would be an easy way to make file
> > > replacement by PUT atomic (see PR 39815). The current behaviour
> > > of deleting the old and the new file when the PUT fails is
> > > really bad.
> >
> > I believe the intent of using inode/device-number keyed locks was
> >  to  ensure that the lock database is independent of the mount
> >  point - i.e. you could move it around in the filesystem and it'd
> >  still work.
> 
> Interesting. Do you think this feature is actually used?
> 
> > I certainly agree that the delete-on-PUT-failure behaviour is
> > bad; I  think the correct behaviour would be to do the deletion
> > only if the resource is newly created by the PUT.
> 
> That would still replace the old file with a broken new file. Even
> better would be to save the new file to a temp file and move that
>  over the old file if it the transfer has completed successfully.
>  But this breaks locking with inode keyed locks. Therefore I would
>  like to move to filename keyed locks (which are already there for
>  systems without inode numbers). Any opinions on this?

Since nobody disagreed, I am going ahead with this and remove inode 
keyed locks and make PUT use temp files.

Using temp files and inode keyed locks would require to either copy 
(instead of move) the temp file to the target file, or to extend the 
dav_hooks_locks interface. I think both solutions are worse than just 
switching to file name keyed locks.

Re: dropping inode keyed locks in mod_dav_fs

[Greg Stein <gs...@gmail.com>]

Sorry for missing earlier messages; I don't follow httpd as closely as before.

See my replies below:

On Mon, Nov 9, 2009 at 06:28, Stefan Fritsch <sf...@sfritsch.de> wrote:
> On Friday 23 October 2009, Stefan Fritsch wrote:
>> On Thursday 22 October 2009, Joe Orton wrote:
>> > > Is the performance improvement of inode keyed locking so large
>> > > that it  is worth the hassle? If mod_dav_fs used filename keyed
>> > > locking entirely, there would be an easy way to make file
>> > > replacement by PUT atomic (see PR 39815). The current behaviour
>> > > of deleting the old and the new file when the PUT fails is
>> > > really bad.
>> >
>> > I believe the intent of using inode/device-number keyed locks was
>> >  to  ensure that the lock database is independent of the mount
>> >  point - i.e. you could move it around in the filesystem and it'd
>> >  still work.

No, I don't think so. The database would be movable with or without
inodes, afaik.

That is dim history :-P, but I am pretty it is because I was looking
forward to when the BIND protocol was implemented and you could bind
multiple URLs to the same resource. Thus, if you wanted to lock the
*resource*, then the inode was your primary key. Locking one path and
allowing changes through another would be Badness.

>... [snip: bad PUT behavior] ...
>
> Since nobody disagreed, I am going ahead with this and remove inode
> keyed locks and make PUT use temp files.
>
> Using temp files and inode keyed locks would require to either copy
> (instead of move) the temp file to the target file, or to extend the
> dav_hooks_locks interface. I think both solutions are worse than just
> switching to file name keyed locks.

People aren't running around with symlinks in their repository, I
believe. mod_dav is pretty unaware of them, and Bad Things are
advertised to happen. It already takes some steps to explicitly
disallow symlinks as "files". Thus, the notion of one resource in two
locations is probably moot.

Therefore, improving the PUT situation rather than keeping inodes is a
very good tradeoff.

Thanks,
-g