ChironFS 1.0RC8 Available for download

[Vuco]

=================================
Release Notes for ChironFS 1.0RC8
October 4, 2007
=================================

This is the eighth release candidate of the Chiron FS code
base. There is one known bug right now. It is the bug related
with massive delete described below. There is a fix for it,
but it is still in experimental status. Until now, no one has
reported failures related to this bug. If you find any bugs,
please report them asap, with as many details as you can:
what you were doing, what you have installed in the system,
the command line you invoked ChironFS, your current directory,
etc.

Major bug fixes included in ChironFS 1.0RC8 are:

o Fixed a bug reported by email by Graham Toal where the hash
address of
the file descriptor table could be a negative number. The hash
table
function was changed to the Robert Jenkins' 32 bit integer hash
function
as found in the Twang's doc at http://www.concentric.net/~Ttwang/tech/inthash.htm
just adapted to the C language. The 64 bit mix function was taken
from
there too. The size of the hash table was changed too it was a
waste of memory
allocating a table of file-max size because file-max is a system
wide parameter
and if all the file-system would be ChironFSed and with a minimal
of two replicas
we would need only 33% of the table space. Since the new hash
functions are much
better distributed and are good enough until 80% of the space
used, then I
decided to use a file-max proportional allocation, using the
maximum power of 2
less than 50% of file-max. The stats showed a low collision rate
for 50% of table
usage (about 18% of file-max in my box, which means that, using
two replicas,
I was using 54% of the system file descriptors). I drew an
allocation graphic
which can be seen in the howto at http://www.furquim.org/chironfs/howto.html#stats
o Fixed an issue when the ulimit were lower than the projected hash
table size, just
raising the ulimit value, but it only works if the mounting user
is root, otherwise
the ulimit must be raised through manual configuration of /etc/
security/limits.conf.

######################################################################
Changes
#######

Changes since ChironFS 1.0RC7
---------------------

o Fixed a bug reported by email by Patrick Chevalier, where ChironFS
was giving wrong error message when the mount point path did not
existed. Thanks to him for the report.
o Fixed issue #7 reported at http://code.google.com/p/chironfs/issues/detail?id=7
where ChironFS wasn't being specific in the error message. Thanks
to
Alexandre Fernandes for reporting it.
o Fixed a bug reported by email by Graham Toal where the hash
address of
the file descriptor table could be a negative number. The hash
table
function was changed to the Robert Jenkins' 32 bit integer hash
function
as found in the Twang's doc at http://www.concentric.net/~Ttwang/tech/inthash.htm
just adapted to the C language. The 64 bit mix function was taken
from
there too. The size of the hash table was changed too it was a
waste of memory
allocating a table of file-max size because file-max is a system
wide parameter
and if all the file-system would be ChironFSed and with a minimal
of two replicas
we would need only 33% of the table space. Since the new hash
functions are much
better distributed and are good enough until 80% of the space
used, then I
decided to use a file-max proportional allocation, using the
maximum power of 2
less than 50% of file-max. The stats showed a low collision rate
for 50% of table
usage (about 18% of file-max in my box, which means that, using
two replicas,
I was using 54% of the system file descriptors). I drew an
allocation graphic
which can be seen in the howto at http://www.furquim.org/chironfs/howto.html#stats
o Fixed a bug where a chunk of memory was being freed two times (and
crashing
ChironFS, but it was going exit anyway) when some replica path
didn't existed
at mount time.
o Fixed an issue when the ulimit were lower than the projected hash
table size, just
raising the ulimit value, but it only works if the mounting user
is root, otherwise
the ulimit must be raised through manual configuration of /etc/
security/limits.conf.
o Updated the howto with hash, file descriptor and ulimit
considerations; packages
other than the tarball installations and how to lower the read
priority of known
slower replicas.