Re: [Gnu-arch-users] patch: automatic remove the corrupt revlib revision, second try

[Stephen J. Turnbull]

>>>>> "Matthew" == Matthew Hannigan <address@hidden> writes:

    Matthew> I agree in general, but if a revlib is on a fs without
    Matthew> stable inodes, the user will get this every time, and tla
    Matthew> will be extremely slow.

    Matthew> The slowness is a motivation to fix it,

Derek's patch indicates that in practice it is not.  He prefers (or is
forced to) automating the slowness rather than fixing it.

    Matthew> and the warning is a hint to the problem.

    Matthew> So it's not just a 'useless annoyance'.

Valid point.  I'd handle this in the user manual and the FAQ rather
than with a runtime warning, though.

    Matthew> I'm not saying I'm completely in favour of it, a real fix
    Matthew> might be to use a different implementation for revlibs --
    Matthew> other than fs.

Over the last three or four years, Tom has several times explained why
he chose conventional file systems to implement archives and revlibs.
It wasn't just that it was an available tool.  It was also a tool
well-tuned to the job, both time- and space-efficient.  I'm not going
to rehearse those arguments here.

Changing that architecture has serious costs of code instability and
core developer distraction.  Why should the people currently getting
excellent performance, both in space and time, from a well-tuned
conventional-fs-based implementation pay so that people (or their
employers) who insist on _exclusively_ using file systems with
_generally_ sucky semantics can work around the sucky semantics they
chose deliberately?

Note that the motivation for the patch was not just that Derek's using
NFS, which is obviously useful for many purposes.  It's that policy or
preference _also_ says that when a local filesystem is the right tool
for the job, he _can't_ use it!  Those are serious and non-trivial
constraints, and they will apply to your as yet unspecified non-fs
solution.  You need a database that emulates local fs semantics that
works on NFS, or you need to convince Derek's employer to run the
database we choose for the revlib, or you need to support all the
databases that Derek's employer might be willing to run, or you need
to change the revlib API to deal with non-local-fs semantics.

revc is probably the answer you're looking for.  But that's a pretty
dramatic jump, especially considering that it's many months into the
future.  :-)


-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.