[merge] errors in deleting obsolete packs should not be fatal (was Re: Problems with NFS mounted filestore)

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Russel Winder wrote:
| Martin,
|
| On Mon, 2008-05-26 at 13:40 +1000, Martin Pool wrote:
|> On Sun, May 25, 2008 at 6:57 PM, Russel Winder
|>
|>> However, the branch consistently fails to work when run on a machine
|>> which mounts the filestore over NFS.  I have just undertaken the branch
|>> on the fileserver itself and that is fine.  I don't know if this is a
|>> bzr or bzr-svn thing, nor whether it is a known issue, i.e. should I
|>> report a bug?
|> Thanks for the report.  This is a new bug.
|
| OK.  Is this something relatively new, 1.5-ish -- I am fairly sure I
| have not had this problem before
|
|> Could you please try merging this patch?
|
| Currently I am using the latest released distributions of things --
| bleeding edge but not entirely amenable to simple patching.  If someone
| could induct me into the correct and proper way of working with a live
| development branch, I am certainly willing to give it a go.
|
| I am assuming that keeping a mirror of the current development master,
| then branching it and applying the patch will be involved (is a shared
| repository best for this sort of thing?).  The question is how to use
| Bazaar direct from the branch rather than installing it.

Bazaar itself can be run from source without much difficulty. It should be as
simple as running 'make' and then symlinking 'bzr' to something like ~/bin/bzr.

I would recommend a shared repository, in case you end up with more than one
branch of bzr, but if you don't expect that, there is no difference.

bzr init-repo bzr
cd bzr
bzr co http://bazaar-vcs.org/bzr/bzr.dev
cd bzr.dev
make
cd ~/bin
ln -s ~/bzr/bzr.dev/bzr

You can apply Martin's patch with:

~  bzr merge ../martins_changes.patch

Or you can wait a day or two when we've approved his patch and it is in bzr.dev.

|
|> The .nfs* files are NFS internal housekeeping for files that have been
|> deleted by one client but that are still in use by another.  More
|> generally, if we fail to delete one of these leftover files it
|> shouldn't be considered a fatal error.  I think if the client(?)
|> abruptly disconnects they can be left behind for a long time.
|
| I would guess that bzr is actually multi-threading and that one thread
| is deleting the file before another thread has released it.  Certainly
| the only way that the .nfs files get created is when the file is opened
| by a process when another process deletes it.  However bzr is the only
| process at work in that directory at that time so it must be an internal
| bzr thing.

bzr is quite single-threaded. Also, these files are generally renamed from
.bzr/repository/packs => .bzr/repository/obsolete-packs. If the files were open
at the time, the rename would fail on windows.

And we only rename the stuff that we've determined to be copied into a new file,
so they should have all been closed, etc. It is *possible* that a second process
has opened those files, but it should be close to impossible for the 'bzr'
process itself to still hold them.
|
|> Arguably we should just specifically ignore all .nfs* files.
|
| But it might be worth considering why bzr is creating these things in
| the first place.  It indicates there might be resource claim/release
| problems that have arisen in either 1.4 or 1.5.
|
| RAII is your friend :-)
|

RAII is a great model, but it unfortunately doesn't work well in python, or most
auto-GC languages. Because you can't guarantee when your object will get garbage
collected, especially if it ends up involved in a reference cycle.

Python has a 'try/finally' semantic which works just as well inside a function.
(It doesn't do quite as well when you might be handing the resource out to
different places, which may decide that you no longer need it, etc)


John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkg6tFMACgkQJdeBCYSNAAMFuQCguMAUnAyliYKJ3/AAFIBIBsmQ
seMAoKFIJmZqTf1oRK5V2uoy3JQSKooN
=AAAY
-----END PGP SIGNATURE-----