DragonFly bugs List (threaded) for 2009-04
Re: Still looking for reports of missed directory entries w/ HAMMER
Ok, here is what I've come up with so far:
* ls sometimes appears to not list some entries, but then they show up.
- The case where the effect is temporary, ls appears not to report
an error and there's somewhat of a question-mark as to why.
- The case where the effect is permanent, and ls reports errors for
some files, is a different issue related to crash recoery. I
will be making it possible to delete such files, but I want to
track down the temporary case first.
* zsh has a correction feature. For zsh the temporary issue appears as
a request to correct the name of a file, but then offer exactly
the same name as the correction. Peter Avalos hit this with e.g.
vi <somefilename> sometimes.
- Zsh does an access() call, which apparently fails, and then
reads the contents of the directory to come up with the proposed
correction... the directory appears to contain the correct
* cpdup. I have seen this temporary issue with cpdup from NFS to HAMMER.
- cpdup does not report an error if it creates a sub-directory as
part of the cpdup operation, but is then unable to stat or chown
it. This causes cpdup to incorrectly believe that the target
directory is in a different filesystem and it silently fails to
copy anything into it.
The bug is line 840 in /usr/bin/cpdup.c. I will commit a fix
right now so it reports the error.
- But when I check manually with ls the target directory DOES exist,
but cpdup failed to copy anything into it.
From this information it is my belief that this issue is due to a
cache effect when a file or directory is created or recently created.
The effect can cause lookups of the file or directory to fail, even
though the creation actually succeeded. When the cache effect goes
away the entry becomes visible on the media.
The directory appears to properly contain the entry, but it cannot be
stat()'d etc. But when the cache effect in the kernel self-corrects
(probably due to simply being discarded), the entry can be stat()'d
again. This is different from the permanent media issue reported by
So now I am trying to find a case where newly created or modified or
renamed files somehow get confused in the kernel cache. That's where
I am. No smoking gun yet but a lot of clues.