[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fuse-devel
Subject:    Re: [fuse-devel] [2.8.x] ulockmgr_server issue / fusexmp_fh example
From:       Stef Bon <stefbon () gmail ! com>
Date:       2011-07-06 11:20:29
Message-ID: CANXojcxQUfx7c_mgQTWxz3bF+pyKE7OQKuL-WG0yu-wcnYU3HQ () mail ! gmail ! com
[Download RAW message or body]

2011/7/4 Miklos Szeredi <miklos@szeredi.hu>:
> Will fix these issues.
>
>> I also hope on answers to these closely-related questions:
>>
>>  - Why does plain
>>
>>      return fcntl(fi->fh, cmd, lock);
>>
>>    not suffice?
>
> POSIX locks are owned by the calling process.  If the filesystem process
> just calls fcntl() then it will become the owner of all locks.  That
> means F_SETLK will never block, just overwrite the previous state of the
> lock.

Hi,

I do not understand this. You say here that when the filesystem self
does the locking,
they are overwritten. Is it because you don't WANT your fs to block?
Why the "thus" the  "just overwrite the previous state".

Can you please explain the logic here?

Stef Bon
>
>>
>>  - What is the purpose of uluckmgr_server?
>
> ulockmgr_server basically starts a separate process for each lock owner
> and calls fcntl from that child process.
>
>>
>>  - What is that big number in lock_owner used for?
>>    How would an implementation not using ulockmgr_op
>>    have to deal with it in general?
>
> In most cases there's a 1:1 relationship between lock_owner and l_pid.
> The reason they don't correspond exactly is because Linux has clone() a
> very flexible fork()-like system call.  With clone(2) you can specify
> what the new task wants to share with the old.  CLONE_FILES flag will
> cause the new task to share file descriptor table with the old, which in
> turn determines lock ownership.  CLONE_THREAD flag will cause sharing of
> the PID value.  They can be specified independently though standard
> calls such as fork() and pthread_create() specify/omit them together.
>>
>>  - I have seen several processes of ulockmgr_server running
>>    in parallel.  Is ulockmgr_server meant to run multiple times?
>
> Yes, see above.
>
>
>>  - Is there a way to run fcntl(2) under the process ID of
>>    the process querying the file system?
>
> No, not without some additional kernel support to allow passing l_pid
> and lock_owner to F_SETLK.
>
>>   Currently either
>>    the FUSE file system or ulockmgr_server seem to become
>>    owner of the lock, instead.
>
> Yep, ulockmgr_server should be the owner.
>
> Thanks,
> Miklos
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> fuse-devel mailing list
> fuse-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fuse-devel
>

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
fuse-devel mailing list
fuse-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[prev in list] [next in list] [prev in thread] [next in thread]