Date: Sun, 06 Mar 2011 11:06:09 -0500 From: Steve Wills <swills@FreeBSD.org> To: Jeremy Chadwick <freebsd@jdc.parodius.com> 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: <4D73B0F1.1040304@FreeBSD.org> In-Reply-To: <20110306153745.GA93530@icarus.home.lan> 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> <20110306153745.GA93530@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/06/11 10:37, Jeremy Chadwick wrote:
>
> 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 = 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 = EOPNOTSUPP;
>
> 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 == 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 = -1;
> 730 else
> 731 error = EOPNOTSUPP;
> 732 } else {
Thanks for the investigation! So this seems to be a bug in md? That's
too bad, I was enjoying using it to make my tinderbox builds faster.
> 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.
Seems to be the same.
> 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.
>
Yep, it does:
% strings -a /boot/kernel/kernel | grep UFS_ACL
options UFS_ACL
(My kernel config is just "include GENERIC" then a bunch of "nooptions"
for KDB, DDB, GDB, INVARIANTS, WITNESS, etc.)
Steve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (FreeBSD)
iQEcBAEBAgAGBQJNc7DxAAoJEPXPYrMgexuh3gsH/0L474FitZMdLLrTLiDiU7jR
D+9syg0boUYcWbv6pA1j1r8LvXMrw0rIxvZOPB4BauY/u8nL5n0YgDgv7tjb69+D
n/m7ce6r1tm6JtBSl/d+MIYfmcnj1E9B8ibgeGwPApKnhe4lmmyLpFHW98tcU1EL
Be+koxDiaKloryyfHrlcIfmSmXMUZ8lP7MFHfFeS39KbE+sf7xXHHLjFE7bcPSi4
qKyBFDcw/ykRjsrM3+YDIanhLUHg8ZjKhlrzbPUgMpzlXXe2QbmLkQELa9SmhVzH
juYywb7JOe5uHuefFQxnTLkSWuDjTlxLW6M+FuNEDejfA91sGIil7m+1nMcdCFg=
=nsSt
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D73B0F1.1040304>