Hi!
A. SUMMARY
Long story short: I have a file name on my zfs without a file to it. ls
will include it in the dir content, but stat-ing that file will result
in an ENOENT error: No such file or directory.
B. HISTORY
So how did I come to this situation? I've recently had to kill the
sending side of an rsync, with the receiving side on FreeBSD. For
reasons yet unknown, the next run of rsync started deleting stuff it
shouldn't. Details on this are in PR 162318 [1], but quoting the most
important things:
Logging into the receiving FreeBSD as root, I found that large parts of
the user's home directory content had disappeared, even outside the
subdirectory used as the rsync destination!
- All the .* config files in the home directory were gone
- The .ssh directory was still present, but its content was gone as well
- Both the home dir and the .ssh subdir contained a file rsync.%stat,
which should be the name of an extattr instead, used to implement the
rsync --fake-super command line option.
[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=162318
C. SYMPTOMS
I first assumed a problem in the binary rsync build for FreeBSD, but
devs on the above bug report favored RAM failure or an upstream source
code bug. So I gave it another try, and payed closer attention to the
error messages. Among them was the following:
rsync: stat /home/name/backup/etc/ca-certificates failed: No such file or
directory (2)
Strange thing is, this isn't specific to rsync at all, it can be
reproduced using simple command line tools like ls:
# ls /home/name/backup/etc/ | grep ca-cert
ca-certificates
ca-certificates.conf
ca-certificates.conf~
# ls /home/name/backup/etc/ca-*
ls: /home/name/backup/etc/ca-certificates: No such file or directory
/home/name/backup/etc/ca-certificates.conf
/home/name/backup/etc/ca-certificates.conf~
So as you see, the name is returned by readdir(3), where both ls for the
dir and the wildcard expansion find it. But anything that stat(2)s the
file will encounter an ENOENT error. zpool status says everything's
fine, so zfs isn't aware of any corruption.
I believe that no matter what errors user space programs might make, the
kernel zfs driver should never allow the above to happen. Either a file
is there, or it isn't, there should be no such mixture. So what do you
think, is this likely to be a bug in the zfs implementation?
I found one other person describing problems like this: in threads
titled file lose inode in Memory-Based file system., lisen1001
described pretty much the same thing, except on ramdisk on 8.2 instead
of my own hdd-based raidz on 9.0-RC1 [2,3].
[2] http://thread.gmane.org/gmane.os.freebsd.questions/280183
[3] http://thread.gmane.org/gmane.os.freebsd.devel.file-systems/13153
D. NEXT STEPS
As I'm new to FreeBSD, I'm not yet sure how bug reports are handled
around here. As I said, I've reported a bug report against rsync, and it
has been closed on the grounds that this appears to be an upstream
problem. Would it make sense to include the above information in the bug
report for reference? Would replying to the gnats address be enough to
accomplish that? Should the bug be reopened, as I assume all my problems
to be related, and as the zfs corruption at least is specific to
FreeBSD? If so, how does one reopen a report? Or who can do that?
Do you agree that this looks like a problem in the ZFS implementation?
Should I file a new problem report for that?
Can you suggest any way I could resolve the corruption on my local ZFS
pool, short of destroying and recreating the whole file system? rm for
the file doesn't work, as it, too, encounters the ENOENT. Is there any
tool to check or rebuild the inode data structures of zfs? zpool scrub
doesn't seem to fit the bill, as its manpage indicates a computation of
file content checksums.
Greetings,
Martin von Gagern
signature.asc
Description: OpenPGP digital signature
