Issue 2 in chironfs: [1.0RC2] "getattr failed accessing" in log, wrong permission on new dirs
codesite...@google.com
http://code.google.com/p/chironfs/issues/detail?id=2
New issue report by mkotas:
Now, I have run a following command:
chironfs --fuseoptions allow_other --log $HOME/tmp/chironfs.log
$TESTDIR/real1=$TESTDIR/real2 $TESTDIR/virtual
and I get following errors in the log, after adding any file to the
"virtual" directory:
2007/08/28 12:49 /home/test/tmp/real1
2007/08/28 12:49 getattr failed accessing /home/test/tmp/real2
I must admit the newly created files are correctly propagated into the
real1 and real2 dirs, however new subdirectories are created with
drw-r--r-- ( in all three dirs) which makes them inaccesible.
Issue attributes:
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
codesite...@google.com
http://code.google.com/p/chironfs/issues/detail?id=2
Comment #1 by luisfurquim:
Problem reproduced. Starting the debug.
Issue attribute updates:
Status: Started
codesite...@google.com
http://code.google.com/p/chironfs/issues/detail?id=2
Comment #2 by luisfurquim:
Bug fixed. Actually, this was not A bug, but TWO bugs!
* The first bug was the incorrect permissions on directory creation.
This only happened when using a log file (--log option), this was
a side effect from the fix of the first reported bug, by Jason Haar,
where the log file was being created world writable. To fix that
bug, I had to change the umask and doing so, I created this bug.
The fix was saving the original umask and then restoring after
opening the log file.
* The second bug brings some filosofical considerations. We have
to keep the systems running even when some failure happens, this
is the reason of the existence of Chiron FS. But we have to
report failures in a replica to fix them before more replicas
fail. When we perform write operations the idea is that we must
prevent system inconsistency/data corruption. This state happens
when we succeed writing in at least one replica and fail in at
least one replica. When this situation occurs, we report the
failure AND disable the failed replica(s). So no other operations
are made in the disabled replicas. But when we perform read
operations, the system tries to load balance the resources. So,
generally, the read operation is made from just one replica. But
read operations may fail too. Them ChironFS tries to read from
another replica. Read operations does not lead to inconsistent
states, so no replica is disabled in a failure, but, as a bonus,
ChironFS was reporting every read failure. The strange thing was
that ALL replicas were failing when the user tried to create a
directory. Despite that, the creation of the directory was
successfull!?!? The fact is: the failure was part of the
operation. More then it: the failure was needed for the success
of the operation. Actually, the failure was a "file not found"
error. Before creating the directory, the system TESTS if the
directory already existed and ONLY CREATES this if the system
returns the error! ;-)
So, I changed all the read algorithms. Now, read failures are
reported ONLY when we get some failures and some success, just
as we do when we perform write operations. But we still try to
load balance the reads and we don't disable any replicas here.
Issue attribute updates:
Status: Fixed
Owner: luisfurquim