rsync w/ fake-super -> crashes zfs
javocado
javocado at gmail.com
Fri Mar 14 23:57:02 UTC 2014
System specifics:
ZFS version 28
FreeBSD 8.3-RELEASE
We're seeing a repeatable outcome where a remote rsync command like:
rsync -axzHAXS --rsync-path="rsync --fake-super" --exclude '*/rsync.%stat'
backing up to our zfs filesystem (with 15M inodes) will lead to a panic
with output like:
Fatal trap 12: page fault while in kernel modecpuid = 4; apic id =
04fault virtual address = 0x160fault code = supervisor
read data, page not presentinstruction pointer =
0x20:0xffffffff80abb546stack pointer =
0x28:0xffffff976c62b910frame pointer =
0x28:0xffffff976c62b9d0code segment = base 0x0, limit
0xfffff, type 0x1b = DPL 0, pres 1, long 1,
def32 0, gran 1processor eflags = interrupt enabled, resume,
IOPL = 0current process = 7295 (rsync)[thread pid 7295 tid
101008 ]Stopped at zfs_freebsd_remove+0x426: movq
0x160(%rax),%rsi
On the sending side (RHEL, ext3), rsync reports errors like:
rsync: failed to read xattr rsync.%statrsync: failed to write xattr
rsync.%statrsync: get_xattr_names: llistxattr
which we've seen occasionally with other systems when running rsync
with fake-super, but it usually doesn't lead to a crash.*
On the receiving side, other than the crashes, we are seeing a few new
files (that don't exist on the source) named:
rsync.%stat
which correspond to and contain the owner and permission attributes
that should have been stored in the extattr's for the file or
directory. Not sure if they are a red herring, but they're usually not
something we see (perhaps that's related to the --exclude
'*/rsync.%stat' and rsync not being able to cleanup properly).
We are still testing to see if any options in the rsync command
(above) may be contributing to the crash, since fake-super in and of
itself runs fine under basic (rsync -av --rsync-path="rsync
--fake-super" /src /dst) circumstances. But we suspect that the
problem is related to fake-super and its reliance upon extattr's.
What we really need is a solution to the crashing - some way to make
ZFS stop choking on whatever --fake-super produces and/or how it's
interacting with extattr's on ZFS.
Thanks!
* we sometimes also see on the sending side w/ fake-super:
rsync: failed to write xattr rsync.%stat for "xxxxxx/file" : No such file
or directory (2)
when (1) the file exists, (2) it's a symlink
but that isn't happening in this instance. We only mention it here as
another oddity of fake-super + ZFS + extattr
More information about the freebsd-fs
mailing list