Date: Sun, 6 Mar 2011 07:37:45 -0800 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Steve Wills <swills@FreeBSD.org> Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Edward Tomasz Napiera?a <trasz@FreeBSD.org> Subject: Re: ACL issue (Was Re: HEADS UP: ZFSv28 is in!) Message-ID: <20110306153745.GA93530@icarus.home.lan> In-Reply-To: <4D739D96.5090705@FreeBSD.org> References: <20110227202957.GD1992@garage.freebsd.pl> <4D73098F.3000807@FreeBSD.org> <59D664AA-76C6-45C7-94CE-5AA63080368C@FreeBSD.org> <4D738DB0.1090603@FreeBSD.org> <4D739D96.5090705@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 06, 2011 at 09:43:34AM -0500, Steve Wills wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> On 03/06/11 08:35, Steve Wills wrote:
> > On 03/06/11 04:22, Edward Tomasz NapieraBa wrote:
> >> Wiadomo[=07 napisana przez Steve Wills w dniu 2011-03-06, o godz. 05:1=
1:
> >=20
> >> [..]
> >=20
> >>> Thanks for your work on this, I'm very happy to have ZFS v28. I just
> >>> updated my -CURRENT system from a snapshot from about a month ago to
> >>> code from today. I have 3 pools and one of them is for ports tinderbo=
x.
> >>> I only upgraded that pool. When I try to build something using
> >>> tinderbox, I get this error:
> >>>
> >>> cp: failed to set acl entries for
> >>> /usr/local/tinderbox/9-CURRENT-amd64-FreeBSD/buildscript: Operation n=
ot
> >>> supported
> >=20
> >> What does "mount" show?
> >=20
> > /dev/md4 12186190 332724 11853466 3%
> > /usr/local/tinderbox/9-CURRENT-amd64-FreeBSD
> >=20
> > Sorry, I forgot about the mdmfs hacks I had in my local tinderd. Without
> > them, it works fine. So the problem seems to be in mfs rather than zfs.
>=20
> I should have said mdmfs, but all that's doing is running mdconfig and
> newfs for me. I've reproduced the issue without mdmfs:
>=20
> % mdconfig -a -t swap -s 12G -u 4
> % newfs -m 0 -o time /dev/md4
> [...]
> % mount /dev/md4 /tmp/foobar
> % cp -p /usr/local/tinderbox/scripts/lib/buildscript /tmp/foobar
> cp: failed to set acl entries for /tmp/foobar/buildscript: Operation not
> supported
>=20
> Without -p it works fine. FWIW:
>=20
> % getfacl /usr/local/tinderbox/scripts/lib/buildscript
> # file: /usr/local/tinderbox/scripts/lib/buildscript
> # owner: root
> # group: wheel
> owner@:--------------:------:deny
> owner@:rwxp---A-W-Co-:------:allow
> group@:-w-p----------:------:deny
> group@:r-x-----------:------:allow
> everyone@:-w-p---A-W-Co-:------:deny
> everyone@:r-x---a-R-c--s:------:allow
>=20
> Any suggestions on where the problem could be?
At first glance it looks like acl_set_fd_np(3) isn't working on an
md-backed filesystem; specifically, it's returning EOPNOTSUPP. You
should be able to reproduce the problem by doing a setfacl on something
in /tmp/foobar.
Looking through src/bin/cp/utils.c, this is the code:
420 if (acl_set_fd_np(dest_fd, acl, acl_type) < 0) {
421 warn("failed to set acl entries for %s", to.p_path);
422 acl_free(acl);
423 return (1);
424 }
EOPNOTSUPP for acl_set_fd_np(3) is defined as:
[EOPNOTSUPP] The file system does not support ACL retrieval.
This would be referring to the destination filesystem.
Looking through the md(4) source for references to EOPNOTSUPP, we do
find some references:
$ egrep -n -r "EOPNOTSUPP|ENOTSUP" /usr/src/sys/dev/md
/usr/src/sys/dev/md/md.c:423: return (EOPNOTSUPP);
/usr/src/sys/dev/md/md.c:475: error =3D EOPNOTSUPP;
/usr/src/sys/dev/md/md.c:523: return (EOPNOTSUPP);
/usr/src/sys/dev/md/md.c:601: return (EOPNOTSUPP);
/usr/src/sys/dev/md/md.c:731: error =3D EOPNOTSUP=
P;
Line 423 is within mdstart_malloc(), and it returns EOPNOTSUPP on any
BIO operation other than READ/WRITE/DELETE. Line 475 is a continuation
of that.
Line 508 is within mdstart_vnode(), behaving effectively the same as
line 423. Line 601 is within mdstart_swap(), behaving effectively the
same as line 423.
Line 731 is within md_kthread(), and indicates only BIO operation
BIO_GETATTR is supported. This would not be an "ACL attribute" thing,
but rather getting attributes of the backing device itself. The code
hints at that:
722 if (bp->bio_cmd =3D=3D BIO_GETATTR) {
723 if ((sc->fwsectors && sc->fwheads &&
724 (g_handleattr_int(bp, "GEOM::fwsectors",
725 sc->fwsectors) ||
726 g_handleattr_int(bp, "GEOM::fwheads",
727 sc->fwheads))) ||
728 g_handleattr_int(bp, "GEOM::candelete", 1))
729 error =3D -1;
730 else
731 error =3D EOPNOTSUPP;
732 } else {
This leaves me with some ideas; just tossing them out here...
1. Maybe/somehow this is caused by swap being used as the backing
type/store for md(4)? Try using "mdconfig -t malloc -o reserve"
instead, temporarily anyway.
2. Are you absolutely 100% sure the kernel you're using was built
with "options UFS_ACL" defined in it? Doing a "strings -a
/boot/kernel/kernel | grep UFS_ACL" should suffice.
--=20
| Jeremy Chadwick jdc@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110306153745.GA93530>