Date: Thu, 20 Mar 2014 17:33:34 -0700 From: javocado <javocado@gmail.com> To: FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: Re: rsync w/ fake-super -> crashes zfs Message-ID: <CAP1HOmRfw0_MkHhu%2BWYu4vac25rx2MGzUAGjdbM8PkPRm5LxtQ@mail.gmail.com> In-Reply-To: <CAP1HOmTiiKp7B1FLQ=Kfq_WUe2=nctMTc0nrtiav5kfAraVHgA@mail.gmail.com> References: <CAP1HOmTiiKp7B1FLQ=Kfq_WUe2=nctMTc0nrtiav5kfAraVHgA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Gathering more info here...
When re-running the rsync command, stripped down:
rsync -av --rsync-path=3D"rsync --fake-super" /src /dst
we're not seeing any system crashes, yet, but rsync is choking/quitting
quite a bit saying a file here or there has a corrupt extattr. Does this
point to a problem with ZFS or more with rsync.
Any thoughts on the fake-super impact and how it leads to crashing?
On Fri, Mar 14, 2014 at 4:57 PM, javocado <javocado@gmail.com> wrote:
> 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=3D"rsync --fake-super" --exclude '*/rsync.%st=
at'
>
> 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 =3D 4; apic id =3D 04=
fault virtual address =3D 0x160fault code =3D supervisor rea=
d data, page not presentinstruction pointer =3D 0x20:0xffffffff80abb546=
stack pointer =3D 0x28:0xffffff976c62b910frame pointer =
=3D 0x28:0xffffff976c62b9d0code segment =3D base 0x0, limit 0xff=
fff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, g=
ran 1processor eflags =3D interrupt enabled, resume, IOPL =3D 0curre=
nt process =3D 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 fi=
les (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 sur=
e if they are a red herring, but they're usually not something we see (perh=
aps that's related to the --exclude '*/rsync.%stat' and rsync not being abl=
e to cleanup properly).
>
> We are still testing to see if any options in the rsync command (above) m=
ay be contributing to the crash, since fake-super in and of itself runs fin=
e under basic (rsync -av --rsync-path=3D"rsync --fake-super" /src /dst) cir=
cumstances. But we suspect that the problem is related to fake-super and it=
s 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
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAP1HOmRfw0_MkHhu%2BWYu4vac25rx2MGzUAGjdbM8PkPRm5LxtQ>