On Aug 17, 2007 20:11 -0400, Kai Germaschewski wrote:> This may have been discussed before, but I didn''t quite find a
solution.
> On a SuSE 9.1 based system, with 2.6.18-vanilla and lustre 1.6.1 (but
> also with different versions), I get a segfault for
>
> # cp etc-ro/ypserver.conf /tmp
>
> where /etc-ro is on a lustre fs, and /tmp is tmpfs.
>
> strace reveals what I think the problem is:
>
> listxattr("etc-ro/ypserv.conf", (nil), 0) = 12
> listxattr("etc-ro/ypserv.conf", 0x7ffff79ea200, 12) = 12
> getxattr("etc-ro/ypserv.conf", "trusted.lov", (nil), 0)
= 56
> getxattr("etc-ro/ypserv.conf", "trusted.lov", 0x515af0,
56) = 56
> setxattr("/tmp/ypserv.conf", "trusted.lov", 0x515af0,
56, ) = -1
> EOPNOTSUPP (Operation not supported)
>
> cp tries to copy the EA, can''t create that on tmpfs and I guess
> doesn''t handle the error return gracefully but segfaults. Now that
> mostly looks like a cp bug, but I''m also wondering whether
internals
> of the fs (the "trusted.lov") should be exposed to a regular
> userspace application?
This is a bug in SLES9 and SLES10 that it tries to copy random EAs.
As you can see - the test would fail copying the EA even if Lustre
wasn''t involved, because tmpfs doesn''t support EAs.
Please file a bug with SuSE, and maybe they will get the point that
only user.* EAs (and maybe not even those) should be copied by default.
I can imagine cases where even copying user.* EAs would be bad (for
example a "last backup time" EA) which might imply that a newly-copied
file has actually been backed up, when it hasn''t been.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.