From owner-freebsd-current@FreeBSD.ORG Sun Mar 6 16:06:13 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 296E7106566B; Sun, 6 Mar 2011 16:06:13 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [204.109.58.86]) by mx1.freebsd.org (Postfix) with ESMTP id 970968FC18; Sun, 6 Mar 2011 16:06:12 +0000 (UTC) Received: from meatwad.mouf.net (cpe-065-190-178-041.nc.res.rr.com [65.190.178.41]) (authenticated bits=0) by mouf.net (8.14.4/8.14.4) with ESMTP id p26G699w097069 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 6 Mar 2011 11:06:11 -0500 (EST) (envelope-from swills@FreeBSD.org) Message-ID: <4D73B0F1.1040304@FreeBSD.org> Date: Sun, 06 Mar 2011 11:06:09 -0500 From: Steve Wills User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20110130 Thunderbird/3.0.11 MIME-Version: 1.0 To: Jeremy Chadwick 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> In-Reply-To: <20110306153745.GA93530@icarus.home.lan> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mouf.net [204.109.58.86]); Sun, 06 Mar 2011 11:06:11 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.2 at mouf.net X-Virus-Status: Clean Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Edward Tomasz Napiera?a Subject: Re: ACL issue (Was Re: HEADS UP: ZFSv28 is in!) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 16:06:13 -0000 -----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-----