Developers of Sympa

[IKEDA Soji <address@concealed>]

David, sorry for disturbing your work.  My proposal can be
discussed later.


A few comment to memorize this issue:

On Tue, 23 Jul 2013 17:55:40 +0200
David Verdin <address@concealed> wrote:

> Hi Soji,
> 
> It's great you investigated this problem. We will need correct and 
> efficient lock badly if we want to share spools between several Sympa 
> instances on separate servers.
> 
> Le 23/07/13 17:43, IKEDA, Soji a écrit :
> > On Thu, 16 May 2013 10:23:41 +0900
> > I wrote:
> >> However, currently Lock::lock() locks _lock file_, not the file
> >> passed to Lock::new(). So lock files can not be removed as long as
> >> any processes are running.
> >>
> >> Is this behavior unnecessary, isn't it?
> > It is necessary, because "forward locking" (locking files even if it does 
> > not
> > exist, I don't know what to call it officially though) is required.
> >
> > flock(2) can not perform forward locking.  That seems why current 
> > behavior of
> > Sympa::Lock is --- locking lock files instead of target files themselves.
> It looks like you found the correct reason. i didnt' write this part of 
> the code so it remained a little bit obscure to me.
> >
> > File::NFSLock can perform forward locking.
> >
> > So I propose that File::NFSLock should be solely used and that flock(2) 
> > should
> > not be used anymore.
> that means that we should not even bother to know whether the spools, 
> for example, are on an NFS volume or not?
> is that does not cripple performances, I gladly approve this project. It 
> is worth a try anyway.
> >
> > I assume that File::NFSLock works on any Unix-like environments.  Is this
> > assumption true? (File::NFSLock uses "hardlink magic").
> Good question. It is hard to verufy but, if we consider that NFS is 
> widely supported and that hardlink magic is necessary to make it work, 
> we can asume that the module will be supported on most Unix-like OS.
> The question now is: what is "hardlink magic"? Do you mean: the 
> principle of hardlinks that allow a file to existe apparently at exactly 
> the same number of hardlinks that point to its memory location and, 
> subsequently, to disappear only when the last of these hardlink is 
> removed. If yes, I think this a very well known behaviour and works 
> probably everywhere. If it is another mechanism, then I's like to 
> understand what it is...

"Hardlink magic" (I named it) is, as I understood:
(1) There may be only one main lock file (i-node) by each target
  file;
(2) Each proccess or routine creates a hardlink to the file above
  so that add shared-lock to the target file, and unlink it to
  unlock target file;
(3) When the main lock file does not have hardlinks anymore,
  it is removed from filesystem by the kernel.

- Lock file will be removed by kernel automatically.
- As lock files may exist independent from target files, forward
  locking is possible.
- As hardlink is usual thing on Unix-like systems, it may work
  on environmets not limited to NFS.

Regards,

--- Soji

> Anyawy, we should investigate this. Right now Étienne and I are still 
> haed first in the merge so I don't think we'll be able to search a lot.
> 
> Cheers,
> 
> David
> >
> >
> > Regards,
> >
> > --- Soji
> >
> > -- 
> > A bug in Sympa? Quick! To the bug tracker! 
> > <https://sourcesup.renater.fr/tracker/?group_id=23>
> > RENATER logo
> > *David Verdin*
> > Infrastructure pour les Services Informatiques
> >
> > Tél : +33 2 23 23 69 71
> > Fax : +33 2 23 23 71 21
> >
> > www.renater.fr <http;//www.renater.fr>
> >     RENATER
> > 263 Avenue du Gal Leclerc
> > 35042 Rennes Cedex
> >
> >
> >


-- 
株式会社 コンバージョン  セキュリティ&OSSソリューション部   池田荘児
〒231-0004　神奈川県横浜市中区元浜町3-21-2 ヘリオス関内ビル7F
e-mail address@concealed  TEL 045-640-3550
http://www.conversion.co.jp/