From owner-freebsd-scsi@freebsd.org Sun Mar 6 03:06:50 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 472C7A92FF4 for ; Sun, 6 Mar 2016 03:06:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 214BDC27 for ; Sun, 6 Mar 2016 03:06:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: by mailman.ysv.freebsd.org (Postfix) id 1AC2FA92FF2; Sun, 6 Mar 2016 03:06:50 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19E15A92FEF; Sun, 6 Mar 2016 03:06:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 6DD9FC20; Sun, 6 Mar 2016 03:06:48 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:y0MephYh0UWE+WqeSx8+bf3/LSx+4OfEezUN459isYplN5qZpcu6bnLW6fgltlLVR4KTs6sC0LqJ9f+wEjVQsN6oizMrTt9lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUiv2OQc9HOnpAIma153xjLDtvcKDKFwY1XKUWvBbElaflU3prM4YgI9veO4a6yDihT92QdlQ3n5iPlmJnhzxtY+a9Z9n9DlM6bp6r5YTGY2zRakzTKRZATI6KCh1oZSz7ViQBTeIs1gRVC0znwBSEkCR7xz8dpnrvybwreY73zOVa57YV7cxDA6j5KQjbRbjiyMKMnZt6mTegc90gadzvRWuuhF7246Sa4jDZ6k2Rb/UYd5PHTkJZc1WTSEUR9rkN4Y= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DQAQB/ndtW/61jaINdFoN2bQa6OgENgWkXCoUkSgKBVBQBAQEBAQEBAWMngi2CFAEBAQMBAQEBIAQnIAsFCwIBCBgCAg0ZAgInAQkmAgQIBwQBHAICh3kIDrA+jlABAQEBAQEEAQEBAQEBAQEUBHuFHIF3gkaEGwEBG4MCgToFh1iGTD2ISYVjhSGETIREiFOOUwIeAQFChAIeLgEBAQSIBzR+AQEB X-IronPort-AV: E=Sophos;i="5.22,544,1449550800"; d="scan'208";a="270953938" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-annu.net.uoguelph.ca with ESMTP; 05 Mar 2016 22:06:41 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 450B015F565; Sat, 5 Mar 2016 22:06:41 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id YFPGxz6bFf3n; Sat, 5 Mar 2016 22:06:40 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 7F3BC15F56D; Sat, 5 Mar 2016 22:06:40 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SFuSwJoICiuZ; Sat, 5 Mar 2016 22:06:40 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 61E4915F565; Sat, 5 Mar 2016 22:06:40 -0500 (EST) Date: Sat, 5 Mar 2016 22:06:40 -0500 (EST) From: Rick Macklem To: Ken Merry Cc: fs@freebsd.org, scsi@freebsd.org, Robert Watson Message-ID: <800018199.6694281.1457233600357.JavaMail.zimbra@uoguelph.ca> In-Reply-To: References: Subject: Re: FUSE extended attribute patches available MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.95.12] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF44 (Win)/8.0.9_GA_6191) Thread-Topic: FUSE extended attribute patches available Thread-Index: hQcBf8vLnYvQAb3eet2rDypFlNoDHA== X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2016 03:06:50 -0000 Ken Merry wrote: > I have patches for FreeBSD=E2=80=99s FUSE filesystem kernel module to sup= port > extended attributes: >=20 > https://people.freebsd.org/~ken/fuse_extattr.20160229.1.txt >=20 The only bit of code I have that might be useful for this patch is: =09case FUSE_GETXATTR: =09case FUSE_LISTXATTR: ! =09=09/* ! =09=09 * These can have varying response lengths, and 0 length ! =09=09 * isn't necessarily invalid. ! =09=09 */ ! =09=09err =3D 0; *** I came up with this: =09=09fgin =3D (struct fuse_getxattr_in *) =09=09 ((char *)ftick->tk_ms_fiov.base + =09=09 sizeof(struct fuse_in_header)); =09=09if (fgin->size =3D=3D 0) =09=09=09err =3D (blen =3D=3D sizeof(struct fuse_getxattr_out)) ? 0 : =09=09=09 EINVAL; =09=09else =09=09=09err =3D (blen <=3D fgin->size) ? 0 : EINVAL; =09=09break; I think I got the size check right? The big question is... What to do with the NAMESPACE? - My code fails for SYSTEM and does USER without prepending "user.". (That seemed to be what rwatson@ felt was reasonable. I thought our discussion was on a mailing list, but I can't find it.) I've cc'd him. Maybe he can comment again. - If you stick with prepending "user." or "system." there needs to be some way to bypass this so that attributes that don't start in "user." or "system." can be accessed. I've seen "trusted." and "glusterfs." on GlusterFS. --> Maybe a new namespace called something like "nil" that just bypasses any USER or SYSTEM checks? rick > The patch implements the get/set/delete/list extended attribute methods. = The > listing code also converts extended attribute lists from the Linux/FUSE > format to the FreeBSD format. For example: >=20 > # touch foo > # ls -la foo > -rwxrwxrwx 1 root wheel 0 Feb 29 21:40 foo > # lsextattr user foo > foo > # setextattr user testattr1 "12345678" foo > # lsextattr user foo > foo testattr1 > # getextattr user testattr1 foo > foo 12345678 > # setextattr user testattr2 "87654321" foo > # lsextattr user foo > foo testattr2 testattr1 > # rmextattr user testattr1 foo > # lsextattr user foo > foo testattr2 > # getextattr user testattr1 foo > getextattr: foo: failed: Attribute not found > # getextattr user testattr2 foo > foo 87654321 >=20 >=20 > Just to be clear on what this does, it only provides extended attribute > support to FreeBSD applications if the underlying FUSE filesystem impleme= nts > FUSE extended attribute support. Many FUSE filesystems don=E2=80=99t sup= port the > extended attribute VFS operations. >=20 > I have tested this out on IBM=E2=80=99s LTFS implementation, but I have n= ot yet found > another FUSE filesystem that supports extended attributes. If anyone kno= ws > of one, please let me know so I can try it out. (I looked through a numb= er > of the filesystems in sysutils/fusefs* in the ports tree.) >=20 > Any feedback is welcome. I=E2=80=99m planning to check this into FreeBSD= /head in the > next week or so. >=20 > Obviously, I=E2=80=99ve also ported IBM=E2=80=99s LTFS implementation to = FreeBSD. It works > in the standard FUSE mode, and you can also link it into an application a= s a > library if you don=E2=80=99t want to incur the overhead of running throug= h FUSE. I > haven=E2=80=99t gotten around to packaging it up to go out for testing / = review. >=20 > If anyone has IBM LTO-5 or newer tape drives, or IBM TS1140 or newer tape > drives, and wants to try it out, let me know. I=E2=80=99ll send you the = code when > I=E2=80=99ve got it at least somewhat ready. This is IBM-specific, and w= on=E2=80=99t work > on HP tape drives. >=20 > Ken > =E2=80=94 > Ken Merry > ken@FreeBSD.ORG >=20 >=20 >=20 > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-scsi@freebsd.org Mon Mar 7 07:16:14 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB3EFAC3E5E for ; Mon, 7 Mar 2016 07:16:14 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C84E2E05 for ; Mon, 7 Mar 2016 07:16:14 +0000 (UTC) (envelope-from julian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id C07E4AC3E5C; Mon, 7 Mar 2016 07:16:14 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFF22AC3E5A; Mon, 7 Mar 2016 07:16:14 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 98542E01; Mon, 7 Mar 2016 07:16:14 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u277GBoT069594 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 6 Mar 2016 23:16:12 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: FUSE extended attribute patches available To: Rick Macklem , Ken Merry References: <800018199.6694281.1457233600357.JavaMail.zimbra@uoguelph.ca> Cc: Robert Watson , fs@freebsd.org, scsi@freebsd.org From: Julian Elischer Message-ID: <56DD2AB6.1030407@freebsd.org> Date: Sun, 6 Mar 2016 23:16:06 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <800018199.6694281.1457233600357.JavaMail.zimbra@uoguelph.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 07:16:15 -0000 On 5/03/2016 7:06 PM, Rick Macklem wrote: > Ken Merry wrote: >> I have patches for FreeBSD’s FUSE filesystem kernel module to support >> extended attributes: oh showing off your masochistic side eh? >> https://people.freebsd.org/~ken/fuse_extattr.20160229.1.txt >> I spent an hour beating my head against fuse yesterday. then realised that it's an old version on our product. We really have to get off 8.0 (hopefully a matter of weeks now to a 10.x switch) Now all I need is to find a FreeBSD filesystem expert (ZFS/NFS/CIFS/GFS) to hire. > The only bit of code I have that might be useful for this patch is: > case FUSE_GETXATTR: > case FUSE_LISTXATTR: > ! /* > ! * These can have varying response lengths, and 0 length > ! * isn't necessarily invalid. > ! */ > ! err = 0; > *** I came up with this: > fgin = (struct fuse_getxattr_in *) > ((char *)ftick->tk_ms_fiov.base + > sizeof(struct fuse_in_header)); > if (fgin->size == 0) > err = (blen == sizeof(struct fuse_getxattr_out)) ? 0 : > EINVAL; > else > err = (blen <= fgin->size) ? 0 : EINVAL; > break; > I think I got the size check right? > > The big question is... > What to do with the NAMESPACE? > - My code fails for SYSTEM and does USER without prepending "user.". > (That seemed to be what rwatson@ felt was reasonable. I thought our > discussion was on a mailing list, but I can't find it.) > I've cc'd him. Maybe he can comment again. Is there a standard for extended attributes I should knwo about? It seems to me that it's a bit like the wild west. Extended attributes seem to be "every OS for himself". > > - If you stick with prepending "user." or "system." there needs to be > some way to bypass this so that attributes that don't start in "user." > or "system." can be accessed. I've seen "trusted." and "glusterfs." > on GlusterFS. > --> Maybe a new namespace called something like "nil" that just bypasses > any USER or SYSTEM checks? > > rick > >> The patch implements the get/set/delete/list extended attribute methods. The >> listing code also converts extended attribute lists from the Linux/FUSE >> format to the FreeBSD format. For example: >> >> # touch foo >> # ls -la foo >> -rwxrwxrwx 1 root wheel 0 Feb 29 21:40 foo >> # lsextattr user foo >> foo >> # setextattr user testattr1 "12345678" foo >> # lsextattr user foo >> foo testattr1 >> # getextattr user testattr1 foo >> foo 12345678 >> # setextattr user testattr2 "87654321" foo >> # lsextattr user foo >> foo testattr2 testattr1 >> # rmextattr user testattr1 foo >> # lsextattr user foo >> foo testattr2 >> # getextattr user testattr1 foo >> getextattr: foo: failed: Attribute not found >> # getextattr user testattr2 foo >> foo 87654321 >> >> >> Just to be clear on what this does, it only provides extended attribute >> support to FreeBSD applications if the underlying FUSE filesystem implements >> FUSE extended attribute support. Many FUSE filesystems don’t support the >> extended attribute VFS operations. >> >> I have tested this out on IBM’s LTFS implementation, but I have not yet found >> another FUSE filesystem that supports extended attributes. If anyone knows >> of one, please let me know so I can try it out. (I looked through a number >> of the filesystems in sysutils/fusefs* in the ports tree.) >> >> Any feedback is welcome. I’m planning to check this into FreeBSD/head in the >> next week or so. >> >> Obviously, I’ve also ported IBM’s LTFS implementation to FreeBSD. It works >> in the standard FUSE mode, and you can also link it into an application as a >> library if you don’t want to incur the overhead of running through FUSE. I >> haven’t gotten around to packaging it up to go out for testing / review. >> >> If anyone has IBM LTO-5 or newer tape drives, or IBM TS1140 or newer tape >> drives, and wants to try it out, let me know. I’ll send you the code when >> I’ve got it at least somewhat ready. This is IBM-specific, and won’t work >> on HP tape drives. >> >> Ken >> — >> Ken Merry >> ken@FreeBSD.ORG >> >> >> >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > From owner-freebsd-scsi@freebsd.org Mon Mar 7 07:59:42 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99636AC2705 for ; Mon, 7 Mar 2016 07:59:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 88FC8E74 for ; Mon, 7 Mar 2016 07:59:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 87CA2AC2703; Mon, 7 Mar 2016 07:59:42 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6EDACAC2700; Mon, 7 Mar 2016 07:59:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 2F557E73; Mon, 7 Mar 2016 07:59:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from [10.0.1.12] (host81-157-243-217.range81-157.btcentralplus.com [81.157.243.217]) by cyrus.watson.org (Postfix) with ESMTPSA id CC86A46B2E; Mon, 7 Mar 2016 02:59:34 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: FUSE extended attribute patches available From: Robert Watson In-Reply-To: <56DD2AB6.1030407@freebsd.org> Date: Mon, 7 Mar 2016 07:59:33 +0000 Cc: Rick Macklem , Ken Merry , fs@freebsd.org, scsi@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6AF0FC23-CC34-43EA-A008-9FB82FB21558@FreeBSD.org> References: <800018199.6694281.1457233600357.JavaMail.zimbra@uoguelph.ca> <56DD2AB6.1030407@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 07:59:42 -0000 FreeBSD and Linux=E2=80=99s extended-attribute models were inherited = from IRIX, as they were introduced to solve the same problems: a place = to metadata such as ACLs, MAC labels, capability masks, etc. IRIX had = three namespaces: one each for =E2=80=9Cuser=E2=80=9D, =E2=80=9Croot=E2=80= =9D, and =E2=80=9Csecure=E2=80=9D, reflecting whether or not they were = managed by the file owner (or permissions), the privileged root user, or = part of the TCB protection mechanism (e.g., for integrity labels). These extended attributes should not be confused with the filesystem = feature of the same name in NFSv4, which is sometimes known by the name = =E2=80=9Cfile fork=E2=80=9D or =E2=80=9Cdata streams=E2=80=9D. EAs in = IRIX/FreeBSD/Linux/HPFS/etc are tuple pairs of names and values intended = to be written atomically or updated in place specifically for (shortish) = metadata such as ACLs, rather than being complete separate data spaces = for I/O (e.g., that could be memory mapped). In FreeBSD=E2=80=99s design, we incorporated the disjoint namespace = model, providing USER and SYSTEM, the former being managed by the file = owner (and those given suitable permission), and the latter being used = for TCB mechanisms such as the implementations of MAC labels, ACLs, etc. In Linux, they adopted a more free-form mechanism based on a single = combined namespace with a prefix =E2=80=94 e.g., user.FOO, and = system.BAR. Over time it looks like that namespace has been expanded in = various filesystem-specific ways. We also have room to expand our = namespace, but from the description below, it=E2=80=99s not clear quite = what the right mechanism is. One path would be to introduce a new namespace for filesystem-specific = attributes =E2=80=94 e.g., EXTATTR_NAMESPACE_FS? But I think the key question here is whether the existing namespaces can = provide the semantics you need. If not, then we likely need a new = namespace. But then we get the question as to who controls use of the = namespace. Certainly =E2=80=9Cthe filesystem=E2=80=9D is one option, but = then you will get inconsistency in approaches between filesystems and = applications =E2=80=94 across various dimensions including protection = (who can read/modify them?), allocation (who decides what names should = be used for what?), and semantics (what applications can use them, and = who backs them up?). For example: who should be responsible for backing up those attributes? = For =E2=80=98system=E2=80=99 attributes in FreeBSD, it is assumed that = backup tools will be aware of the services layered over the attributes = =E2=80=94 e.g., that they will back up ACLs using the ACL API, rather = than backing up the binary EAs holding the ACLs. For =E2=80=98user=E2=80=99= attributes, it is assumed that backup tools (e.g., tar) must explicitly = preserve them, since they are user-defined and user-managed. For = filesystem-specific attributes, some other choice will need to be made = =E2=80=94 perhaps filesystem-specific backup tools need to know about = them? Note that in the Linux EA model, ACLs are actually accessed via the EA = system calls, whereas in FreeBSD, ACLs are a first-class citizen in the = system-call API/ABI, and so user applications don=E2=80=99t treat them = as EAs. We made that choice as filesystems may choose themselves not to = represent ACLs as EAs, and they have real semantics visible to the VFS = layer. In Linux, I believe they chose to pass them via EAs to narrow the = system-call interface for filesystem metadata. Both are legitimate = choices, but this could also trigger discussions about whether new = attributes are best accessed via the EA interface, or new system calls. = For filesystem-specific attributes, EAs are likely the better way to go. Robert > On 7 Mar 2016, at 07:16, Julian Elischer wrote: >=20 > On 5/03/2016 7:06 PM, Rick Macklem wrote: >> Ken Merry wrote: >>> I have patches for FreeBSD=E2=80=99s FUSE filesystem kernel module = to support >>> extended attributes: > oh showing off your masochistic side eh? >=20 >>> https://people.freebsd.org/~ken/fuse_extattr.20160229.1.txt >>>=20 > I spent an hour beating my head against fuse yesterday. > then realised that it's an old version on our product. We really have = to get off 8.0 > (hopefully a matter of weeks now to a 10.x switch) > Now all I need is to find a FreeBSD filesystem expert = (ZFS/NFS/CIFS/GFS) to hire. >=20 >=20 >> The only bit of code I have that might be useful for this patch is: >> case FUSE_GETXATTR: >> case FUSE_LISTXATTR: >> ! /* >> ! * These can have varying response lengths, and 0 length >> ! * isn't necessarily invalid. >> ! */ >> ! err =3D 0; >> *** I came up with this: >> fgin =3D (struct fuse_getxattr_in *) >> ((char *)ftick->tk_ms_fiov.base + >> sizeof(struct fuse_in_header)); >> if (fgin->size =3D=3D 0) >> err =3D (blen =3D=3D sizeof(struct = fuse_getxattr_out)) ? 0 : >> EINVAL; >> else >> err =3D (blen <=3D fgin->size) ? 0 : EINVAL; >> break; >> I think I got the size check right? >>=20 >> The big question is... >> What to do with the NAMESPACE? >> - My code fails for SYSTEM and does USER without prepending "user.". >> (That seemed to be what rwatson@ felt was reasonable. I thought our >> discussion was on a mailing list, but I can't find it.) >> I've cc'd him. Maybe he can comment again. > Is there a standard for extended attributes I should knwo about? > It seems to me that it's a bit like the wild west. > Extended attributes seem to be "every OS for himself". >=20 >>=20 >> - If you stick with prepending "user." or "system." there needs to be >> some way to bypass this so that attributes that don't start in = "user." >> or "system." can be accessed. I've seen "trusted." and "glusterfs." >> on GlusterFS. >> --> Maybe a new namespace called something like "nil" that just = bypasses >> any USER or SYSTEM checks? >>=20 >> rick >>=20 >>> The patch implements the get/set/delete/list extended attribute = methods. The >>> listing code also converts extended attribute lists from the = Linux/FUSE >>> format to the FreeBSD format. For example: >>>=20 >>> # touch foo >>> # ls -la foo >>> -rwxrwxrwx 1 root wheel 0 Feb 29 21:40 foo >>> # lsextattr user foo >>> foo >>> # setextattr user testattr1 "12345678" foo >>> # lsextattr user foo >>> foo testattr1 >>> # getextattr user testattr1 foo >>> foo 12345678 >>> # setextattr user testattr2 "87654321" foo >>> # lsextattr user foo >>> foo testattr2 testattr1 >>> # rmextattr user testattr1 foo >>> # lsextattr user foo >>> foo testattr2 >>> # getextattr user testattr1 foo >>> getextattr: foo: failed: Attribute not found >>> # getextattr user testattr2 foo >>> foo 87654321 >>>=20 >>>=20 >>> Just to be clear on what this does, it only provides extended = attribute >>> support to FreeBSD applications if the underlying FUSE filesystem = implements >>> FUSE extended attribute support. Many FUSE filesystems don=E2=80=99t = support the >>> extended attribute VFS operations. >>>=20 >>> I have tested this out on IBM=E2=80=99s LTFS implementation, but I = have not yet found >>> another FUSE filesystem that supports extended attributes. If = anyone knows >>> of one, please let me know so I can try it out. (I looked through a = number >>> of the filesystems in sysutils/fusefs* in the ports tree.) >>>=20 >>> Any feedback is welcome. I=E2=80=99m planning to check this into = FreeBSD/head in the >>> next week or so. >>>=20 >>> Obviously, I=E2=80=99ve also ported IBM=E2=80=99s LTFS = implementation to FreeBSD. It works >>> in the standard FUSE mode, and you can also link it into an = application as a >>> library if you don=E2=80=99t want to incur the overhead of running = through FUSE. I >>> haven=E2=80=99t gotten around to packaging it up to go out for = testing / review. >>>=20 >>> If anyone has IBM LTO-5 or newer tape drives, or IBM TS1140 or newer = tape >>> drives, and wants to try it out, let me know. I=E2=80=99ll send you = the code when >>> I=E2=80=99ve got it at least somewhat ready. This is IBM-specific, = and won=E2=80=99t work >>> on HP tape drives. >>>=20 >>> Ken >>> =E2=80=94 >>> Ken Merry >>> ken@FreeBSD.ORG >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> freebsd-fs@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-fs >>> To unsubscribe, send any mail to = "freebsd-fs-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >>=20 >>=20 >=20 From owner-freebsd-scsi@freebsd.org Mon Mar 7 10:48:41 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1832EAC1212 for ; Mon, 7 Mar 2016 10:48:41 +0000 (UTC) (envelope-from byhkaan@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7C1A13A6 for ; Mon, 7 Mar 2016 10:48:40 +0000 (UTC) (envelope-from byhkaan@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id l68so65252404wml.1 for ; Mon, 07 Mar 2016 02:48:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=bp2p6oy+RiXn/L+OfO82vRNPL8RTBTlnzNR73UGQRCE=; b=ObnDLS9pxJpftVPPOcC2iKfOEVG98FPZNbWVBVCluG+CkxPe71zgAeMoTqhmWkx5+8 8XREJN+zZoUocz1YstyYmpRcWfJtGPq68eJiFNe6t6//fTJodvstdElMlESptzX8/6I3 k4+6BFHbQ6jhdiuMR4gwgbz/PrjMVJYi6YFfi0LxaunYt7c25DFhlDL/8JhGjrQLN0Wb Pn3JVcN42lB1UZqfo7O4ZapBPwa4kh4T61qYz1IBMcHu6JiccGWPhaMhJreY8ftQTluW oXgQU21Aixj/qbbikcs/9+wH0h3E2seuGUmS4TtVPV6fTT8ZuBH6fnExBumpIhmahDBh nyFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=bp2p6oy+RiXn/L+OfO82vRNPL8RTBTlnzNR73UGQRCE=; b=DcULcmrkjGj1oVZI15oTMbZ7Xuju21GfWsBPGTt4wo1ZYnxTN5/2KcurVEywJiBPlX x7rJDoHWhgbV0P8HSQp5PKSwfZS4Zd2wy78CzuR6KsO16zrsGcqe+wqj2vDx3n8CbNPI 3sHc4FaqEG8dhofzJUHe6hb4/bgAMkviKIXOqBuTSQNRMsaZ3KLdsY96JkkGorlWevql ASiTc1d7Fth7atzSfFdtSeGGScs/s9BUH47njj+uwhBxt4L93ANwhRWfhn5i5+lPMxar LpxHphvnixdERqnEIJncB2yIESBcpOokw49oT2MdL/e8mQ2DCrPMoMHQ0jxlADCJT5Rz V8eA== X-Gm-Message-State: AD7BkJJV1Waf5z18wb3zpQ9Wt+cIyhd79vToQE5BiUWrv7eERxwtDxItRv3Kqf0LZQ7fMw== X-Received: by 10.28.188.5 with SMTP id m5mr6269146wmf.35.1457347718782; Mon, 07 Mar 2016 02:48:38 -0800 (PST) Received: from [192.168.1.37] ([78.167.25.212]) by smtp.gmail.com with ESMTPSA id g126sm12968273wmf.16.2016.03.07.02.48.37 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2016 02:48:37 -0800 (PST) To: freebsd-scsi@freebsd.org From: byhkaan Subject: Toshiba SAS disk Message-ID: <56DD5C84.6070502@gmail.com> Date: Mon, 7 Mar 2016 12:48:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 10:48:41 -0000 Hi, I have a dell perc h330 card runnig at HBA mode with TOSHIBA AL13SEB300 series 10k sas drives. These disk are running on ubuntu as expected defined from spec sheet ,but at FreeBSD10 they are acting like limited to 20MB/s bandwidth. I also tried the mrsas driver instead of mfi but the results are same. Is anyone see the same problem ? linux # dd if=/dev/zero of=/dev/sdb bs=1M count=1000 oflag=dsync 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 11.0951 s, 94.5 MB/s freebsd10 (FreeBSD 10.2-STABLE #2 r291926M) # dd if=/dev/zero of=/dev/da4 bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 51.243550 secs (20462595 bytes/sec) # camcontrol inquiry da4 pass4: Fixed Direct Access SPC-4 SCSI device pass4: Serial Number 15O0A0FOFRD6 pass4: 150.000MB/s transfers, Command Queueing Enabled # diskinfo -vt da4 da4 512 # sectorsize 300000000000 # mediasize in bytes (279G) 585937500 # mediasize in sectors 0 # stripesize 0 # stripeoffset 9010 # Cylinders according to firmware. 255 # Heads according to firmware. 255 # Sectors according to firmware. 15O0A0FOFRD6 # Disk ident. Seek times: Full stroke: 250 iter in 2.790492 sec = 11.162 msec Half stroke: 250 iter in 1.870304 sec = 7.481 msec Quarter stroke: 500 iter in 3.109343 sec = 6.219 msec Short forward: 400 iter in 1.106922 sec = 2.767 msec Short backward: 400 iter in 1.412916 sec = 3.532 msec Seq outer: 2048 iter in 0.103199 sec = 0.050 msec Seq inner: 2048 iter in 0.104223 sec = 0.051 msec Transfer rates: outside: 102400 kbytes in 0.530404 sec = 193060 kbytes/sec middle: 102400 kbytes in 0.672639 sec = 152236 kbytes/sec inside: 102400 kbytes in 0.853422 sec = 119988 kbytes/sec thanks, From owner-freebsd-scsi@freebsd.org Mon Mar 7 12:34:00 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CBD739DB7EF for ; Mon, 7 Mar 2016 12:34:00 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 680913D2 for ; Mon, 7 Mar 2016 12:33:59 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.96] (izaro.sarenet.es [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPSA id EA0579DD34A for ; Mon, 7 Mar 2016 13:33:50 +0100 (CET) From: Borja Marcos Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: FreeBSD 10.3 - nvme regression Message-Id: <5A6B5C6F-26D1-40C5-8CCF-26EB8F17C59A@sarenet.es> Date: Mon, 7 Mar 2016 13:33:50 +0100 To: FreeBSD-scsi Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 12:34:01 -0000 Hello, I am trying a SuperMicro server with NVME disks. The system boots = FreeBSD 10.2, panics when booting FreeBSD 10.3. It was compiled on March 7th and Revision 296191 is included. On 10.3 it=E2=80=99s crashing right after this line: nvme9: mem 0xfba10000-0xfba13fff irq 59 at = device 0.0 on pci134 with a panic.=20 panic: couldn=E2=80=99t find an APIC vector for IRQ 59. cpuid =3D 0 The backtrace is (sorry, copying from a screen video) #0 kdb_backtrace=3D0x60 #1 vpanic+0x126 #2 panic+0x43 #3 ioapic_disable_intr+0 #4 intr_add_handler+0xfb #5 nexus_setup_inter+0x8a #6 pci_setup_intr+0x33 #7 pci_setup_intr+0x33 #8 bus_setup_intr+0xac #9 nvme_ctrlr_configure_intx+0x88 #10 nvme_ctrlr_construct+0x407 #11 nvme_attach+0x20 #12 device_attach+0x43d #13 bus_generic_attach+0x2d #14 acpi_pci_attach+0x15c #15 device_attach+0x43d #16 bus_generic_attach+0x2d #17 acpi_pcib_attach+0x22c It said =E2=80=9CUptime 1s=E2=80=9D and did a cold reboot. dmesg.boot from 10.2 (the system in installed on a memory stick). root@ssd9:/usr/src/sys/dev/nvme # cat /var/run/dmesg.boot=20 Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12 15:26:37 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz (2400.04-MHz K8-class = CPU) Origin=3D"GenuineIntel" Id=3D0x306f2 Family=3D0x6 Model=3D0x3f = Stepping=3D2 = Features=3D0xbfebfbff = Features2=3D0x7ffefbff,FMA,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TS= CDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> AMD Features=3D0x2c100800 AMD Features2=3D0x21 Structured Extended = Features=3D0x37ab XSAVE Features=3D0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, performance statistics real memory =3D 137438953472 (131072 MB) avail memory =3D 133409718272 (127229 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 cpu8 (AP): APIC ID: 8 cpu9 (AP): APIC ID: 9 cpu10 (AP): APIC ID: 10 cpu11 (AP): APIC ID: 11 cpu12 (AP): APIC ID: 12 cpu13 (AP): APIC ID: 13 cpu14 (AP): APIC ID: 14 cpu15 (AP): APIC ID: 15 cpu16 (AP): APIC ID: 16 cpu17 (AP): APIC ID: 17 cpu18 (AP): APIC ID: 18 cpu19 (AP): APIC ID: 19 cpu20 (AP): APIC ID: 20 cpu21 (AP): APIC ID: 21 cpu22 (AP): APIC ID: 22 cpu23 (AP): APIC ID: 23 cpu24 (AP): APIC ID: 24 cpu25 (AP): APIC ID: 25 cpu26 (AP): APIC ID: 26 cpu27 (AP): APIC ID: 27 cpu28 (AP): APIC ID: 28 cpu29 (AP): APIC ID: 29 cpu30 (AP): APIC ID: 30 cpu31 (AP): APIC ID: 31 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard random: initialized module_register_init: MOD_LOAD (vesa, 0xffffffff80db8eb0, 0) error 19 kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 cpu8: on acpi0 cpu9: on acpi0 cpu10: on acpi0 cpu11: on acpi0 cpu12: on acpi0 cpu13: on acpi0 cpu14: on acpi0 cpu15: on acpi0 cpu16: on acpi0 cpu17: on acpi0 cpu18: on acpi0 cpu19: on acpi0 cpu20: on acpi0 cpu21: on acpi0 cpu22: on acpi0 cpu23: on acpi0 cpu24: on acpi0 cpu25: on acpi0 cpu26: on acpi0 cpu27: on acpi0 cpu28: on acpi0 cpu29: on acpi0 cpu30: on acpi0 cpu31: on acpi0 atrtc0: port 0x70-0x71,0x74-0x77 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 Event timer "HPET3" frequency 14318180 Hz quality 340 Event timer "HPET4" frequency 14318180 Hz quality 340 Event timer "HPET5" frequency 14318180 Hz quality 340 Event timer "HPET6" frequency 14318180 Hz quality 340 Event timer "HPET7" frequency 14318180 Hz quality 340 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: on acpi0 pci255: on pcib0 pcib1: on acpi0 pci127: on pcib1 pcib2: port 0xcf8-0xcff on acpi0 pci0: on pcib2 pcib3: irq 26 at device 1.0 on pci0 pci1: on pcib3 ix0: = port 0x6020-0x603f mem 0xc7c00000-0xc7dfffff,0xc7e04000-0xc7e07fff irq = 26 at device 0.0 on pci1 ix0: Using MSIX interrupts with 9 vectors ix0: Ethernet address: 0c:c4:7a:a3:24:1e ix0: PCI Express Bus: Speed 5.0GT/s Width x8 ix1: = port 0x6000-0x601f mem 0xc7a00000-0xc7bfffff,0xc7e00000-0xc7e03fff irq = 28 at device 0.1 on pci1 ix1: Using MSIX interrupts with 9 vectors ix1: Ethernet address: 0c:c4:7a:a3:24:1f ix1: PCI Express Bus: Speed 5.0GT/s Width x8 pcib4: irq 32 at device 2.0 on pci0 pci2: on pcib4 nvme0: mem 0xc7610000-0xc7613fff irq 32 at = device 0.0 on pci2 pcib5: irq 32 at device 2.1 on pci0 pci3: on pcib5 nvme1: mem 0xc7510000-0xc7513fff irq 33 at = device 0.0 on pci3 pcib6: irq 32 at device 2.2 on pci0 pci4: on pcib6 pcib7: irq 40 at device 3.0 on pci0 pci5: on pcib7 nvme2: mem 0xc7410000-0xc7413fff irq 40 at = device 0.0 on pci5 pcib8: irq 40 at device 3.1 on pci0 pci6: on pcib8 nvme3: mem 0xc7310000-0xc7313fff irq 41 at = device 0.0 on pci6 pcib9: irq 40 at device 3.2 on pci0 pci7: on pcib9 nvme4: mem 0xc7210000-0xc7213fff irq 42 at = device 0.0 on pci7 pcib10: irq 40 at device 3.3 on pci0 pci8: on pcib10 nvme5: mem 0xc7110000-0xc7113fff irq 43 at = device 0.0 on pci8 pci0: at device 17.0 (no driver attached) ahci0: port = 0x7110-0x7117,0x7100-0x7103,0x70f0-0x70f7,0x70e0-0x70e3,0x7020-0x703f = mem 0xc7738000-0xc77387ff irq 16 at device 17.4 on pci0 ahci0: AHCI v1.30 with 4 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahciem0: on ahci0 xhci0: mem 0xc7700000-0xc770ffff irq = 19 at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA usbus0 on xhci0 pci0: at device 22.0 (no driver attached) pci0: at device 22.1 (no driver attached) ehci0: mem 0xc7734000-0xc77343ff irq = 18 at device 26.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 pcib11: irq 16 at device 28.0 on pci0 pci9: on pcib11 pcib12: irq 18 at device 28.2 on pci0 pci10: on pcib12 pcib13: at device 0.0 on pci10 pci11: on pcib13 vgapci0: port 0x5000-0x507f mem = 0xc6000000-0xc6ffffff,0xc7000000-0xc701ffff irq 18 at device 0.0 on = pci11 vgapci0: Boot video device ehci1: mem 0xc7733000-0xc77333ff irq = 18 at device 29.0 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci1 isab0: at device 31.0 on pci0 isa0: on isab0 ahci1: port = 0x7070-0x7077,0x7060-0x7063,0x7050-0x7057,0x7040-0x7043,0x7000-0x701f = mem 0xc7732000-0xc77327ff irq 16 at device 31.2 on pci0 ahci1: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich4: at channel 0 on ahci1 ahcich5: at channel 1 on ahci1 ahcich6: at channel 2 on ahci1 ahcich7: at channel 3 on ahci1 ahcich8: at channel 4 on ahci1 ahcich9: at channel 5 on ahci1 ahciem1: on ahci1 pcib14: on acpi0 pci128: on pcib14 pcib15: at device 0.0 on pci128 pci129: on pcib15 pcib16: irq 50 at device 1.0 on pci128 pci130: on pcib16 ix2: = port 0xf020-0xf03f mem 0xfb880000-0xfb8fffff,0xfb904000-0xfb907fff irq = 50 at device 0.0 on pci130 ix2: Using MSIX interrupts with 9 vectors ix2: Ethernet address: 0c:c4:7a:bd:70:26 ix2: PCI Express Bus: Speed 5.0GT/s Width x8 ix3: = port 0xf000-0xf01f mem 0xfb800000-0xfb87ffff,0xfb900000-0xfb903fff irq = 52 at device 0.1 on pci130 ix3: Using MSIX interrupts with 9 vectors ix3: Ethernet address: 0c:c4:7a:bd:70:27 ix3: PCI Express Bus: Speed 5.0GT/s Width x8 pcib17: irq 56 at device 2.0 on pci128 pci131: on pcib17 nvme6: mem 0xfbd10000-0xfbd13fff irq 56 at = device 0.0 on pci131 pcib18: irq 56 at device 2.1 on pci128 pci132: on pcib18 nvme7: mem 0xfbc10000-0xfbc13fff irq 57 at = device 0.0 on pci132 pcib19: irq 56 at device 2.2 on pci128 pci133: on pcib19 nvme8: mem 0xfbb10000-0xfbb13fff irq 58 at = device 0.0 on pci133 pcib20: irq 56 at device 2.3 on pci128 pci134: on pcib20 nvme9: mem 0xfba10000-0xfba13fff irq 59 at = device 0.0 on pci134 pcib21: irq 64 at device 3.0 on pci128 pci135: on pcib21 pcib22: irq 64 at device 3.2 on pci128 pci136: on pcib22 acpi_button0: on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 orm0: at iomem = 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcafff on isa0 sc0: at flags 0x100 on isa0 sc0: CGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3d0-0x3db iomem 0xb8000-0xbffff on = isa0 ppc0: cannot reserve I/O port range est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 est4: on cpu4 est5: on cpu5 est6: on cpu6 est7: on cpu7 est8: on cpu8 est9: on cpu9 est10: on cpu10 est11: on cpu11 est12: on cpu12 est13: on cpu13 est14: on cpu14 est15: on cpu15 est16: on cpu16 est17: on cpu17 est18: on cpu18 est19: on cpu19 est20: on cpu20 est21: on cpu21 est22: on cpu22 est23: on cpu23 est24: on cpu24 est25: on cpu25 est26: on cpu26 est27: on cpu27 est28: on cpu28 est29: on cpu29 est30: on cpu30 est31: on cpu31 random: unblocking device. usbus0: 5.0Gbps Super Speed USB v3.0 Timecounters tick every 1.000 msec usbus1: 480Mbps High Speed USB v2.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: <0x8086> at usbus0 uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on = usbus0 ugen2.1: at usbus2 uhub1: on usbus2 ugen1.1: at usbus1 uhub2: on usbus1 ses0 at ahciem0 bus 0 scbus4 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ses1 at ahciem1 bus 0 scbus11 target 0 lun 0 ses1: SEMB S-E-S 2.00 device ses1: SEMB SES Device nvd0: NVMe namespace nvd0: 1907729MB (3907029168 512 byte sectors) nvd1: NVMe namespace nvd1: 1907729MB (3907029168 512 byte sectors) nvd2: NVMe namespace nvd2: 1907729MB (3907029168 512 byte sectors) nvd3: NVMe namespace nvd3: 1907729MB (3907029168 512 byte sectors) nvd4: NVMe namespace nvd4: 1907729MB (3907029168 512 byte sectors) nvd5: NVMe namespace nvd5: 1907729MB (3907029168 512 byte sectors) nvd6: NVMe namespace nvd6: 1907729MB (3907029168 512 byte sectors) nvd7: NVMe namespace nvd7: 1907729MB (3907029168 512 byte sectors) nvd8: NVMe namespace nvd8: 1907729MB (3907029168 512 byte sectors) nvd9: NVMe namespace nvd9: 1907729MB (3907029168 512 byte sectors) SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #28 Launched! SMP: AP CPU #12 Launched! SMP: AP CPU #16 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #27 Launched! SMP: AP CPU #11 Launched! SMP: AP CPU #31 Launched! SMP: AP CPU #10 Launched! SMP: AP CPU #17 Launched! SMP: AP CPU #13 Launched! SMP: AP CPU #29 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #30 Launched! SMP: AP CPU #14 Launched! SMP: AP CPU #18 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #21 Launched! SMP: AP CPU #15 Launched! SMP: AP CPU #24 Launched! SMP: AP CPU #8 Launched! SMP: AP CPU #23 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #22 Launched! SMP: AP CPU #9 Launched! SMP: AP CPU #25 Launched! SMP: AP CPU #19 Launched! SMP: AP CPU #26 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #20 Launched! Timecounter "TSC-low" frequency 1200022010 Hz quality 1000 Root mount waiting for: usbus2 usbus1 usbus0 uhub2: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub0: 21 ports with 21 removable, self powered ugen1.2: at usbus1 uhub3: = on usbus1 ugen2.2: at usbus2 uhub4: = on usbus2 uhub3: 6 ports with 6 removable, self powered uhub4: 8 ports with 8 removable, self powered Root mount waiting for: usbus2 usbus1 ugen2.3: at usbus2 uhub5: = on usbus2 uhub5: 4 ports with 3 removable, self powered Root mount waiting for: usbus2 usbus1 ugen2.4: at usbus2 ukbd0: = on usbus2 ugen1.3: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks =3D 0x0100 umass0:12:0:-1: Attached to scbus12 kbd0 at ukbd0 cd0 at umass-sim0 bus 0 scbus12 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: 40.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present = - tray open cd0: quirks=3D0x10<10_BYTE_ONLY> ugen1.4: at usbus1 ukbd1: on usbus1 kbd2 at ukbd1 Root mount waiting for: usbus1 ugen1.5: at usbus1 umass1: on = usbus1 umass1: SCSI over Bulk-Only; quirks =3D 0x4000 umass1:13:1:-1: Attached to scbus13 Trying to mount root from ufs:/dev/da0s1a [rw]... da0 at umass-sim1 bus 1 scbus13 target 0 lun 0 mountroot: waiting for device /dev/da0s1a ... da0: Removable Direct Access SPC-2 SCSI device da0: 40.000MB/s transfers da0: 7681MB (15730688 512 byte sectors: 255H 63S/T 979C) da0: quirks=3D0x3 On 10.3=20 From owner-freebsd-scsi@freebsd.org Mon Mar 7 16:15:03 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C60CCAC3B46 for ; Mon, 7 Mar 2016 16:15:03 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id AC7676B2 for ; Mon, 7 Mar 2016 16:15:03 +0000 (UTC) (envelope-from ken@kdm.org) Received: by mailman.ysv.freebsd.org (Postfix) id A807AAC3B43; Mon, 7 Mar 2016 16:15:03 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D91AAC3B42; Mon, 7 Mar 2016 16:15:03 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D2B96AE; Mon, 7 Mar 2016 16:15:02 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id u27GEsSm004385 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Mar 2016 11:14:54 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id u27GEsD8004384; Mon, 7 Mar 2016 11:14:54 -0500 (EST) (envelope-from ken) Date: Mon, 7 Mar 2016 11:14:54 -0500 From: "Kenneth D. Merry" To: Rick Macklem Cc: fs@freebsd.org, scsi@freebsd.org, Robert Watson Subject: Re: FUSE extended attribute patches available Message-ID: <20160307161454.GA3501@mithlond.kdm.org> References: <800018199.6694281.1457233600357.JavaMail.zimbra@uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <800018199.6694281.1457233600357.JavaMail.zimbra@uoguelph.ca> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Mon, 07 Mar 2016 11:14:55 -0500 (EST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 16:15:04 -0000 On Sat, Mar 05, 2016 at 22:06:40 -0500, Rick Macklem wrote: > Ken Merry wrote: > > I have patches for FreeBSD???s FUSE filesystem kernel module to support > > extended attributes: > > > > https://people.freebsd.org/~ken/fuse_extattr.20160229.1.txt > > > The only bit of code I have that might be useful for this patch is: > case FUSE_GETXATTR: > case FUSE_LISTXATTR: > ! /* > ! * These can have varying response lengths, and 0 length > ! * isn't necessarily invalid. > ! */ > ! err = 0; > *** I came up with this: > fgin = (struct fuse_getxattr_in *) > ((char *)ftick->tk_ms_fiov.base + > sizeof(struct fuse_in_header)); > if (fgin->size == 0) > err = (blen == sizeof(struct fuse_getxattr_out)) ? 0 : > EINVAL; > else > err = (blen <= fgin->size) ? 0 : EINVAL; > break; > I think I got the size check right? I think that is correct, yes. > The big question is... > What to do with the NAMESPACE? > - My code fails for SYSTEM and does USER without prepending "user.". > (That seemed to be what rwatson@ felt was reasonable. I thought our > discussion was on a mailing list, but I can't find it.) > I've cc'd him. Maybe he can comment again. IBM's LTFS at least seems to require the "user." prefix on Linux. For context, this code supports Windows, Linux and MacOS X. So the "#else" case is Linux. Here's the code in question: /** * Strip a Linux namespace prefix from the given xattr name and return the position of the suffix. * If the name is "user.X", return the "X" portion. Otherwise, return an error. * This function does nothing on Mac OS X. * @param name Name to strip. * @return A pointer to the name suffix, or NULL to indicate an invalid name. On Mac OS X, * always returns @name. */ const char *_xattr_strip_name(const char *name) { #if (defined (__APPLE__) || defined (mingw_PLATFORM)) return name; #else if (strstr(name, "user.") == name) return name + 5; else return NULL; #endif } I can certainly change it to do whatever is the correct answer on FreeBSD. It looks like for FUSE with MacOS and Windows, they expect just the attribute name without a namespace prefix. > - If you stick with prepending "user." or "system." there needs to be > some way to bypass this so that attributes that don't start in "user." > or "system." can be accessed. I've seen "trusted." and "glusterfs." > on GlusterFS. > --> Maybe a new namespace called something like "nil" that just bypasses > any USER or SYSTEM checks? > I'll respond to rwatson's email on this part... Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@freebsd.org Mon Mar 7 16:19:50 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E38D8AC3DA7 for ; Mon, 7 Mar 2016 16:19:49 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C8BB8B78 for ; Mon, 7 Mar 2016 16:19:49 +0000 (UTC) (envelope-from ken@kdm.org) Received: by mailman.ysv.freebsd.org (Postfix) id C4395AC3DA5; Mon, 7 Mar 2016 16:19:49 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3AEAAC3DA4; Mon, 7 Mar 2016 16:19:49 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 77301B75; Mon, 7 Mar 2016 16:19:49 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id u27GJlr8004486 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Mar 2016 11:19:47 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id u27GJl2A004485; Mon, 7 Mar 2016 11:19:47 -0500 (EST) (envelope-from ken) Date: Mon, 7 Mar 2016 11:19:47 -0500 From: "Kenneth D. Merry" To: Julian Elischer Cc: Rick Macklem , Robert Watson , fs@freebsd.org, scsi@freebsd.org Subject: Re: FUSE extended attribute patches available Message-ID: <20160307161947.GB3501@mithlond.kdm.org> References: <800018199.6694281.1457233600357.JavaMail.zimbra@uoguelph.ca> <56DD2AB6.1030407@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56DD2AB6.1030407@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Mon, 07 Mar 2016 11:19:47 -0500 (EST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 16:19:50 -0000 On Sun, Mar 06, 2016 at 23:16:06 -0800, Julian Elischer wrote: > On 5/03/2016 7:06 PM, Rick Macklem wrote: > > Ken Merry wrote: > >> I have patches for FreeBSD???s FUSE filesystem kernel module to support > >> extended attributes: > oh showing off your masochistic side eh? I suppose so; it was rather slow going to figure out the interface. More documentation on the interface would be helpful. Even a more clearly structured interface would be helpful. > >> https://people.freebsd.org/~ken/fuse_extattr.20160229.1.txt > >> > I spent an hour beating my head against fuse yesterday. > then realised that it's an old version on our product. We really have > to get off 8.0 > (hopefully a matter of weeks now to a 10.x switch) > Now all I need is to find a FreeBSD filesystem expert > (ZFS/NFS/CIFS/GFS) to hire. I'm sure you know a few, you'll just have to persuade someone. > > The only bit of code I have that might be useful for this patch is: > > case FUSE_GETXATTR: > > case FUSE_LISTXATTR: > > ! /* > > ! * These can have varying response lengths, and 0 length > > ! * isn't necessarily invalid. > > ! */ > > ! err = 0; > > *** I came up with this: > > fgin = (struct fuse_getxattr_in *) > > ((char *)ftick->tk_ms_fiov.base + > > sizeof(struct fuse_in_header)); > > if (fgin->size == 0) > > err = (blen == sizeof(struct fuse_getxattr_out)) ? 0 : > > EINVAL; > > else > > err = (blen <= fgin->size) ? 0 : EINVAL; > > break; > > I think I got the size check right? > > > > The big question is... > > What to do with the NAMESPACE? > > - My code fails for SYSTEM and does USER without prepending "user.". > > (That seemed to be what rwatson@ felt was reasonable. I thought our > > discussion was on a mailing list, but I can't find it.) > > I've cc'd him. Maybe he can comment again. > Is there a standard for extended attributes I should knwo about? > It seems to me that it's a bit like the wild west. > Extended attributes seem to be "every OS for himself". It does appear to be somewhat OS-dependent. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@freebsd.org Mon Mar 7 22:28:23 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9B5CAC7C68 for ; Mon, 7 Mar 2016 22:28:23 +0000 (UTC) (envelope-from ken@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B515781B for ; Mon, 7 Mar 2016 22:28:23 +0000 (UTC) (envelope-from ken@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id AD3B5AC7C66; Mon, 7 Mar 2016 22:28:23 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94305AC7C64; Mon, 7 Mar 2016 22:28:23 +0000 (UTC) (envelope-from ken@freebsd.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 65C9C817; Mon, 7 Mar 2016 22:28:23 +0000 (UTC) (envelope-from ken@freebsd.org) Received: from [10.0.0.27] (mbp2013-wired.int.kdm.org [10.0.0.27]) (authenticated bits=0) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPSA id u27MSGvD009626 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Mar 2016 17:28:21 -0500 (EST) (envelope-from ken@freebsd.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: FUSE extended attribute patches available From: Ken Merry In-Reply-To: <6AF0FC23-CC34-43EA-A008-9FB82FB21558@FreeBSD.org> Date: Mon, 7 Mar 2016 17:28:16 -0500 Cc: Julian Elischer , Rick Macklem , fs@freebsd.org, scsi@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <800018199.6694281.1457233600357.JavaMail.zimbra@uoguelph.ca> <56DD2AB6.1030407@freebsd.org> <6AF0FC23-CC34-43EA-A008-9FB82FB21558@FreeBSD.org> To: Robert Watson X-Mailer: Apple Mail (2.3112) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [96.89.93.250]); Mon, 07 Mar 2016 17:28:21 -0500 (EST) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 22:28:23 -0000 > On Mar 7, 2016, at 2:59 AM, Robert Watson wrote: >=20 > FreeBSD and Linux=E2=80=99s extended-attribute models were inherited = from IRIX, as they were introduced to solve the same problems: a place = to metadata such as ACLs, MAC labels, capability masks, etc. IRIX had = three namespaces: one each for =E2=80=9Cuser=E2=80=9D, =E2=80=9Croot=E2=80= =9D, and =E2=80=9Csecure=E2=80=9D, reflecting whether or not they were = managed by the file owner (or permissions), the privileged root user, or = part of the TCB protection mechanism (e.g., for integrity labels). >=20 > These extended attributes should not be confused with the filesystem = feature of the same name in NFSv4, which is sometimes known by the name = =E2=80=9Cfile fork=E2=80=9D or =E2=80=9Cdata streams=E2=80=9D. EAs in = IRIX/FreeBSD/Linux/HPFS/etc are tuple pairs of names and values intended = to be written atomically or updated in place specifically for (shortish) = metadata such as ACLs, rather than being complete separate data spaces = for I/O (e.g., that could be memory mapped). It would be nice to have NFSv4 / Solaris style alternate data streams. = ZFS handles them already, but I suppose it would take more work to = support them in UFS. > In FreeBSD=E2=80=99s design, we incorporated the disjoint namespace = model, providing USER and SYSTEM, the former being managed by the file = owner (and those given suitable permission), and the latter being used = for TCB mechanisms such as the implementations of MAC labels, ACLs, etc. >=20 > In Linux, they adopted a more free-form mechanism based on a single = combined namespace with a prefix =E2=80=94 e.g., user.FOO, and = system.BAR. Over time it looks like that namespace has been expanded in = various filesystem-specific ways. We also have room to expand our = namespace, but from the description below, it=E2=80=99s not clear quite = what the right mechanism is. >=20 > One path would be to introduce a new namespace for filesystem-specific = attributes =E2=80=94 e.g., EXTATTR_NAMESPACE_FS? >=20 > But I think the key question here is whether the existing namespaces = can provide the semantics you need. If not, then we likely need a new = namespace. But then we get the question as to who controls use of the = namespace. Certainly =E2=80=9Cthe filesystem=E2=80=9D is one option, but = then you will get inconsistency in approaches between filesystems and = applications =E2=80=94 across various dimensions including protection = (who can read/modify them?), allocation (who decides what names should = be used for what?), and semantics (what applications can use them, and = who backs them up?). >=20 > For example: who should be responsible for backing up those = attributes? For =E2=80=98system=E2=80=99 attributes in FreeBSD, it is = assumed that backup tools will be aware of the services layered over the = attributes =E2=80=94 e.g., that they will back up ACLs using the ACL = API, rather than backing up the binary EAs holding the ACLs. For = =E2=80=98user=E2=80=99 attributes, it is assumed that backup tools = (e.g., tar) must explicitly preserve them, since they are user-defined = and user-managed. For filesystem-specific attributes, some other choice = will need to be made =E2=80=94 perhaps filesystem-specific backup tools = need to know about them? >=20 > Note that in the Linux EA model, ACLs are actually accessed via the EA = system calls, whereas in FreeBSD, ACLs are a first-class citizen in the = system-call API/ABI, and so user applications don=E2=80=99t treat them = as EAs. We made that choice as filesystems may choose themselves not to = represent ACLs as EAs, and they have real semantics visible to the VFS = layer. In Linux, I believe they chose to pass them via EAs to narrow the = system-call interface for filesystem metadata. Both are legitimate = choices, but this could also trigger discussions about whether new = attributes are best accessed via the EA interface, or new system calls. = For filesystem-specific attributes, EAs are likely the better way to go. It may be that for at least the purposes of FUSE, we can adequately live = under the USER namespace. That would allow for arbitrary namespaces = that Linux-centric filesystems create without significant churn in = FreeBSD to support it. And of course this is only for the front/top end of a FUSE filesystem. = What the filesystem actually does with the extended attributes that the = user sets on top is another question altogether. In the case of IBM=E2=80= =99s LTFS, it stores extended attributes (without the =E2=80=9Cuser.=E2=80= =9D prefix) in the LTFS index, which is an XML file that resides on = tape. For other filesystems, the answer could also vary significantly. = A few that I examined in sysutils/fusefs* used extended attributes on = the backend (usually on a backing filesystem) under Linux only, but not = on the front (user facing) end. In order to make arbitrary namespaces in FUSE work in FreeBSD under the = user namespace, we=E2=80=99ll have to do what Rick was talking about and = just not include the namespace as a prefix when we get/set attributes. = This will allow using any sort of namespace or attribute name that the = FUSE filesystem wants to use. The impact of this, from a porting standpoint, is that the FUSE = filesystems will have to know that on FreeBSD, they cannot/should not = expect to see the =E2=80=9Cuser.=E2=80=9D namespace prefix, but they = might see other namespace prefixes. I took a look at the way LTFS and Gluster work with respect to extended = attributes with MacOS, since it seems that is how MacOS works, and = it=E2=80=99s less obvious to me what is going on with Gluster. = They=E2=80=99ve got this function: #ifdef GF_DARWIN_HOST_OS static int set_xattr_user_namespace_mode (struct posix_private *priv, const char = *str) { if (strcmp (str, "none") =3D=3D 0) priv->xattr_user_namespace =3D XATTR_NONE; else if (strcmp (str, "strip") =3D=3D 0) priv->xattr_user_namespace =3D XATTR_STRIP; else if (strcmp (str, "append") =3D=3D 0) priv->xattr_user_namespace =3D XATTR_APPEND; else if (strcmp (str, "both") =3D=3D 0) priv->xattr_user_namespace =3D XATTR_BOTH; else return -1; return 0; } #endif =20 Although it=E2=80=99s not clear that they do anything with values other = than XATTR_STRIP.=20 With LTFS, since they either assume a =E2=80=9Cuser.=E2=80=9D prefix on = Linux, or no prefix on Windows and MacOS X, it=E2=80=99s more = straightforward. Ken >=20 > Robert >=20 >> On 7 Mar 2016, at 07:16, Julian Elischer wrote: >>=20 >> On 5/03/2016 7:06 PM, Rick Macklem wrote: >>> Ken Merry wrote: >>>> I have patches for FreeBSD=E2=80=99s FUSE filesystem kernel module = to support >>>> extended attributes: >> oh showing off your masochistic side eh? >>=20 >>>> https://people.freebsd.org/~ken/fuse_extattr.20160229.1.txt >>>>=20 >> I spent an hour beating my head against fuse yesterday. >> then realised that it's an old version on our product. We really have = to get off 8.0 >> (hopefully a matter of weeks now to a 10.x switch) >> Now all I need is to find a FreeBSD filesystem expert = (ZFS/NFS/CIFS/GFS) to hire. >>=20 >>=20 >>> The only bit of code I have that might be useful for this patch is: >>> case FUSE_GETXATTR: >>> case FUSE_LISTXATTR: >>> ! /* >>> ! * These can have varying response lengths, and 0 length >>> ! * isn't necessarily invalid. >>> ! */ >>> ! err =3D 0; >>> *** I came up with this: >>> fgin =3D (struct fuse_getxattr_in *) >>> ((char *)ftick->tk_ms_fiov.base + >>> sizeof(struct fuse_in_header)); >>> if (fgin->size =3D=3D 0) >>> err =3D (blen =3D=3D sizeof(struct = fuse_getxattr_out)) ? 0 : >>> EINVAL; >>> else >>> err =3D (blen <=3D fgin->size) ? 0 : EINVAL; >>> break; >>> I think I got the size check right? >>>=20 >>> The big question is... >>> What to do with the NAMESPACE? >>> - My code fails for SYSTEM and does USER without prepending "user.". >>> (That seemed to be what rwatson@ felt was reasonable. I thought our >>> discussion was on a mailing list, but I can't find it.) >>> I've cc'd him. Maybe he can comment again. >> Is there a standard for extended attributes I should knwo about? >> It seems to me that it's a bit like the wild west. >> Extended attributes seem to be "every OS for himself". >>=20 >>>=20 >>> - If you stick with prepending "user." or "system." there needs to = be >>> some way to bypass this so that attributes that don't start in = "user." >>> or "system." can be accessed. I've seen "trusted." and "glusterfs." >>> on GlusterFS. >>> --> Maybe a new namespace called something like "nil" that just = bypasses >>> any USER or SYSTEM checks? >>>=20 >>> rick >>>=20 >>>> The patch implements the get/set/delete/list extended attribute = methods. The >>>> listing code also converts extended attribute lists from the = Linux/FUSE >>>> format to the FreeBSD format. For example: >>>>=20 >>>> # touch foo >>>> # ls -la foo >>>> -rwxrwxrwx 1 root wheel 0 Feb 29 21:40 foo >>>> # lsextattr user foo >>>> foo >>>> # setextattr user testattr1 "12345678" foo >>>> # lsextattr user foo >>>> foo testattr1 >>>> # getextattr user testattr1 foo >>>> foo 12345678 >>>> # setextattr user testattr2 "87654321" foo >>>> # lsextattr user foo >>>> foo testattr2 testattr1 >>>> # rmextattr user testattr1 foo >>>> # lsextattr user foo >>>> foo testattr2 >>>> # getextattr user testattr1 foo >>>> getextattr: foo: failed: Attribute not found >>>> # getextattr user testattr2 foo >>>> foo 87654321 >>>>=20 >>>>=20 >>>> Just to be clear on what this does, it only provides extended = attribute >>>> support to FreeBSD applications if the underlying FUSE filesystem = implements >>>> FUSE extended attribute support. Many FUSE filesystems don=E2=80=99t= support the >>>> extended attribute VFS operations. >>>>=20 >>>> I have tested this out on IBM=E2=80=99s LTFS implementation, but I = have not yet found >>>> another FUSE filesystem that supports extended attributes. If = anyone knows >>>> of one, please let me know so I can try it out. (I looked through = a number >>>> of the filesystems in sysutils/fusefs* in the ports tree.) >>>>=20 >>>> Any feedback is welcome. I=E2=80=99m planning to check this into = FreeBSD/head in the >>>> next week or so. >>>>=20 >>>> Obviously, I=E2=80=99ve also ported IBM=E2=80=99s LTFS = implementation to FreeBSD. It works >>>> in the standard FUSE mode, and you can also link it into an = application as a >>>> library if you don=E2=80=99t want to incur the overhead of running = through FUSE. I >>>> haven=E2=80=99t gotten around to packaging it up to go out for = testing / review. >>>>=20 >>>> If anyone has IBM LTO-5 or newer tape drives, or IBM TS1140 or = newer tape >>>> drives, and wants to try it out, let me know. I=E2=80=99ll send = you the code when >>>> I=E2=80=99ve got it at least somewhat ready. This is IBM-specific, = and won=E2=80=99t work >>>> on HP tape drives. >>>>=20 >>>> Ken >>>> =E2=80=94 >>>> Ken Merry >>>> ken@FreeBSD.ORG >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> freebsd-fs@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-fs >>>> To unsubscribe, send any mail to = "freebsd-fs-unsubscribe@freebsd.org" >>> _______________________________________________ >>> freebsd-fs@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-fs >>> To unsubscribe, send any mail to = "freebsd-fs-unsubscribe@freebsd.org" >>>=20 >>>=20 >>=20 >=20 =E2=80=94=20 Ken Merry ken@FreeBSD.ORG From owner-freebsd-scsi@freebsd.org Tue Mar 8 02:39:17 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0788AC27B6 for ; Tue, 8 Mar 2016 02:39:17 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BFCF59CB for ; Tue, 8 Mar 2016 02:39:17 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: by mailman.ysv.freebsd.org (Postfix) id B9EF8AC27B3; Tue, 8 Mar 2016 02:39:17 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F6ABAC27B2; Tue, 8 Mar 2016 02:39:17 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id E57639C7; Tue, 8 Mar 2016 02:39:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:Y3V1BhLIKxFVs8tnhNmcpTZWNBhigK39O0sv0rFitYgVKPTxwZ3uMQTl6Ol3ixeRBMOAu60C27Cd7/2ocFdDyKjCmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWM5DIfUi/yKRBybrysXNWC0ILnjavuptX6WEZhunmUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD89pozcNLUL37cqIkVvQYSW1+ayFmrPDtrgTJGAuT+mMHACJRlhtTHxOD4gv3U53qvm39rOU63SCbOcj/S/cwWC++7qFlT1jmkioKPSU1tW/M2fB32YFWplqEqgZl0saAY4yTHPRkc67XZt9cQnBOCJV/TStEV7m9ZIhHKuMKPuJVqsGpvV4Hphi6CAyEGeTg1zJMnn+w1qRsgLdpKh3PwAF1R4FGi3/Tttigcf5KCe0= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DQAQCeOt5W/61jaINcFoN2bQa6QgENgWkXCoUkSgKBbBQBAQEBAQEBAWMngi2CFAEBAQMBAQEBIAQnHQMLEAIBCBgCAg0ZAgInAQkYAQ0CBAgHBAEcAgKHewgOrxePOAEBAQEBBQEBAQEBARp7hRyBd4FJfYQBGgEBG4MCgToFh1iFWHQ9iEmFY4JwgjKETEuDeYMlhS6OUwIeAQFChAIeLgEBAQSIRjR+AQEB X-IronPort-AV: E=Sophos;i="5.22,554,1449550800"; d="scan'208";a="269546410" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 07 Mar 2016 21:39:08 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id D1A2515F56D; Mon, 7 Mar 2016 21:39:08 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id N14dMD25e0Sp; Mon, 7 Mar 2016 21:39:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 5E0F315F571; Mon, 7 Mar 2016 21:39:07 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9Lr9r1Ia1djW; Mon, 7 Mar 2016 21:39:07 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 3C7BD15F56D; Mon, 7 Mar 2016 21:39:07 -0500 (EST) Date: Mon, 7 Mar 2016 21:39:07 -0500 (EST) From: Rick Macklem To: Ken Merry Cc: Robert Watson , Julian Elischer , fs@freebsd.org, scsi@freebsd.org Message-ID: <436595384.8930140.1457404747058.JavaMail.zimbra@uoguelph.ca> In-Reply-To: References: <800018199.6694281.1457233600357.JavaMail.zimbra@uoguelph.ca> <56DD2AB6.1030407@freebsd.org> <6AF0FC23-CC34-43EA-A008-9FB82FB21558@FreeBSD.org> Subject: Re: FUSE extended attribute patches available MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF44 (Win)/8.0.9_GA_6191) Thread-Topic: FUSE extended attribute patches available Thread-Index: 8umvwGT6Jzla+wnY64CVfII3kq5mdA== X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 02:39:18 -0000 Ken Merry wrote: >=20 >=20 > > On Mar 7, 2016, at 2:59 AM, Robert Watson wrote: > >=20 > > FreeBSD and Linux=E2=80=99s extended-attribute models were inherited fr= om IRIX, as > > they were introduced to solve the same problems: a place to metadata su= ch > > as ACLs, MAC labels, capability masks, etc. IRIX had three namespaces: = one > > each for =E2=80=9Cuser=E2=80=9D, =E2=80=9Croot=E2=80=9D, and =E2=80=9Cs= ecure=E2=80=9D, reflecting whether or not they were > > managed by the file owner (or permissions), the privileged root user, o= r > > part of the TCB protection mechanism (e.g., for integrity labels). > >=20 > > These extended attributes should not be confused with the filesystem > > feature of the same name in NFSv4, which is sometimes known by the name > > =E2=80=9Cfile fork=E2=80=9D or =E2=80=9Cdata streams=E2=80=9D. EAs in I= RIX/FreeBSD/Linux/HPFS/etc are > > tuple pairs of names and values intended to be written atomically or > > updated in place specifically for (shortish) metadata such as ACLs, rat= her > > than being complete separate data spaces for I/O (e.g., that could be > > memory mapped). >=20 > It would be nice to have NFSv4 / Solaris style alternate data streams. Z= FS > handles them already, but I suppose it would take more work to support th= em > in UFS. >=20 When this was discussed previously, Jordan Hubbard pointed out that most of= the work is making sure the userland utilities (like backup utilities...) know = about them and what to do with them. I am not familiar with the userland issue, but if that was resolved, person= ally, I don't think a lack of support in UFS would be a showstopper. (Assuming that it would be= an addition and not a replacement for extended attributes.) I do recall that someone at Cern is adamant about this. (I think they creat= e file forks with Gbytes of data and can't live without them.) > > In FreeBSD=E2=80=99s design, we incorporated the disjoint namespace mod= el, > > providing USER and SYSTEM, the former being managed by the file owner (= and > > those given suitable permission), and the latter being used for TCB > > mechanisms such as the implementations of MAC labels, ACLs, etc. > >=20 > > In Linux, they adopted a more free-form mechanism based on a single > > combined namespace with a prefix =E2=80=94 e.g., user.FOO, and system.B= AR. Over > > time it looks like that namespace has been expanded in various > > filesystem-specific ways. We also have room to expand our namespace, bu= t > > from the description below, it=E2=80=99s not clear quite what the right= mechanism > > is. > >=20 > > One path would be to introduce a new namespace for filesystem-specific > > attributes =E2=80=94 e.g., EXTATTR_NAMESPACE_FS? > >=20 > > But I think the key question here is whether the existing namespaces ca= n > > provide the semantics you need. If not, then we likely need a new > > namespace. But then we get the question as to who controls use of the > > namespace. Certainly =E2=80=9Cthe filesystem=E2=80=9D is one option, bu= t then you will get > > inconsistency in approaches between filesystems and applications =E2=80= =94 across > > various dimensions including protection (who can read/modify them?), > > allocation (who decides what names should be used for what?), and > > semantics (what applications can use them, and who backs them up?). > >=20 > > For example: who should be responsible for backing up those attributes?= For > > =E2=80=98system=E2=80=99 attributes in FreeBSD, it is assumed that back= up tools will be > > aware of the services layered over the attributes =E2=80=94 e.g., that = they will > > back up ACLs using the ACL API, rather than backing up the binary EAs > > holding the ACLs. For =E2=80=98user=E2=80=99 attributes, it is assumed = that backup tools > > (e.g., tar) must explicitly preserve them, since they are user-defined = and > > user-managed. For filesystem-specific attributes, some other choice wil= l > > need to be made =E2=80=94 perhaps filesystem-specific backup tools need= to know > > about them? > >=20 > > Note that in the Linux EA model, ACLs are actually accessed via the EA > > system calls, whereas in FreeBSD, ACLs are a first-class citizen in the > > system-call API/ABI, and so user applications don=E2=80=99t treat them = as EAs. We > > made that choice as filesystems may choose themselves not to represent > > ACLs as EAs, and they have real semantics visible to the VFS layer. In > > Linux, I believe they chose to pass them via EAs to narrow the system-c= all > > interface for filesystem metadata. Both are legitimate choices, but thi= s > > could also trigger discussions about whether new attributes are best > > accessed via the EA interface, or new system calls. For > > filesystem-specific attributes, EAs are likely the better way to go. >=20 > It may be that for at least the purposes of FUSE, we can adequately live > under the USER namespace. That would allow for arbitrary namespaces that > Linux-centric filesystems create without significant churn in FreeBSD to > support it. >=20 > And of course this is only for the front/top end of a FUSE filesystem. W= hat > the filesystem actually does with the extended attributes that the user s= ets > on top is another question altogether. In the case of IBM=E2=80=99s LTFS= , it stores > extended attributes (without the =E2=80=9Cuser.=E2=80=9D prefix) in the L= TFS index, which is > an XML file that resides on tape. For other filesystems, the answer coul= d > also vary significantly. A few that I examined in sysutils/fusefs* used > extended attributes on the backend (usually on a backing filesystem) unde= r > Linux only, but not on the front (user facing) end. >=20 > In order to make arbitrary namespaces in FUSE work in FreeBSD under the u= ser > namespace, we=E2=80=99ll have to do what Rick was talking about and just = not include > the namespace as a prefix when we get/set attributes. This will allow us= ing > any sort of namespace or attribute name that the FUSE filesystem wants to > use. >=20 > The impact of this, from a porting standpoint, is that the FUSE filesyste= ms > will have to know that on FreeBSD, they cannot/should not expect to see t= he > =E2=80=9Cuser.=E2=80=9D namespace prefix, but they might see other namesp= ace prefixes. >=20 > I took a look at the way LTFS and Gluster work with respect to extended > attributes with MacOS, since it seems that is how MacOS works, and it=E2= =80=99s less > obvious to me what is going on with Gluster. They=E2=80=99ve got this fu= nction: >=20 > #ifdef GF_DARWIN_HOST_OS > static int > set_xattr_user_namespace_mode (struct posix_private *priv, const char *st= r) > { > if (strcmp (str, "none") =3D=3D 0) > priv->xattr_user_namespace =3D XATTR_NONE; > else if (strcmp (str, "strip") =3D=3D 0) > priv->xattr_user_namespace =3D XATTR_STRIP; > else if (strcmp (str, "append") =3D=3D 0) > priv->xattr_user_namespace =3D XATTR_APPEND; > else if (strcmp (str, "both") =3D=3D 0) > priv->xattr_user_namespace =3D XATTR_BOTH; > else > return -1; > return 0; > } > #endif >=20 > Although it=E2=80=99s not clear that they do anything with values other t= han > XATTR_STRIP. >=20 > With LTFS, since they either assume a =E2=80=9Cuser.=E2=80=9D prefix on L= inux, or no prefix > on Windows and MacOS X, it=E2=80=99s more straightforward. >=20 > Ken >=20 >=20 > >=20 > > Robert > >=20 > >> On 7 Mar 2016, at 07:16, Julian Elischer wrote: > >>=20 > >> On 5/03/2016 7:06 PM, Rick Macklem wrote: > >>> Ken Merry wrote: > >>>> I have patches for FreeBSD=E2=80=99s FUSE filesystem kernel module t= o support > >>>> extended attributes: > >> oh showing off your masochistic side eh? > >>=20 > >>>> https://people.freebsd.org/~ken/fuse_extattr.20160229.1.txt > >>>>=20 > >> I spent an hour beating my head against fuse yesterday. > >> then realised that it's an old version on our product. We really have = to > >> get off 8.0 > >> (hopefully a matter of weeks now to a 10.x switch) > >> Now all I need is to find a FreeBSD filesystem expert (ZFS/NFS/CIFS/G= FS) > >> to hire. > >>=20 > >>=20 > >>> The only bit of code I have that might be useful for this patch is: > >>> =09case FUSE_GETXATTR: > >>> =09case FUSE_LISTXATTR: > >>> ! =09=09/* > >>> ! =09=09 * These can have varying response lengths, and 0 length > >>> ! =09=09 * isn't necessarily invalid. > >>> ! =09=09 */ > >>> ! =09=09err =3D 0; > >>> *** I came up with this: > >>> =09=09fgin =3D (struct fuse_getxattr_in *) > >>> =09=09 ((char *)ftick->tk_ms_fiov.base + > >>> =09=09 sizeof(struct fuse_in_header)); > >>> =09=09if (fgin->size =3D=3D 0) > >>> =09=09=09err =3D (blen =3D=3D sizeof(struct fuse_getxattr_out)) ? 0 : > >>> =09=09=09 EINVAL; > >>> =09=09else > >>> =09=09=09err =3D (blen <=3D fgin->size) ? 0 : EINVAL; > >>> =09=09break; > >>> I think I got the size check right? > >>>=20 > >>> The big question is... > >>> What to do with the NAMESPACE? > >>> - My code fails for SYSTEM and does USER without prepending "user.". > >>> (That seemed to be what rwatson@ felt was reasonable. I thought our > >>> discussion was on a mailing list, but I can't find it.) > >>> I've cc'd him. Maybe he can comment again. > >> Is there a standard for extended attributes I should knwo about? > >> It seems to me that it's a bit like the wild west. > >> Extended attributes seem to be "every OS for himself". > >>=20 > >>>=20 > >>> - If you stick with prepending "user." or "system." there needs to be > >>> some way to bypass this so that attributes that don't start in "user= ." > >>> or "system." can be accessed. I've seen "trusted." and "glusterfs." > >>> on GlusterFS. > >>> --> Maybe a new namespace called something like "nil" that just bypa= sses > >>> any USER or SYSTEM checks? > >>>=20 > >>> rick > >>>=20 > >>>> The patch implements the get/set/delete/list extended attribute meth= ods. > >>>> The > >>>> listing code also converts extended attribute lists from the Linux/F= USE > >>>> format to the FreeBSD format. For example: > >>>>=20 > >>>> # touch foo > >>>> # ls -la foo > >>>> -rwxrwxrwx 1 root wheel 0 Feb 29 21:40 foo > >>>> # lsextattr user foo > >>>> foo > >>>> # setextattr user testattr1 "12345678" foo > >>>> # lsextattr user foo > >>>> foo testattr1 > >>>> # getextattr user testattr1 foo > >>>> foo 12345678 > >>>> # setextattr user testattr2 "87654321" foo > >>>> # lsextattr user foo > >>>> foo testattr2 testattr1 > >>>> # rmextattr user testattr1 foo > >>>> # lsextattr user foo > >>>> foo testattr2 > >>>> # getextattr user testattr1 foo > >>>> getextattr: foo: failed: Attribute not found > >>>> # getextattr user testattr2 foo > >>>> foo 87654321 > >>>>=20 > >>>>=20 > >>>> Just to be clear on what this does, it only provides extended attrib= ute > >>>> support to FreeBSD applications if the underlying FUSE filesystem > >>>> implements > >>>> FUSE extended attribute support. Many FUSE filesystems don=E2=80=99= t support > >>>> the > >>>> extended attribute VFS operations. > >>>>=20 > >>>> I have tested this out on IBM=E2=80=99s LTFS implementation, but I h= ave not yet > >>>> found > >>>> another FUSE filesystem that supports extended attributes. If anyon= e > >>>> knows > >>>> of one, please let me know so I can try it out. (I looked through a > >>>> number > >>>> of the filesystems in sysutils/fusefs* in the ports tree.) > >>>>=20 > >>>> Any feedback is welcome. I=E2=80=99m planning to check this into Fr= eeBSD/head > >>>> in the > >>>> next week or so. > >>>>=20 > >>>> Obviously, I=E2=80=99ve also ported IBM=E2=80=99s LTFS implementatio= n to FreeBSD. It > >>>> works > >>>> in the standard FUSE mode, and you can also link it into an applicat= ion > >>>> as a > >>>> library if you don=E2=80=99t want to incur the overhead of running t= hrough FUSE. > >>>> I > >>>> haven=E2=80=99t gotten around to packaging it up to go out for testi= ng / review. > >>>>=20 > >>>> If anyone has IBM LTO-5 or newer tape drives, or IBM TS1140 or newer > >>>> tape > >>>> drives, and wants to try it out, let me know. I=E2=80=99ll send you= the code > >>>> when > >>>> I=E2=80=99ve got it at least somewhat ready. This is IBM-specific, = and won=E2=80=99t > >>>> work > >>>> on HP tape drives. > >>>>=20 > >>>> Ken > >>>> =E2=80=94 > >>>> Ken Merry > >>>> ken@FreeBSD.ORG > >>>>=20 > >>>>=20 > >>>>=20 > >>>> _______________________________________________ > >>>> freebsd-fs@freebsd.org mailing list > >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-fs > >>>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org= " > >>> _______________________________________________ > >>> freebsd-fs@freebsd.org mailing list > >>> https://lists.freebsd.org/mailman/listinfo/freebsd-fs > >>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > >>>=20 > >>>=20 > >>=20 > >=20 >=20 >=20 >=20 > =E2=80=94 > Ken Merry > ken@FreeBSD.ORG >=20 >=20 >=20 >=20 From owner-freebsd-scsi@freebsd.org Tue Mar 8 05:26:44 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6919BAC2201 for ; Tue, 8 Mar 2016 05:26:44 +0000 (UTC) (envelope-from jkh@ixsystems.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4954CA99 for ; Tue, 8 Mar 2016 05:26:44 +0000 (UTC) (envelope-from jkh@ixsystems.com) Received: by mailman.ysv.freebsd.org (Postfix) id 46287AC21FE; Tue, 8 Mar 2016 05:26:44 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D883AC21FC for ; Tue, 8 Mar 2016 05:26:44 +0000 (UTC) (envelope-from jkh@ixsystems.com) Received: from barracuda.ixsystems.com (barracuda.ixsystems.com [12.229.62.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED2D2A91 for ; Tue, 8 Mar 2016 05:26:43 +0000 (UTC) (envelope-from jkh@ixsystems.com) X-ASG-Debug-ID: 1457414802-08ca041787e9c60001-ZLaBJh Received: from zimbra.ixsystems.com ([10.246.0.20]) by barracuda.ixsystems.com with ESMTP id ReAiXcRFNUXtr106 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 07 Mar 2016 21:26:42 -0800 (PST) X-Barracuda-Envelope-From: jkh@ixsystems.com X-Barracuda-RBL-Trusted-Forwarder: 10.246.0.20 X-ASG-Whitelist: Client Received: from localhost (localhost [127.0.0.1]) by zimbra.ixsystems.com (Postfix) with ESMTP id 3E021A24AAF; Mon, 7 Mar 2016 21:26:42 -0800 (PST) Received: from zimbra.ixsystems.com ([127.0.0.1]) by localhost (zimbra.ixsystems.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id TWPhxT75OqFO; Mon, 7 Mar 2016 21:26:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.ixsystems.com (Postfix) with ESMTP id E80E7A24AB0; Mon, 7 Mar 2016 21:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at ixsystems.com Received: from zimbra.ixsystems.com ([127.0.0.1]) by localhost (zimbra.ixsystems.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id L6ilLv6SRbv8; Mon, 7 Mar 2016 21:26:41 -0800 (PST) Received: from [10.8.0.34] (unknown [10.8.0.34]) by zimbra.ixsystems.com (Postfix) with ESMTPSA id 702ABA24AA9; Mon, 7 Mar 2016 21:26:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: FUSE extended attribute patches available From: Jordan Hubbard X-ASG-Orig-Subj: Re: FUSE extended attribute patches available In-Reply-To: <6AF0FC23-CC34-43EA-A008-9FB82FB21558@FreeBSD.org> Date: Mon, 7 Mar 2016 21:26:42 -0800 Cc: Julian Elischer , Ken Merry , fs@freebsd.org, scsi@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <536B3B67-E8F6-472C-8A2C-8884533B4CB6@ixsystems.com> References: <800018199.6694281.1457233600357.JavaMail.zimbra@uoguelph.ca> <56DD2AB6.1030407@freebsd.org> <6AF0FC23-CC34-43EA-A008-9FB82FB21558@FreeBSD.org> To: Robert Watson X-Mailer: Apple Mail (2.3124) X-Barracuda-Connect: UNKNOWN[10.246.0.20] X-Barracuda-Start-Time: 1457414802 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://10.246.0.26:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 05:26:44 -0000 > On Mar 6, 2016, at 11:59 PM, Robert Watson = wrote: >=20 > For example: who should be responsible for backing up those = attributes? For =E2=80=98system=E2=80=99 attributes in FreeBSD, it is = assumed that backup tools will be aware of the services layered over the = attributes =E2=80=94 e.g., that they will back up ACLs using the ACL = API, rather than backing up the binary EAs holding the ACLs. For = =E2=80=98user=E2=80=99 attributes, it is assumed that backup tools = (e.g., tar) must explicitly preserve them, since they are user-defined = and user-managed. For filesystem-specific attributes, some other choice = will need to be made =E2=80=94 perhaps filesystem-specific backup tools = need to know about them? As Rick observed, the last time this came up, I pointed out that = teaching all possible =E2=80=9Carchivers=E2=80=9D of filesystem = information (which includes serializers, like rsync / scp / etc) how to = cope gracefully with EAs and ACLs, even if you stick ACLs in an EA = system namespace and make them opaque blobs, is =E2=80=9Chard=E2=80=9D = and it=E2=80=99s the edge/legacy cases that really hose you. This is why Apple chose to split the problem space between =E2=80=9Cthings= that are capable of dealing with the problem natively=E2=80=9D = (abstracting that native understanding behind the copyfile(3) APIs), = which is a comparatively small number of tools, and =E2=80=9Ceverything = else=E2=80=9D which gets all of its metadata serialized into an = AppleDouble file. Yes, those are the ._* files you see when you copy a = bunch of files off your Mac onto a filesystem that doesn=E2=80=99t know = how to cope with the metadata. The extra AppleDouble files just sit = around passively on that NTFS or ext2fs filesystem, minding their own = business, until they get copied back to to Mac, at which point something = at the VFS layer (I=E2=80=99m guessing now, I never actually looked) = re-unites the ._Foo file with its corresponding Foo file and the = AppleDouble file disappears. I used to think this was kind of ghetto, then I observed how many = problems it solved in terms of turning data-loss scenarios into =E2=80=9Cn= o big deal, it=E2=80=99ll all work out=E2=80=9D scenarios and I changed = my mind. TL;DR summary: This can be handled in such a way that =E2=80=9Cno one = need be responsible=E2=80=9D for backing up those attributes if you=E2=80=99= re willing to pay the freight. - Jordan From owner-freebsd-scsi@freebsd.org Tue Mar 8 06:38:04 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80938AC3955 for ; Tue, 8 Mar 2016 06:38:04 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6D82B14CA for ; Tue, 8 Mar 2016 06:38:04 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 6A21BAC3950; Tue, 8 Mar 2016 06:38:04 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4FBCFAC394F; Tue, 8 Mar 2016 06:38:04 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 0EA5A14C5; Tue, 8 Mar 2016 06:38:04 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from [10.0.1.9] (host81-157-243-217.range81-157.btcentralplus.com [81.157.243.217]) by cyrus.watson.org (Postfix) with ESMTPSA id BDAB746B64; Tue, 8 Mar 2016 01:38:02 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: FUSE extended attribute patches available From: "Robert N. M. Watson" X-Mailer: iPhone Mail (13D15) In-Reply-To: Date: Tue, 8 Mar 2016 06:38:00 +0000 Cc: Robert Watson , Julian Elischer , Rick Macklem , fs@freebsd.org, scsi@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <800018199.6694281.1457233600357.JavaMail.zimbra@uoguelph.ca> <56DD2AB6.1030407@freebsd.org> <6AF0FC23-CC34-43EA-A008-9FB82FB21558@FreeBSD.org> To: Ken Merry X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 06:38:04 -0000 Just a quick observation: to avoid application change, you could actually le= ave the 'user.' on the front of the strings? It's not harmful, it just doesn= 't serve the same function. This might keep documentation more in sync, etc.= Sent from my iPhone > On 7 Mar 2016, at 22:28, Ken Merry wrote: >=20 >=20 >=20 >> On Mar 7, 2016, at 2:59 AM, Robert Watson wrote: >>=20 >> FreeBSD and Linux=E2=80=99s extended-attribute models were inherited from= IRIX, as they were introduced to solve the same problems: a place to metada= ta such as ACLs, MAC labels, capability masks, etc. IRIX had three namespace= s: one each for =E2=80=9Cuser=E2=80=9D, =E2=80=9Croot=E2=80=9D, and =E2=80=9C= secure=E2=80=9D, reflecting whether or not they were managed by the file own= er (or permissions), the privileged root user, or part of the TCB protection= mechanism (e.g., for integrity labels). >>=20 >> These extended attributes should not be confused with the filesystem feat= ure of the same name in NFSv4, which is sometimes known by the name =E2=80=9C= file fork=E2=80=9D or =E2=80=9Cdata streams=E2=80=9D. EAs in IRIX/FreeBSD/Li= nux/HPFS/etc are tuple pairs of names and values intended to be written atom= ically or updated in place specifically for (shortish) metadata such as ACLs= , rather than being complete separate data spaces for I/O (e.g., that could b= e memory mapped). >=20 > It would be nice to have NFSv4 / Solaris style alternate data streams. ZFS= handles them already, but I suppose it would take more work to support them= in UFS. >=20 >> In FreeBSD=E2=80=99s design, we incorporated the disjoint namespace model= , providing USER and SYSTEM, the former being managed by the file owner (and= those given suitable permission), and the latter being used for TCB mechani= sms such as the implementations of MAC labels, ACLs, etc. >>=20 >> In Linux, they adopted a more free-form mechanism based on a single combi= ned namespace with a prefix =E2=80=94 e.g., user.FOO, and system.BAR. Over t= ime it looks like that namespace has been expanded in various filesystem-spe= cific ways. We also have room to expand our namespace, but from the descript= ion below, it=E2=80=99s not clear quite what the right mechanism is. >>=20 >> One path would be to introduce a new namespace for filesystem-specific at= tributes =E2=80=94 e.g., EXTATTR_NAMESPACE_FS? >>=20 >> But I think the key question here is whether the existing namespaces can p= rovide the semantics you need. If not, then we likely need a new namespace. B= ut then we get the question as to who controls use of the namespace. Certain= ly =E2=80=9Cthe filesystem=E2=80=9D is one option, but then you will get inc= onsistency in approaches between filesystems and applications =E2=80=94 acro= ss various dimensions including protection (who can read/modify them?), allo= cation (who decides what names should be used for what?), and semantics (wha= t applications can use them, and who backs them up?). >>=20 >> For example: who should be responsible for backing up those attributes? Fo= r =E2=80=98system=E2=80=99 attributes in FreeBSD, it is assumed that backup t= ools will be aware of the services layered over the attributes =E2=80=94 e.g= ., that they will back up ACLs using the ACL API, rather than backing up the= binary EAs holding the ACLs. For =E2=80=98user=E2=80=99 attributes, it is a= ssumed that backup tools (e.g., tar) must explicitly preserve them, since th= ey are user-defined and user-managed. For filesystem-specific attributes, so= me other choice will need to be made =E2=80=94 perhaps filesystem-specific b= ackup tools need to know about them? >>=20 >> Note that in the Linux EA model, ACLs are actually accessed via the EA sy= stem calls, whereas in FreeBSD, ACLs are a first-class citizen in the system= -call API/ABI, and so user applications don=E2=80=99t treat them as EAs. We m= ade that choice as filesystems may choose themselves not to represent ACLs a= s EAs, and they have real semantics visible to the VFS layer. In Linux, I be= lieve they chose to pass them via EAs to narrow the system-call interface fo= r filesystem metadata. Both are legitimate choices, but this could also trig= ger discussions about whether new attributes are best accessed via the EA in= terface, or new system calls. For filesystem-specific attributes, EAs are li= kely the better way to go. >=20 > It may be that for at least the purposes of FUSE, we can adequately live u= nder the USER namespace. That would allow for arbitrary namespaces that Lin= ux-centric filesystems create without significant churn in FreeBSD to suppor= t it. >=20 > And of course this is only for the front/top end of a FUSE filesystem. Wh= at the filesystem actually does with the extended attributes that the user s= ets on top is another question altogether. In the case of IBM=E2=80=99s LTFS= , it stores extended attributes (without the =E2=80=9Cuser.=E2=80=9D prefix)= in the LTFS index, which is an XML file that resides on tape. For other fi= lesystems, the answer could also vary significantly. A few that I examined i= n sysutils/fusefs* used extended attributes on the backend (usually on a bac= king filesystem) under Linux only, but not on the front (user facing) end. >=20 > In order to make arbitrary namespaces in FUSE work in FreeBSD under the us= er namespace, we=E2=80=99ll have to do what Rick was talking about and just n= ot include the namespace as a prefix when we get/set attributes. This will a= llow using any sort of namespace or attribute name that the FUSE filesystem w= ants to use. >=20 > The impact of this, from a porting standpoint, is that the FUSE filesystem= s will have to know that on FreeBSD, they cannot/should not expect to see th= e =E2=80=9Cuser.=E2=80=9D namespace prefix, but they might see other namespa= ce prefixes. >=20 > I took a look at the way LTFS and Gluster work with respect to extended at= tributes with MacOS, since it seems that is how MacOS works, and it=E2=80=99= s less obvious to me what is going on with Gluster. They=E2=80=99ve got thi= s function: >=20 > #ifdef GF_DARWIN_HOST_OS > static int > set_xattr_user_namespace_mode (struct posix_private *priv, const char *str= ) > { > if (strcmp (str, "none") =3D=3D 0) > priv->xattr_user_namespace =3D XATTR_NONE; > else if (strcmp (str, "strip") =3D=3D 0) > priv->xattr_user_namespace =3D XATTR_STRIP; > else if (strcmp (str, "append") =3D=3D 0) > priv->xattr_user_namespace =3D XATTR_APPEND; > else if (strcmp (str, "both") =3D=3D 0) > priv->xattr_user_namespace =3D XATTR_BOTH; > else > return -1; > return 0; > } > #endif =20 >=20 > Although it=E2=80=99s not clear that they do anything with values other th= an XATTR_STRIP.=20 >=20 > With LTFS, since they either assume a =E2=80=9Cuser.=E2=80=9D prefix on Li= nux, or no prefix on Windows and MacOS X, it=E2=80=99s more straightforward.= >=20 > Ken >=20 >=20 >>=20 >> Robert >>=20 >>> On 7 Mar 2016, at 07:16, Julian Elischer wrote: >>>=20 >>> On 5/03/2016 7:06 PM, Rick Macklem wrote: >>>> Ken Merry wrote: >>>>> I have patches for FreeBSD=E2=80=99s FUSE filesystem kernel module to s= upport >>>>> extended attributes: >>> oh showing off your masochistic side eh? >>>=20 >>>>> https://people.freebsd.org/~ken/fuse_extattr.20160229.1.txt >>> I spent an hour beating my head against fuse yesterday. >>> then realised that it's an old version on our product. We really have to= get off 8.0 >>> (hopefully a matter of weeks now to a 10.x switch) >>> Now all I need is to find a FreeBSD filesystem expert (ZFS/NFS/CIFS/GFS= ) to hire. >>>=20 >>>=20 >>>> The only bit of code I have that might be useful for this patch is: >>>> case FUSE_GETXATTR: >>>> case FUSE_LISTXATTR: >>>> ! /* >>>> ! * These can have varying response lengths, and 0 length >>>> ! * isn't necessarily invalid. >>>> ! */ >>>> ! err =3D 0; >>>> *** I came up with this: >>>> fgin =3D (struct fuse_getxattr_in *) >>>> ((char *)ftick->tk_ms_fiov.base + >>>> sizeof(struct fuse_in_header)); >>>> if (fgin->size =3D=3D 0) >>>> err =3D (blen =3D=3D sizeof(struct fuse_getxattr_out)) ? 0 := >>>> EINVAL; >>>> else >>>> err =3D (blen <=3D fgin->size) ? 0 : EINVAL; >>>> break; >>>> I think I got the size check right? >>>>=20 >>>> The big question is... >>>> What to do with the NAMESPACE? >>>> - My code fails for SYSTEM and does USER without prepending "user.". >>>> (That seemed to be what rwatson@ felt was reasonable. I thought our >>>> discussion was on a mailing list, but I can't find it.) >>>> I've cc'd him. Maybe he can comment again. >>> Is there a standard for extended attributes I should knwo about? >>> It seems to me that it's a bit like the wild west. >>> Extended attributes seem to be "every OS for himself". >>>=20 >>>>=20 >>>> - If you stick with prepending "user." or "system." there needs to be >>>> some way to bypass this so that attributes that don't start in "user." >>>> or "system." can be accessed. I've seen "trusted." and "glusterfs." >>>> on GlusterFS. >>>> --> Maybe a new namespace called something like "nil" that just bypasse= s >>>> any USER or SYSTEM checks? >>>>=20 >>>> rick >>>>=20 >>>>> The patch implements the get/set/delete/list extended attribute method= s. The >>>>> listing code also converts extended attribute lists from the Linux/FUS= E >>>>> format to the FreeBSD format. For example: >>>>>=20 >>>>> # touch foo >>>>> # ls -la foo >>>>> -rwxrwxrwx 1 root wheel 0 Feb 29 21:40 foo >>>>> # lsextattr user foo >>>>> foo >>>>> # setextattr user testattr1 "12345678" foo >>>>> # lsextattr user foo >>>>> foo testattr1 >>>>> # getextattr user testattr1 foo >>>>> foo 12345678 >>>>> # setextattr user testattr2 "87654321" foo >>>>> # lsextattr user foo >>>>> foo testattr2 testattr1 >>>>> # rmextattr user testattr1 foo >>>>> # lsextattr user foo >>>>> foo testattr2 >>>>> # getextattr user testattr1 foo >>>>> getextattr: foo: failed: Attribute not found >>>>> # getextattr user testattr2 foo >>>>> foo 87654321 >>>>>=20 >>>>>=20 >>>>> Just to be clear on what this does, it only provides extended attribut= e >>>>> support to FreeBSD applications if the underlying FUSE filesystem impl= ements >>>>> FUSE extended attribute support. Many FUSE filesystems don=E2=80=99t s= upport the >>>>> extended attribute VFS operations. >>>>>=20 >>>>> I have tested this out on IBM=E2=80=99s LTFS implementation, but I hav= e not yet found >>>>> another FUSE filesystem that supports extended attributes. If anyone k= nows >>>>> of one, please let me know so I can try it out. (I looked through a n= umber >>>>> of the filesystems in sysutils/fusefs* in the ports tree.) >>>>>=20 >>>>> Any feedback is welcome. I=E2=80=99m planning to check this into Free= BSD/head in the >>>>> next week or so. >>>>>=20 >>>>> Obviously, I=E2=80=99ve also ported IBM=E2=80=99s LTFS implementation t= o FreeBSD. It works >>>>> in the standard FUSE mode, and you can also link it into an applicatio= n as a >>>>> library if you don=E2=80=99t want to incur the overhead of running thr= ough FUSE. I >>>>> haven=E2=80=99t gotten around to packaging it up to go out for testing= / review. >>>>>=20 >>>>> If anyone has IBM LTO-5 or newer tape drives, or IBM TS1140 or newer t= ape >>>>> drives, and wants to try it out, let me know. I=E2=80=99ll send you t= he code when >>>>> I=E2=80=99ve got it at least somewhat ready. This is IBM-specific, an= d won=E2=80=99t work >>>>> on HP tape drives. >>>>>=20 >>>>> Ken >>>>> =E2=80=94 >>>>> Ken Merry >>>>> ken@FreeBSD.ORG >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> freebsd-fs@freebsd.org mailing list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-fs >>>>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >>>> _______________________________________________ >>>> freebsd-fs@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-fs >>>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >=20 >=20 >=20 > =E2=80=94=20 > Ken Merry > ken@FreeBSD.ORG >=20 >=20 >=20 From owner-freebsd-scsi@freebsd.org Wed Mar 9 00:27:07 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC0DCAC8FB6 for ; Wed, 9 Mar 2016 00:27:07 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B9AC8933 for ; Wed, 9 Mar 2016 00:27:07 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: by mailman.ysv.freebsd.org (Postfix) id B4277AC8FB4; Wed, 9 Mar 2016 00:27:07 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3900AC8FB3; Wed, 9 Mar 2016 00:27:07 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id E1C0892F; Wed, 9 Mar 2016 00:27:06 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:bBAKzxzyCsua54jXCy+O+j09IxM/srCxBDY+r6Qd0O4SIJqq85mqBkHD//Il1AaPBtWEraIZwLCP+4nbGkU+or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkItf6KuStGU35n8jbn60qaQSjsLrQL1Wal1IhSyoFeZnegtqqwmFJwMzADUqGBDYeVcyDAgD1uSmxHh+pX4p8Y7oGx48sgs/M9YUKj8Y79wDfkBVGxnYCgI4tb2v0zDUReX/SlbFWEXiQZTRQbf4RzwRZu3tTH18e902S2fNMuxSbEvRTWk4aAsRgXlhS0cO3s36zLrjZk6tqVRrQi97zo5i6uSKL6cKOF5eOmVKckFTHZaWcB5WTZMD4mnY80IFeVXbshCqIyonVoFrlObDAKvAO7qgmtSg3b93qk31sw8Fg7b0Qg4H5QFuSKH/53OKK4OXLXtn+HzxjLZYqYTgG+l5Q== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DQAQAqbd9W/61jaINcFoN2bQa6WAENgWkXCoUkSgKBfxQBAQEBAQEBAWMngi2CFAEBAQMBAQEBIAQnHQMLBQsCAQgYAgINGQICJwEJGAENAgQIBwQBHAICh3sIDq9QjykBAQEBAQEEAQEBAQEBGnuFHIF7gUl+hAEaAQEbgko4E4EnBYdYhVh0PYhJhWOCcIIyhE1Lg3mDJYUujlQCHgEBQoQCHi4BAQEEiEY0fgEBAQ X-IronPort-AV: E=Sophos;i="5.22,558,1449550800"; d="scan'208";a="271613761" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-annu.net.uoguelph.ca with ESMTP; 08 Mar 2016 19:26:59 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 12D9015F56D; Tue, 8 Mar 2016 19:26:59 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id jn4MzuIk7hlA; Tue, 8 Mar 2016 19:26:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 5E91215F571; Tue, 8 Mar 2016 19:26:57 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zZm846OeCGHn; Tue, 8 Mar 2016 19:26:57 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 3976515F56D; Tue, 8 Mar 2016 19:26:57 -0500 (EST) Date: Tue, 8 Mar 2016 19:26:57 -0500 (EST) From: Rick Macklem To: "Robert N. M. Watson" Cc: Ken Merry , Robert Watson , Julian Elischer , fs@freebsd.org, scsi@freebsd.org Message-ID: <2091108840.10124858.1457483217137.JavaMail.zimbra@uoguelph.ca> In-Reply-To: References: <800018199.6694281.1457233600357.JavaMail.zimbra@uoguelph.ca> <56DD2AB6.1030407@freebsd.org> <6AF0FC23-CC34-43EA-A008-9FB82FB21558@FreeBSD.org> Subject: Re: FUSE extended attribute patches available MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF44 (Win)/8.0.9_GA_6191) Thread-Topic: FUSE extended attribute patches available Thread-Index: 8OfjVNO8yB/8BPMtb/zoCjB/754qNA== X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 00:27:08 -0000 Robert N. M. Watson wrote: > Just a quick observation: to avoid application change, you could actually > leave the 'user.' on the front of the strings? It's not harmful, it just > doesn't serve the same function. This might keep documentation more in sy= nc, > etc. >=20 Btw, this internet draft was just published. There is work in progress w.r.= t. NFS support for Linux style extended attributes and this draft might have s= omething to say w.r.t. namepsace? (I haven't looked at it.) draft-ietf-nfsv4-xattrs-02.txt Available via anonymous ftp at ftp.ietf.org (I find it amusing that the eng= ineers of the internet still use anonymous ftp;-). rick > Sent from my iPhone >=20 > > On 7 Mar 2016, at 22:28, Ken Merry wrote: > >=20 > >=20 > >=20 > >> On Mar 7, 2016, at 2:59 AM, Robert Watson wrote: > >>=20 > >> FreeBSD and Linux=E2=80=99s extended-attribute models were inherited f= rom IRIX, as > >> they were introduced to solve the same problems: a place to metadata s= uch > >> as ACLs, MAC labels, capability masks, etc. IRIX had three namespaces: > >> one each for =E2=80=9Cuser=E2=80=9D, =E2=80=9Croot=E2=80=9D, and =E2= =80=9Csecure=E2=80=9D, reflecting whether or not they > >> were managed by the file owner (or permissions), the privileged root > >> user, or part of the TCB protection mechanism (e.g., for integrity > >> labels). > >>=20 > >> These extended attributes should not be confused with the filesystem > >> feature of the same name in NFSv4, which is sometimes known by the nam= e > >> =E2=80=9Cfile fork=E2=80=9D or =E2=80=9Cdata streams=E2=80=9D. EAs in = IRIX/FreeBSD/Linux/HPFS/etc are > >> tuple pairs of names and values intended to be written atomically or > >> updated in place specifically for (shortish) metadata such as ACLs, > >> rather than being complete separate data spaces for I/O (e.g., that co= uld > >> be memory mapped). > >=20 > > It would be nice to have NFSv4 / Solaris style alternate data streams. = ZFS > > handles them already, but I suppose it would take more work to support > > them in UFS. > >=20 > >> In FreeBSD=E2=80=99s design, we incorporated the disjoint namespace mo= del, > >> providing USER and SYSTEM, the former being managed by the file owner > >> (and those given suitable permission), and the latter being used for T= CB > >> mechanisms such as the implementations of MAC labels, ACLs, etc. > >>=20 > >> In Linux, they adopted a more free-form mechanism based on a single > >> combined namespace with a prefix =E2=80=94 e.g., user.FOO, and system.= BAR. Over > >> time it looks like that namespace has been expanded in various > >> filesystem-specific ways. We also have room to expand our namespace, b= ut > >> from the description below, it=E2=80=99s not clear quite what the righ= t mechanism > >> is. > >>=20 > >> One path would be to introduce a new namespace for filesystem-specific > >> attributes =E2=80=94 e.g., EXTATTR_NAMESPACE_FS? > >>=20 > >> But I think the key question here is whether the existing namespaces c= an > >> provide the semantics you need. If not, then we likely need a new > >> namespace. But then we get the question as to who controls use of the > >> namespace. Certainly =E2=80=9Cthe filesystem=E2=80=9D is one option, b= ut then you will > >> get inconsistency in approaches between filesystems and applications = =E2=80=94 > >> across various dimensions including protection (who can read/modify > >> them?), allocation (who decides what names should be used for what?), = and > >> semantics (what applications can use them, and who backs them up?). > >>=20 > >> For example: who should be responsible for backing up those attributes= ? > >> For =E2=80=98system=E2=80=99 attributes in FreeBSD, it is assumed that= backup tools will > >> be aware of the services layered over the attributes =E2=80=94 e.g., t= hat they > >> will back up ACLs using the ACL API, rather than backing up the binary > >> EAs holding the ACLs. For =E2=80=98user=E2=80=99 attributes, it is ass= umed that backup > >> tools (e.g., tar) must explicitly preserve them, since they are > >> user-defined and user-managed. For filesystem-specific attributes, som= e > >> other choice will need to be made =E2=80=94 perhaps filesystem-specifi= c backup > >> tools need to know about them? > >>=20 > >> Note that in the Linux EA model, ACLs are actually accessed via the EA > >> system calls, whereas in FreeBSD, ACLs are a first-class citizen in th= e > >> system-call API/ABI, and so user applications don=E2=80=99t treat them= as EAs. We > >> made that choice as filesystems may choose themselves not to represent > >> ACLs as EAs, and they have real semantics visible to the VFS layer. In > >> Linux, I believe they chose to pass them via EAs to narrow the > >> system-call interface for filesystem metadata. Both are legitimate > >> choices, but this could also trigger discussions about whether new > >> attributes are best accessed via the EA interface, or new system calls= . > >> For filesystem-specific attributes, EAs are likely the better way to g= o. > >=20 > > It may be that for at least the purposes of FUSE, we can adequately liv= e > > under the USER namespace. That would allow for arbitrary namespaces th= at > > Linux-centric filesystems create without significant churn in FreeBSD t= o > > support it. > >=20 > > And of course this is only for the front/top end of a FUSE filesystem. > > What the filesystem actually does with the extended attributes that the > > user sets on top is another question altogether. In the case of IBM=E2= =80=99s > > LTFS, it stores extended attributes (without the =E2=80=9Cuser.=E2=80= =9D prefix) in the > > LTFS index, which is an XML file that resides on tape. For other > > filesystems, the answer could also vary significantly. A few that I > > examined in sysutils/fusefs* used extended attributes on the backend > > (usually on a backing filesystem) under Linux only, but not on the fron= t > > (user facing) end. > >=20 > > In order to make arbitrary namespaces in FUSE work in FreeBSD under the > > user namespace, we=E2=80=99ll have to do what Rick was talking about an= d just not > > include the namespace as a prefix when we get/set attributes. This wil= l > > allow using any sort of namespace or attribute name that the FUSE > > filesystem wants to use. > >=20 > > The impact of this, from a porting standpoint, is that the FUSE filesys= tems > > will have to know that on FreeBSD, they cannot/should not expect to see > > the =E2=80=9Cuser.=E2=80=9D namespace prefix, but they might see other = namespace prefixes. > >=20 > > I took a look at the way LTFS and Gluster work with respect to extended > > attributes with MacOS, since it seems that is how MacOS works, and it= =E2=80=99s > > less obvious to me what is going on with Gluster. They=E2=80=99ve got = this > > function: > >=20 > > #ifdef GF_DARWIN_HOST_OS > > static int > > set_xattr_user_namespace_mode (struct posix_private *priv, const char *= str) > > { > > if (strcmp (str, "none") =3D=3D 0) > > priv->xattr_user_namespace =3D XATTR_NONE; > > else if (strcmp (str, "strip") =3D=3D 0) > > priv->xattr_user_namespace =3D XATTR_STRIP; > > else if (strcmp (str, "append") =3D=3D 0) > > priv->xattr_user_namespace =3D XATTR_APPEND; > > else if (strcmp (str, "both") =3D=3D 0) > > priv->xattr_user_namespace =3D XATTR_BOTH; > > else > > return -1; > > return 0; > > } > > #endif > >=20 > > Although it=E2=80=99s not clear that they do anything with values other= than > > XATTR_STRIP. > >=20 > > With LTFS, since they either assume a =E2=80=9Cuser.=E2=80=9D prefix on= Linux, or no prefix > > on Windows and MacOS X, it=E2=80=99s more straightforward. > >=20 > > Ken > >=20 > >=20 > >>=20 > >> Robert > >>=20 > >>> On 7 Mar 2016, at 07:16, Julian Elischer wrote: > >>>=20 > >>> On 5/03/2016 7:06 PM, Rick Macklem wrote: > >>>> Ken Merry wrote: > >>>>> I have patches for FreeBSD=E2=80=99s FUSE filesystem kernel module = to support > >>>>> extended attributes: > >>> oh showing off your masochistic side eh? > >>>=20 > >>>>> https://people.freebsd.org/~ken/fuse_extattr.20160229.1.txt > >>> I spent an hour beating my head against fuse yesterday. > >>> then realised that it's an old version on our product. We really have= to > >>> get off 8.0 > >>> (hopefully a matter of weeks now to a 10.x switch) > >>> Now all I need is to find a FreeBSD filesystem expert (ZFS/NFS/CIFS/= GFS) > >>> to hire. > >>>=20 > >>>=20 > >>>> The only bit of code I have that might be useful for this patch is: > >>>> case FUSE_GETXATTR: > >>>> case FUSE_LISTXATTR: > >>>> ! /* > >>>> ! * These can have varying response lengths, and 0 length > >>>> ! * isn't necessarily invalid. > >>>> ! */ > >>>> ! err =3D 0; > >>>> *** I came up with this: > >>>> fgin =3D (struct fuse_getxattr_in *) > >>>> ((char *)ftick->tk_ms_fiov.base + > >>>> sizeof(struct fuse_in_header)); > >>>> if (fgin->size =3D=3D 0) > >>>> err =3D (blen =3D=3D sizeof(struct fuse_getxattr_out)) ? = 0 : > >>>> EINVAL; > >>>> else > >>>> err =3D (blen <=3D fgin->size) ? 0 : EINVAL; > >>>> break; > >>>> I think I got the size check right? > >>>>=20 > >>>> The big question is... > >>>> What to do with the NAMESPACE? > >>>> - My code fails for SYSTEM and does USER without prepending "user.". > >>>> (That seemed to be what rwatson@ felt was reasonable. I thought our > >>>> discussion was on a mailing list, but I can't find it.) > >>>> I've cc'd him. Maybe he can comment again. > >>> Is there a standard for extended attributes I should knwo about? > >>> It seems to me that it's a bit like the wild west. > >>> Extended attributes seem to be "every OS for himself". > >>>=20 > >>>>=20 > >>>> - If you stick with prepending "user." or "system." there needs to b= e > >>>> some way to bypass this so that attributes that don't start in "user= ." > >>>> or "system." can be accessed. I've seen "trusted." and "glusterfs." > >>>> on GlusterFS. > >>>> --> Maybe a new namespace called something like "nil" that just bypa= sses > >>>> any USER or SYSTEM checks? > >>>>=20 > >>>> rick > >>>>=20 > >>>>> The patch implements the get/set/delete/list extended attribute > >>>>> methods. The > >>>>> listing code also converts extended attribute lists from the Linux/= FUSE > >>>>> format to the FreeBSD format. For example: > >>>>>=20 > >>>>> # touch foo > >>>>> # ls -la foo > >>>>> -rwxrwxrwx 1 root wheel 0 Feb 29 21:40 foo > >>>>> # lsextattr user foo > >>>>> foo > >>>>> # setextattr user testattr1 "12345678" foo > >>>>> # lsextattr user foo > >>>>> foo testattr1 > >>>>> # getextattr user testattr1 foo > >>>>> foo 12345678 > >>>>> # setextattr user testattr2 "87654321" foo > >>>>> # lsextattr user foo > >>>>> foo testattr2 testattr1 > >>>>> # rmextattr user testattr1 foo > >>>>> # lsextattr user foo > >>>>> foo testattr2 > >>>>> # getextattr user testattr1 foo > >>>>> getextattr: foo: failed: Attribute not found > >>>>> # getextattr user testattr2 foo > >>>>> foo 87654321 > >>>>>=20 > >>>>>=20 > >>>>> Just to be clear on what this does, it only provides extended attri= bute > >>>>> support to FreeBSD applications if the underlying FUSE filesystem > >>>>> implements > >>>>> FUSE extended attribute support. Many FUSE filesystems don=E2=80= =99t support > >>>>> the > >>>>> extended attribute VFS operations. > >>>>>=20 > >>>>> I have tested this out on IBM=E2=80=99s LTFS implementation, but I = have not yet > >>>>> found > >>>>> another FUSE filesystem that supports extended attributes. If anyo= ne > >>>>> knows > >>>>> of one, please let me know so I can try it out. (I looked through = a > >>>>> number > >>>>> of the filesystems in sysutils/fusefs* in the ports tree.) > >>>>>=20 > >>>>> Any feedback is welcome. I=E2=80=99m planning to check this into F= reeBSD/head > >>>>> in the > >>>>> next week or so. > >>>>>=20 > >>>>> Obviously, I=E2=80=99ve also ported IBM=E2=80=99s LTFS implementati= on to FreeBSD. It > >>>>> works > >>>>> in the standard FUSE mode, and you can also link it into an applica= tion > >>>>> as a > >>>>> library if you don=E2=80=99t want to incur the overhead of running = through > >>>>> FUSE. I > >>>>> haven=E2=80=99t gotten around to packaging it up to go out for test= ing / > >>>>> review. > >>>>>=20 > >>>>> If anyone has IBM LTO-5 or newer tape drives, or IBM TS1140 or newe= r > >>>>> tape > >>>>> drives, and wants to try it out, let me know. I=E2=80=99ll send yo= u the code > >>>>> when > >>>>> I=E2=80=99ve got it at least somewhat ready. This is IBM-specific,= and won=E2=80=99t > >>>>> work > >>>>> on HP tape drives. > >>>>>=20 > >>>>> Ken > >>>>> =E2=80=94 > >>>>> Ken Merry > >>>>> ken@FreeBSD.ORG > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>> _______________________________________________ > >>>>> freebsd-fs@freebsd.org mailing list > >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-fs > >>>>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.or= g" > >>>> _______________________________________________ > >>>> freebsd-fs@freebsd.org mailing list > >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-fs > >>>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org= " > >=20 > >=20 > >=20 > > =E2=80=94 > > Ken Merry > > ken@FreeBSD.ORG > >=20 > >=20 > >=20 >=20 From owner-freebsd-scsi@freebsd.org Wed Mar 9 04:00:42 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 285E1AC8D1A for ; Wed, 9 Mar 2016 04:00:42 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0816DC09 for ; Wed, 9 Mar 2016 04:00:42 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: by mailman.ysv.freebsd.org (Postfix) id 07C4CAC8D19; Wed, 9 Mar 2016 04:00:42 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07392AC8D17; Wed, 9 Mar 2016 04:00:42 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 95695C08; Wed, 9 Mar 2016 04:00:40 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074423-b4fff700000048c2-37-56df9fe07bcc Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id D4.A8.18626.0EF9FD65; Tue, 8 Mar 2016 23:00:32 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u2940WBu016503; Tue, 8 Mar 2016 23:00:32 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2940TH0016280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Mar 2016 23:00:31 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u2940Sv5007758; Tue, 8 Mar 2016 23:00:28 -0500 (EST) Date: Tue, 8 Mar 2016 23:00:28 -0500 (EST) From: Benjamin Kaduk To: Rick Macklem cc: fs@freebsd.org, scsi@freebsd.org Subject: Re: FUSE extended attribute patches available In-Reply-To: <2091108840.10124858.1457483217137.JavaMail.zimbra@uoguelph.ca> Message-ID: References: <800018199.6694281.1457233600357.JavaMail.zimbra@uoguelph.ca> <56DD2AB6.1030407@freebsd.org> <6AF0FC23-CC34-43EA-A008-9FB82FB21558@FreeBSD.org> <2091108840.10124858.1457483217137.JavaMail.zimbra@uoguelph.ca> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixCmqrPtg/v0wg1ntFhaHn7hYPFx2jcni 1tH5zA7MHjM+zWfx+L15L1MAUxSXTUpqTmZZapG+XQJXxpwpSxgLlrFXnDhm1sD4gbWLkZND QsBEYv+7S0A2F4eQQBuTxNkHD9kgnA2MEnPXbmCGcA4ySex6vZoNpEVIoF7i8oIV7CA2i4CW xLPOe4wgNpuAisTMNxvBakQE1CU2r+5nBrGZgeKH97wFqxcWMJO4Or2TBcTmFPCReP13FVA9 BwevgKPElIfmEOO/MUns/iUOYosK6Eis3j8FrJxXQFDi5MwnLBAjtSSWT9/GMoFRYBaS1Cwk qQWMTKsYZVNyq3RzEzNzilOTdYuTE/PyUot0zfRyM0v0UlNKNzGCwpLdRXkH48s+70OMAhyM Sjy8ES73w4RYE8uKK3MPMUpyMCmJ8t6RAgrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4V08EyjH m5JYWZValA+TkuZgURLnZWRgYBASSE8sSc1OTS1ILYLJynBwKEnwXp4H1ChYlJqeWpGWmVOC kGbi4AQZzgM0PB6khre4IDG3ODMdIn+KUZdjwY/ba5mEWPLy81KlxHn9QIoEQIoySvPg5oDT yW4m1VeM4kBvCfNyApOLEA8wFcFNegW0hAloyYvWeyBLShIRUlINjL2PQhlvn9n321Nc6eix qTG2nqWVr95umPnoxocA22PnL5+ykHl/+9qUC9OCKq49ZmVn/LKXP/e4y+OXKmx2B9pPLNJ8 OXPv17WOkR9W3WRcMtczxTWvkbW7eBufyM8V0+O35u0Izo3TneTR4BOeIPDyp5/zxRhJP69e 9tDL7cePr2BzS5H+sEaJpTgj0VCLuag4EQAWZ6/pAgMAAA== X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 04:00:42 -0000 On Tue, 8 Mar 2016, Rick Macklem wrote: > Robert N. M. Watson wrote: > > Just a quick observation: to avoid application change, you could actually > > leave the 'user.' on the front of the strings? It's not harmful, it just > > doesn't serve the same function. This might keep documentation more in sync, > > etc. > > > Btw, this internet draft was just published. There is work in progress w.r.t. > NFS support for Linux style extended attributes and this draft might have something > to say w.r.t. namepsace? (I haven't looked at it.) > > draft-ietf-nfsv4-xattrs-02.txt > > Available via anonymous ftp at ftp.ietf.org (I find it amusing that the engineers > of the internet still use anonymous ftp;-). I prefer the version at http://tools.ietf.org/html/draft-ietf-nfsv4-xattrs-02 :) [obligatory note that the above document is to be considered a work in progress, and is not a final specification.] -Ben