ChironFS 1.0RC7 Available for download
Vuco
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 in
experimental status. 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.0RC7 are:
* Fixed bug #6 where files created by another user than the user
that mounted ChironFS were owned by the mounting user and not the
creator itself. See details below. Thanks to Neal Becker who reported
the bug.
* Implemented an experimental fix for a bug reported by Oleg
Bartunov by e-mail, where ChironFS fails to exclude all files when
doing massive delete ("rm -Rf" on directories with thousands of
files). See details below. Thanks to Oleg Bartunov for reporting the
bug.
* Implemented a priorization system, modifying the simple round-
robin that made the load balance on read operations. Now when we have
replicas with a too different response time (tipically a local/LAN
replica and a remote WAN replica) the system focus the load balance
only in the fast replicas. See details below. Thanks to Maxime Ritter
who gave the idea of configuring the priority in the command line.
Changes
Since ChironFS 1.0RC6
* Fixed bug #6 where files created by another user than the user
that mounted ChironFS were owned by the mounting user and not the
creator itself. It was a serious security problem. ChironFS was not
tracking the creation of the files and, this way, was not changing the
ownership of the created file/directory to the uid and gid of the
calling process. Now ChironFS calls fuse_context to get that info from
the calling process and changes to it right after the creation. Thanks
to Neal Becker who reported the bug.
* Implemented an experimental fix for a bug reported by Oleg
Bartunov by e-mail, where ChironFS fails to exclude all files when
doing massive delete ("rm -Rf" on directories with thousands of
files). It happens when a cycle of opendir/readdir/closedir cannot be
done in only one call due to lack of space in the readdir buffer and
subsequent calls were lacking of synchronization because the system
flushed the deletes and updated the directory list. I started to call
seekdir using the offset parameter of the readdir. This parameter were
being ignored until now as in the example programs of fuse
implementations. Now my tests are succesfull. But, Franco Broi
reported at the fuse-devel mailing list that a filesystem he is
implementing got the same bug. I told him about my fix and he tested
with his filesystem and it did NOT work for him. Miklos Szeredi, the
author of fuse proposed another fix and it worked for Franco Broi. But
when I implemented it in ChironFS, it made my system crash. Franco
Broi told me that his filesystem runs on top of NFS. I did not tested
ChironFS over NFS, but my fix worked on top of SSHFS. So, I will keep
my fix, but in experimental status. Thanks to Oleg Bartunov for
reporting the bug.
* Complete rewrite of the debug function. The old ones were a
confusing mess. Now there is only one, accepting variable parameters.
Thanks to Graham Toal, author of dupfs, from whose code I learnt the
techniques to do it.
* Fixed a bug when ChironFS is called with --log option and the
logfile pathname is relative and the file itself doesn't exists. In
this case, ChironFS was exiting with the "file not found" error. The
problem is that when realpath is called with a non-existant path it
returns NULL. So I had to get its basedir, call realpath and only
then, re-append the basename to it. Thanks to Graham Toal who reported
this bug.
* Implemented a priorization system, modifying the simple round-
robin that made the load balance on read operations. Now when we have
replicas with a too different response time (tipically a local/LAN
replica and a remote WAN replica) the system focus the load balance
only in the fast replicas. The slow replicas are accessed in read
operations only when the fast ones fails. To enable this, the user
MUST tell ChironFS which are the slower replicas by prefixing the
pathnames with a colon in the command line, for example: "chironfs /
real1=:/real2=/real3=/real4=:/real5 /virtual". In this example,
ChironFS will give priority to the /real1, /real3 and /real4 and
choosing a replica to read using a round-robin load balance algorithm.
ChironFS will read from /real2 and /real5 replicas only if /real1, /
real3 and /real4 fail and in this case, will choose between /real2
and /real5 unsing the same round-robin algorithm. Of course most of
its usage will be something like "chironfs /real1=:/real2 /virtual",
but the example was intended to show more details on how ChironFS will
handle these situations. Thanks to Maxime Ritter who gave the idea of
configuring the priority in the command line.
* Fixed one more memory leak: I was freeing all paths[i].path
allocations, but I forgot to free the paths structure itself.