Mailing List Archive: Apache: Dev

dropping inode keyed locks in mod_dav_fs (was: Dav Locks corrupting; need some troubleshooting tools)

Index | Next | Previous | View Threaded

sf at sfritsch

Oct 18, 2009, 12:50 PM

Post #1 of 6 (649 views)
Permalink

dropping inode keyed locks in mod_dav_fs (was: Dav Locks corrupting; need some troubleshooting tools)

On Thursday 15 October 2009, Dick Davies wrote:
> In any event, does it made sense to use something other than the
> inode as the key into the lockDB - the URI for example?

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.

rasputnik at hellooperator

Oct 19, 2009, 4:16 AM

Post #2 of 6 (617 views)
Permalink

Re: dropping inode keyed locks in mod_dav_fs (was: Dav Locks corrupting; need some troubleshooting tools) [In reply to]

On Sun, Oct 18, 2009 at 8:50 PM, Stefan Fritsch <sf [at] sfritsch> wrote:
> On Thursday 15 October 2009, Dick Davies wrote:
>> In any event, does it made sense to use something other than the
>> inode as the key into the lockDB - the URI for example?
>
> 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.

Agreed.
I can see how inodes are faster, but I'd like an alternative option -
maybe a similar config option to the ETags tunable ; if the DBM key was
mtime+inode number my problem would go away, for example.

[. I know it may sounds like 'Doctor it hurts when I do this'
wrt. other processes editing files underneath mod_dav, but it's a fairly
common thing to do in most installs I've seen. It's certainly the first
time I've heard that DAV requires exclusive access to a filesystem to avoid
strange behaviour. ]

jorton at redhat

Oct 22, 2009, 1:56 AM

Post #3 of 6 (609 views)
Permalink

Re: dropping inode keyed locks in mod_dav_fs (was: Dav Locks corrupting; need some troubleshooting tools) [In reply to]

On Sun, Oct 18, 2009 at 09:50:25PM +0200, Stefan Fritsch wrote:
> On Thursday 15 October 2009, Dick Davies wrote:
> > In any event, does it made sense to use something other than the
> > inode as the key into the lockDB - the URI for example?
>
> 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.

(It would also allow mod_dav to support BIND via hard links since locks
would be associated correctly with a resource rather than a URI path,
but that is not really a consideration here)

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.

Regards, Joe

sf at sfritsch

Oct 23, 2009, 11:26 AM

Post #4 of 6 (598 views)
Permalink

Re: dropping inode keyed locks in mod_dav_fs (was: Dav Locks corrupting; need some troubleshooting tools) [In reply to]

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?

Cheers,
Stefan

sf at sfritsch

Nov 9, 2009, 3:28 AM

Post #5 of 6 (505 views)
Permalink

Re: dropping inode keyed locks in mod_dav_fs [In reply to]

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.

gstein at gmail

Nov 9, 2009, 5:29 AM

Post #6 of 6 (502 views)
Permalink

Re: dropping inode keyed locks in mod_dav_fs [In reply to]

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 [at] sfritsch> 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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads