From owner-freebsd-current@FreeBSD.ORG Sun Mar 6 15:37:49 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 126651065675 for ; Sun, 6 Mar 2011 15:37:49 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id E9B638FC08 for ; Sun, 6 Mar 2011 15:37:48 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta13.emeryville.ca.mail.comcast.net with comcast id Frd91g0021afHeLADrdovJ; Sun, 06 Mar 2011 15:37:48 +0000 Received: from koitsu.dyndns.org ([98.248.33.18]) by omta17.emeryville.ca.mail.comcast.net with comcast id Frdl1g00C0PUQVN8drdmup; Sun, 06 Mar 2011 15:37:46 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6B8F69B422; Sun, 6 Mar 2011 07:37:45 -0800 (PST) Date: Sun, 6 Mar 2011 07:37:45 -0800 From: Jeremy Chadwick To: Steve Wills Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <4D739D96.5090705@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sun, 06 Mar 2011 15:50:41 +0000 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 15:37:49 -0000 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 |