fcntl or flock support in fuse?

[Jeffrey 'jf' Lim]

sorry if this has been asked before, but I would like to just get a better
sense of the status for fcntl and flock. From a google search (going back as
far as June 2006!), there's talk of fcntl, but looking at the api (
http://sourceforge.net/apps/mediawiki/fuse/index.php?title=API), it seems
like both are not supported?

This bug report in the redhat bugzilla (
https://bugzilla.redhat.com/show_bug.cgi?id=440483) also seems to indicate
that there might be flock support, but i'm wondering if this is peculiar to
redhat, and not to the standard kernel.

thanks,
-jf

--
In the meantime, here is your PSA:
"It's so hard to write a graphics driver that open-sourcing it would not
help."
   -- Andrew Fear, Software Product Manager, NVIDIA Corporation
http://kerneltrap.org/node/7228
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Miklos Szeredi]

On Thu, 5 Nov 2009, Jeffrey 'jf' Lim wrote:
> sorry if this has been asked before, but I would like to just get a better
> sense of the status for fcntl and flock. From a google search (going back as
> far as June 2006!), there's talk of fcntl, but looking at the api (
> http://sourceforge.net/apps/mediawiki/fuse/index.php?title=API), it seems
> like both are not supported?

Both flock and fcntl/lockf should work by default on any fuse filesystem.

If the filesystem needs remote locking capabilities, then it need to
implement the locking functions.  In this case too, both flock and
fcntl types should work, the kernel even tells userspace which one.
Unfortunately the current API hasn't been extended with this info, so
from the filesystem the two types of locks are indistinguishable.

Thanks,
Miklos

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Jeffrey 'jf' Lim]

On Thu, Nov 5, 2009 at 10:10 PM, Miklos Szeredi <miklos@...> wrote:

> On Thu, 5 Nov 2009, Jeffrey 'jf' Lim wrote:
> > sorry if this has been asked before, but I would like to just get a
> better
> > sense of the status for fcntl and flock. From a google search (going back
> as
> > far as June 2006!), there's talk of fcntl, but looking at the api (
> > http://sourceforge.net/apps/mediawiki/fuse/index.php?title=API), it
> seems
> > like both are not supported?
>
> Both flock and fcntl/lockf should work by default on any fuse filesystem.
>
> If the filesystem needs remote locking capabilities, then it need to
> implement the locking functions.

sorry - could you explain this further? remote locking as in the filesystem
actually resides on another system, different from the system where it is
mounted? Or remote locking in the sense of it being a shared file system,
and therefore lock contention has to be taken care of between different
clients? I am personally interested to see if a shared file system might be
possible using fuse. This is my use case.



>  In this case too, both flock and
> fcntl types should work, the kernel even tells userspace which one.
> Unfortunately the current API hasn't been extended with this info, so
> from the filesystem the two types of locks are indistinguishable.
>
>
and the api call would be lock()?

-jf
--

In the meantime, here is your PSA:
"It's so hard to write a graphics driver that open-sourcing it would not
help."
   -- Andrew Fear, Software Product Manager, NVIDIA Corporation
http://kerneltrap.org/node/7228
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Miklos Szeredi]

On Thu, 5 Nov 2009, Jeffrey 'jf' Lim wrote:

> > Both flock and fcntl/lockf should work by default on any fuse filesystem.
> >
> > If the filesystem needs remote locking capabilities, then it need to
> > implement the locking functions.
>
>
> sorry - could you explain this further? remote locking as in the filesystem
> actually resides on another system, different from the system where it is
> mounted? Or remote locking in the sense of it being a shared file system,
> and therefore lock contention has to be taken care of between different
> clients?

Yes.  I use the term "remote" because that's the case where it most
often comes up.  On a single system you usually don't need any special
sharing.  What's your reason for having multiple filesystems connected
to a single backend?

> >  In this case too, both flock and
> > fcntl types should work, the kernel even tells userspace which one.
> > Unfortunately the current API hasn't been extended with this info, so
> > from the filesystem the two types of locks are indistinguishable.
> >
> >
> and the api call would be lock()?

Yes.

Thanks,
Miklos

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Jeffrey 'jf' Lim]

On Fri, Nov 6, 2009 at 5:17 PM, Miklos Szeredi <miklos@...> wrote:

> On Thu, 5 Nov 2009, Jeffrey 'jf' Lim wrote:
> > > Both flock and fcntl/lockf should work by default on any fuse
> filesystem.
> > >
> > > If the filesystem needs remote locking capabilities, then it need to
> > > implement the locking functions.
> >
> >
> > sorry - could you explain this further? remote locking as in the
> filesystem
> > actually resides on another system, different from the system where it is
> > mounted? Or remote locking in the sense of it being a shared file system,
> > and therefore lock contention has to be taken care of between different
> > clients?
>
> Yes.  I use the term "remote" because that's the case where it most
> often comes up.  On a single system you usually don't need any special
> sharing.  What's your reason for having multiple filesystems connected
> to a single backend?
>
>

My use case is for a shared file system between multiple web backends. The
shared file system would be used for cache files, session files, and the
like.


> >  In this case too, both flock and
> > > fcntl types should work, the kernel even tells userspace which one.
> > > Unfortunately the current API hasn't been extended with this info, so
> > > from the filesystem the two types of locks are indistinguishable.
> > >
> > >
> > and the api call would be lock()?
>
>
thanks.

-jf

--
In the meantime, here is your PSA:
"It's so hard to write a graphics driver that open-sourcing it would not
help."
   -- Andrew Fear, Software Product Manager, NVIDIA Corporation
http://kerneltrap.org/node/7228
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel