From kasperdanielhansen at gmail.com  Tue Jun  1 14:52:05 2010
From: kasperdanielhansen at gmail.com (Kasper Daniel Hansen)
Date: Tue, 1 Jun 2010 08:52:05 -0400
Subject: [Rd] 00LOCK and nfs
In-Reply-To: <AANLkTikhZwblSL_MyLTmqbsD5R61vhDa0l-o9lcw0caT@mail.gmail.com>
References: <s2le780c0971004260815we5156859v293d5b3a6ffd9890@mail.gmail.com>
	<l2kc0177e5a1004261054k3775628fyb6c1fd154707dd91@mail.gmail.com>
	<y2le780c0971004261205i39f069dt379690211f8f8a7f@mail.gmail.com>
	<4BD6F661.10409@acm.org>
	<AANLkTikhZwblSL_MyLTmqbsD5R61vhDa0l-o9lcw0caT@mail.gmail.com>
Message-ID: <AANLkTikE8kSXLI_dS3hGBFUlVk8A0f0gNULzZ9ZVitZk@mail.gmail.com>

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.

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
>



[Rd] 00LOCK and nfs
Kasper Daniel Hansen