From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 24 01:28:41 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E34FAC2; Sun, 24 Nov 2013 01:28:41 +0000 (UTC) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AEDA225E4; Sun, 24 Nov 2013 01:28:40 +0000 (UTC) Received: by mail-ea0-f174.google.com with SMTP id b10so1441404eae.33 for ; Sat, 23 Nov 2013 17:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N9hTop8FsCeWsdRmjiJNqD+wOODAobEtdc7S0r7QfJ4=; b=ekkNgOiBRwZGlkHYx0BhFq0amRg/OJJgoDVz26GX03vM/ru36q2J77kwS09TWjecIQ J7OtEEgoBVKprJJzkf3skFbeSlHac4WBw7dCqrIe4uzc2K6bMyxoExuyBh2hZO9Cda0W 8GmLSX11FdeZPLWTqa7AQDySib0fAOrWL+hH/cJHANjLBCUJVv3DcMmIdPjHohAArYQ2 gLc+JrSW+fbpCvv/dryRXvtTxmYWj68lLMcyrR8l//1qov9A7atgKgJ7Wzz/AQ+nKDm8 tjmOgpsuVAyiDTGCyoSkPQPsdyVtoVrwpNvB2CpO8ptsbJuGPvzo+uEMJVf4cB952+If v2MQ== X-Received: by 10.14.199.197 with SMTP id x45mr26581941een.8.1385256519028; Sat, 23 Nov 2013 17:28:39 -0800 (PST) Received: from mini.home (abwu147.neoplus.adsl.tpnet.pl. [83.8.244.147]) by mx.google.com with ESMTPSA id g8sm88818527eep.20.2013.11.23.17.28.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Nov 2013 17:28:38 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: O_XATTR support in FreeBSD? From: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= In-Reply-To: <820263347.19772534.1385247218007.JavaMail.root@uoguelph.ca> Date: Sun, 24 Nov 2013 02:28:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <987A1DDC-0C8F-4EEF-9504-D28CA7027F56@FreeBSD.org> References: <820263347.19772534.1385247218007.JavaMail.root@uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1822) Cc: Freebsd hackers list , Richard Yao , Pedro Giffuni , Robert Watson , Cedric Blancher X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 01:28:41 -0000 Wiadomo=C5=9B=C4=87 napisana przez Rick Macklem w = dniu 23 lis 2013, o godz. 23:53: > Pedro Giffuni wrote: >> On 23.11.2013 02:13, Cedric Blancher wrote: >>> On 22 November 2013 20:55, Pedro Giffuni wrote: >>>> Well ... >>>>=20 >>>> According to: >>>>=20 >>>> https://wiki.freebsd.org/ZFS >>>>=20 >>>> We do support Extended Attributes on ZFS but they differ from the >>>> ones in >>>> Solaris (and Linux). >>> Well, we need the one specified in the NFSv4 standard. The Linux >>> extended attributes are pretty much useless because they are size >>> restricted (typical attribute size here is in the GB range, and for >>> example NIH and CERN have even much bigger sizes), can't be >>> accessed >>> like normal files and are incompatible to Window's Alternate >>> Streams. >>>=20 >>> Ced >>=20 >> I was unaware of a standard for EA beyond the old posix draft. >> The reason for Extended Attributes is supporting ACL and we support >> both >> the draft posix and the NFS/win style ACLs. >>=20 > Interestingly, FreeBSD has a VOP_OPENEXTATTR() but no syscall > that uses it nor support for it in ZFS. (I'm just guessing it > was intended for an openat(2) syscall at some time?) Hm, interesting. It looks kind of unused (MAC uses it to implement mac_vnode_create_extattr() and mac_vnode_setlabel_extattr()). Robert = (Cc-ed), perhaps you know what=E2=80=99s the story here? % grep -R openextattr * =20 fs/unionfs/union.h:#define UNIONFS_OPENEXTL 0x01 /* openextattr = (lower) */ fs/unionfs/union.h:#define UNIONFS_OPENEXTU 0x02 /* openextattr = (upper) */ fs/unionfs/union_vnops.c:unionfs_openextattr(struct vop_openextattr_args = *ap) fs/unionfs/union_vnops.c: .vop_openextattr =3D = unionfs_openextattr, kern/vnode_if.src:%% openextattr vp L L L kern/vnode_if.src:vop_openextattr { ufs/ffs/ffs_vnops.c:static vop_openextattr_t ffs_openextattr; ufs/ffs/ffs_vnops.c: .vop_openextattr =3D ffs_openextattr, ufs/ffs/ffs_vnops.c: .vop_openextattr =3D ffs_openextattr, ufs/ffs/ffs_vnops.c:ffs_openextattr(struct vop_openextattr_args *ap) ufs/ffs/ffs_vnops.c:struct vop_openextattr_args { % grep -R VOP_OPENEXTATTR * fs/unionfs/union_vnops.c: error =3D VOP_OPENEXTATTR(tvp, = ap->a_cred, ap->a_td); fs/unionfs/union_vnops.c: VOP_OPENEXTATTR(lvp, = cred, td)) { fs/unionfs/union_vnops.c: panic("unionfs: = VOP_OPENEXTATTR failed"); fs/unionfs/union_vnops.c: if ((error =3D = VOP_OPENEXTATTR(uvp, cred, td)) !=3D 0) fs/unionfs/union_vnops.c: VOP_OPENEXTATTR(lvp, = cred, td)) { fs/unionfs/union_vnops.c: panic("unionfs: = VOP_OPENEXTATTR failed"); fs/unionfs/union_vnops.c: if ((error =3D = VOP_OPENEXTATTR(uvp, cred, td)) !=3D 0) security/mac/mac_vfs.c: error =3D VOP_OPENEXTATTR(vp, cred, curthread); security/mac/mac_vfs.c: error =3D VOP_OPENEXTATTR(vp, cred, curthread); Anyway - extended attributes _are_ supported on ZFS; see extattr(2) for = API.