From kasperdanielhansen at gmail.com  Tue May 18 17:59:38 2010
From: kasperdanielhansen at gmail.com (Kasper Daniel Hansen)
Date: Tue, 18 May 2010 11:59:38 -0400
Subject: [Rd] 00LOCK and nfs
In-Reply-To: <4BD6F661.10409@acm.org>
References: <s2le780c0971004260815we5156859v293d5b3a6ffd9890@mail.gmail.com>
	<l2kc0177e5a1004261054k3775628fyb6c1fd154707dd91@mail.gmail.com>
	<y2le780c0971004261205i39f069dt379690211f8f8a7f@mail.gmail.com>
	<4BD6F661.10409@acm.org>
Message-ID: <AANLkTikhZwblSL_MyLTmqbsD5R61vhDa0l-o9lcw0caT@mail.gmail.com>

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