Re: FUSE file locking

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FUSE file locking

Franco Broi
On Tue, 2005-05-31 at 17:10 +0200, jens m. noedler wrote:

> I'm planning to code a WebDAV filesystem for FUSE, that supports file
> locking. Therefor i need to know, when a process calls lockf/flock and
> then pass the LOCK/UNLOCK WebDAV commando to the WebDAV server.
>
> But until now i have not found out how to handle locks with FUSE.
>

All the locking for a FUSE filesystem is handled in the kernel, lock
commands don't get passed down to the application.

This might be a good time to reopen the discussion re locking, it's a
pretty thorny subject.




-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FUSE file locking

JoelKatz

> All the locking for a FUSE filesystem is handled in the kernel, lock
> commands don't get passed down to the application.

        Which is, of course, useless since the kernel can't actually lock the
files.

> This might be a good time to reopen the discussion re locking, it's a
> pretty thorny subject.

        Yeah, it has been on my FUSE wishlist for a long time.

        Unfortunately, the way we have to handle it now is that any time we get a
request to open a file or directory for read access, we have to read lock
it. And anytime we see an open for a file or directory for write access, we
have to write lock it. This really hurts concurrency and can cause
deadlocks. This is not the UNIX way, it is the Windows way.

        DS




-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: FUSE file locking

Franco Broi
On Tue, 2005-05-31 at 20:33 -0700, David Schwartz wrote:

> > All the locking for a FUSE filesystem is handled in the kernel, lock
> > commands don't get passed down to the application.
>
> Which is, of course, useless since the kernel can't actually lock the
> files.
>
> > This might be a good time to reopen the discussion re locking, it's a
> > pretty thorny subject.
>
> Yeah, it has been on my FUSE wishlist for a long time.
>
> Unfortunately, the way we have to handle it now is that any time we get a
> request to open a file or directory for read access, we have to read lock
> it. And anytime we see an open for a file or directory for write access, we
> have to write lock it. This really hurts concurrency and can cause
> deadlocks. This is not the UNIX way, it is the Windows way.
>

>From what I can remember the main issue is lock ownership. What
mechanism removes the lock in the event the lock holder dies without
first unlocking the file.



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Re: FUSE file locking

JoelKatz

> > Unfortunately, the way we have to handle it now is that any
> > time we get a
> > request to open a file or directory for read access, we have to
> > read lock
> > it. And anytime we see an open for a file or directory for
> > write access, we
> > have to write lock it. This really hurts concurrency and can cause
> > deadlocks. This is not the UNIX way, it is the Windows way.

> From what I can remember the main issue is lock ownership. What
> mechanism removes the lock in the event the lock holder dies without
> first unlocking the file.

        There are two ways to do this. One is that a lock (that the filesystem is
informed about) can only be placed on a file that is associated with a
handle. When the handle is freed, any locks associated with that handle are
released. Alternatively, whenever FUSE places or removes locks itself, it
can just inform the filesystem. The filesystem would then get lock releases
when the lock holder died just as it gets them when the lock holder releases
them.

        DS




-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FUSE file locking

jens m. noedler
In reply to this post by Franco Broi
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

It was me, bringing up the locking issue again by asking Franco Broi
for FUSE locking support...


David Schwartz wrote:

>> All the locking for a FUSE filesystem is handled in the kernel,
>> lock commands don"t get passed down to the application.
>
> Which is, of course, useless since the kernel can"t actually lock
> the files.

Because the files being locked may not be accessible by the kernel?
I dont't think that this must be useless, because the fuse filesystem
can handle the lock request.

What is currently done when a process uses a flock() or fcntl() within
a fuse filesystem? -> return "???"; :-)

Greetings, Jens

- --
jens m. noedler
  [hidden email]
  pgp: 0x9f0920bb
  http://noedler.de


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCniwKBoFc9p8JILsRAnKxAJ4zDqGmXQwk3TGGddhzWfp/RM+EZgCeN8Dq
2RwaS1rIeoixqMS1+lNImTA=
=9KZH
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: FUSE file locking

Miklos Szeredi
> >> All the locking for a FUSE filesystem is handled in the kernel,
> >> lock commands don"t get passed down to the application.
> >
> > Which is, of course, useless since the kernel can"t actually lock
> > the files.
>
> Because the files being locked may not be accessible by the kernel?
> I dont't think that this must be useless, because the fuse filesystem
> can handle the lock request.
>
> What is currently done when a process uses a flock() or fcntl() within
> a fuse filesystem? -> return "???"; :-)

The file will be successfully locked.  But the filesystem daemon won't
be notified of any lock/unlock requests.

Whether this is useless or useful to you, depends on how you want to
use locking.

Miklos


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: FUSE file locking

John Muir-3
Miklos Szeredi wrote:

>
>The file will be successfully locked.  But the filesystem daemon won't
>be notified of any lock/unlock requests.
>
>Whether this is useless or useful to you, depends on how you want to
>use locking.
>
>Miklos
>
>  
>
Could we request that you implement the lock and unlock primitives? This
is high on my wishlist as well.

John.

--
John Muir
NORTEL
[hidden email]



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: FUSE file locking

Miklos Szeredi
> Could we request that you implement the lock and unlock primitives? This
> is high on my wishlist as well.

OK, I'll look into it sometime.

One thing should be clear though: you won't be able to just "forward"
all locking primitives to the underlying filesystem in the fashion of
other operations.  This is because locking has tricky semantics when
multiple threads are involved.

I don't remember the details, but this has been discussed on this list
maybe a year ago, so if you're interested, just look it up in the
archives.

Miklos


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: FUSE file locking

jens m. noedler
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Miklos Szeredi wrote at 02.06.2005 16:50:

>> Could we request that you implement the lock and unlock
>> primitives? This is high on my wishlist as well.
>
> OK, I'll look into it sometime.

Yes! Thanks a lot. It would be great to see it (maybe) in the upcoming
- -rc releases.

> One thing should be clear though: you won't be able to just
> "forward" all locking primitives to the underlying filesystem in the
> fashion of other operations. This is because locking has tricky
> semantics when multiple threads are involved.

I'm planing a webdav filesystem, that supports webdav locking. Because
there is only one webdav LOCK/UNLOCK command, it should be possibly to
map the linux lockf/flock commands to one webdav LOCK command.

Greetings, Jens

- --
jens m. noedler
  [hidden email]
  pgp: 0x9f0920bb
  http://noedler.de

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCoCIZBoFc9p8JILsRAmrnAKDiYn0NDECHIZVG17n9c5TqmybOSgCgkI5A
rgJCZb5eBgzq2cT8vGaQZm4=
=3UhT
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Loading...