From kasperdanielhansen at gmail.com  Mon Jun 14 16:34:34 2010
From: kasperdanielhansen at gmail.com (Kasper Daniel Hansen)
Date: Mon, 14 Jun 2010 10:34:34 -0400
Subject: [Rd] 00LOCK and nfs
In-Reply-To: <alpine.LFD.2.00.1006091222350.18833@gannet.stats.ox.ac.uk>
References: <s2le780c0971004260815we5156859v293d5b3a6ffd9890@mail.gmail.com>
	<l2kc0177e5a1004261054k3775628fyb6c1fd154707dd91@mail.gmail.com>
	<y2le780c0971004261205i39f069dt379690211f8f8a7f@mail.gmail.com>
	<4BD6F661.10409@acm.org>
	<AANLkTikhZwblSL_MyLTmqbsD5R61vhDa0l-o9lcw0caT@mail.gmail.com>
	<AANLkTikE8kSXLI_dS3hGBFUlVk8A0f0gNULzZ9ZVitZk@mail.gmail.com>
	<alpine.LFD.2.00.1006091222350.18833@gannet.stats.ox.ac.uk>
Message-ID: <AANLkTikupwbBPMIZbbkVldNU6vAWspKnoJnQ-I8Nx8Px@mail.gmail.com>

Thank you very much for including this additional capability.

Our cluster is still running NFS 3 and I doubt I will be able to get
the file system upgraded.  It is nice to know that the problem is
mostly solved under NFS 4.

Kasper

On Thu, Jun 10, 2010 at 7:54 AM, Prof Brian Ripley
<ripley at stats.ox.ac.uk> wrote:
> Note that this patch is incomplete: there are three separate branches in
> install.packages() where R CMD INSTALL is used, and one already uses
> --pkglock. ?(So a short-term solution for you is to set Ncpus > 1.)
>
> However, I think this request has been subsumed by a more general need to be
> able to pass options to INSTALL, and R-devel now has an INSTALL_opts
> argument to install.packages(). ?So I believe you could just use
> install.packages( ... , INSTALL_opts = "--pkglock") .
>
> On Tue, 1 Jun 2010, Kasper Daniel Hansen wrote:
>
>> Further experimentation using this patch to install.packages shows
>> that I sometimes have remaining 00LOCK-pkgname directories after doing
>> a massive update on a multi-user system with R installed on NFS.
>> However, I have never had install.packages/update.packages stop midway
>> because of an unremovable 00LOCK directory. ?I therefore consider the
>> patch to be big improvement for people like me, having a multi-user R
>> installed on NFS. ?Private followups to my original email shows that I
>> am not the only one with this problem.
>
> But I should point out that others with well-tuned NFS do not have the
> problem -- my sysadmins say that it was common with NFSv3 but they've hardly
> seen it with NFSv4.
>
>
>> I would very much like the patch (or some variant hereof) to be
>> considered for inclusion in R-devel.
>>
>> Kasper
>>
>> On Tue, May 18, 2010 at 11:59 AM, Kasper Daniel Hansen
>> <kasperdanielhansen at gmail.com> wrote:
>>>
>>> This is a follow-up to an old thread with kind of solution to the
>>> 00LOCK problem on NFS.
>>>
>>> I have made a patch to install.packages to accept a new argument
>>> ?locktype = c("lock", "no-lock", "pkglock")
>>> which is passed to R CMD INSTALL. ?This addition might have
>>> independent interest aside from the NFS problem, as it exposes
>>> functionality from R CMD INSTALL to install.packages and the very
>>> convenient update.packages. ?Patches are at
>>> ?http://www.biostat.jhsph.edu/~khansen/packages2.R-patch
>>> ?http://www.biostat.jhsph.edu/~khansen/install.packages.Rd-patch
>>> (patches to files in the utils package) and both
>>> ?R-devel (R version 2.12.0 Under development (unstable) (2010-05-17
>>> r52025))
>>> and
>>> ?R-2.11 (R version 2.11.0 Patched (2010-05-17 r52025))
>>> passed make check-all with these two patches applied. ?I thought about
>>> adding a note describing my findings below to the details section, but
>>> decided against it.
>>>
>>> Regarding the 00LOCK problem. ?In my testing, using the patches above
>>> and setting locktype = "pkglock", makes it possible to deal with the
>>> NFS problem. ?Specifically, I have not been able to make
>>> update.packages() fail midway, due to a un-removable 00LOCK file
>>> (which is not too surprising, as I now have a per-package lock).
>>>
>>> However, sometimes (but far less frequently than before), a
>>> 00LOCK-pkgname directory remains after update/install.packages.
>>> Sometimes this 00LOCK-pkgname directory does not contain any .nfs*
>>> files (!?) and sometimes it does. For this reason, I still precede any
>>> install/update.packages with a check for the existence of a
>>> 00LOCK-pkgname directory and an attempt to remove it.
>>>
>>> The difference between using locktype = "pkglock" and not is
>>> specifically that without, it was possible for update.packages to fail
>>> midway even though there were no 00LOCK* files at the start of the
>>> update process.
>>>
>>> Originally I hypothesized that the presence of the .nfs* files in the
>>> 00LOCK directory had to do with synchronization issues between the
>>> file server and the compute node. ?In order to approach this I tried
>>> to insert a
>>> ?system("sleep 10")
>>> at the beginning of
>>> ?do_cleanup
>>> in
>>> ?tools/R/install.R
>>> but that did not work.
>>>
>>> Since the pkglock approach described above seems to solve this issue
>>> for me, I have not pursued the synchronization issue further.
>>>
>>> Kasper
>>>
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Brian D. Ripley, ? ? ? ? ? ? ? ? ?ripley at stats.ox.ac.uk
> Professor of Applied Statistics, ?http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, ? ? ? ? ? ? Tel: ?+44 1865 272861 (self)
> 1 South Parks Road, ? ? ? ? ? ? ? ? ? ? +44 1865 272866 (PA)
> Oxford OX1 3TG, UK ? ? ? ? ? ? ? ?Fax: ?+44 1865 272595



[Rd] 00LOCK and nfs
Kasper Daniel Hansen