From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 10:19:13 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 611642E6; Tue, 26 Nov 2013 10:19:13 +0000 (UTC) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 316312191; Tue, 26 Nov 2013 10:19:13 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id g10so7463327pdj.1 for ; Tue, 26 Nov 2013 02:19:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=DxxCbJCrCF+0GrIm+Tw3u0g+vHCje3kiK/lXHrI5tbQ=; b=VS/ZS9p+8k2sGHI7T+GQ7HR+bM1PMAsiGm+8jK5lmRd3DItZqSbOSjsLzrl6wrCHPL 6Lq4hrn5Yovp1I8bmPmCOqj53LPiOwy9Jt6d6q5tEscB2wijtyM9KIGsFW9fC+bjBfr6 +/g2sRNSH4bwlLf8Zdmxyay7Lhm5UE0CZaty7PEaPzUSXYk8K4sEVg7yO2E18TSQAfJV 3S22xdnRxir9mZyF2Gxz7rzYOu28JONLt08ei4GfrLljr3KITfhQ7Y/Hp64z0Tg73gRT C9VDn+yaB6aLXJffUzILlBjl3xWJuaE3xIHu8HcFJ8d3+bEKpkZtrQQiVMnzm4KyC8R8 gHkg== X-Received: by 10.66.2.66 with SMTP id 2mr33871828pas.72.1385461152670; Tue, 26 Nov 2013 02:19:12 -0800 (PST) Received: from [10.20.30.117] (16.sub-70-197-7.myvzw.com. [70.197.7.16]) by mx.google.com with ESMTPSA id jn12sm38146827pbd.37.2013.11.26.02.19.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 02:19:11 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) Subject: Re: O_XATTR support in FreeBSD? From: Jordan Hubbard In-Reply-To: Date: Tue, 26 Nov 2013 02:19:08 -0800 Message-Id: References: <718836647.19911209.1385302696963.JavaMail.root@uoguelph.ca> To: Cedric Blancher X-Mailer: Apple Mail (2.1812) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: Freebsd hackers list , Richard Yao , Pedro Giffuni , Rick Macklem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 10:19:13 -0000 On Nov 26, 2013, at 1:51 AM, Cedric Blancher = wrote: > 1. You do not need more syscalls. Solaris uses the plain openat() > syscall for this, with the O_XATTR flag passed to the normal > open()/openat() flags to open a named attribute. Likewise read(), > write(), mmap() etc work, too. I don=92t know if I=92d go so far as to say =93you do not need more = syscalls=94; there are additional functions for manipulating EAs that go well beyond the Solaris extensions to the directory and file I/O functions. = Assuming you want to be able to get/set as well as enumerate or remove EAs, then you might just as well add getxattr(2), listxattr(2), removexattr(2), = setxattr(2) too and follow the herd (Linux and OS X, so far). We=92re also glossing over ACLs and where they get to live. I don=92t = know if Robert and friends have stuck them in a separate namespace on FreeBSD or if = they=92re in system-protected EAs, as they are in OS X, but ACL preservation = across serialization / deserialization is just as important as it is for EAs. > 5. Support for tar and pax is already there. Its described in > Solaris's fsattr man page, they use a extended header with filename > /dev/null (to prevent older tar versions from tripping over the new > headers) and then have a named attribute header which describes the > attributes names and flags. This approach gets uglier when you try to apply to tools like rsync or = scp - now we=92re going to version their protocols? I think this was the = wrong approach, basically. Now there are multiple semi-compatible versions of tar and pax on Solaris, and they didn=92t do anything for zip/bzip/gzip = (what happens when you bzip2 a file with EAs and then unbzip it again? What if that file is on a remote NFSv3 share?). Again, the =93sidecar=94 files may strike all concerned as grotty hacks, = and they sort of ARE, but they=92re also the only fully functional, = work-in-pretty-much-all=20 situations solution for these scenarios. If the underlying filesystem = supports EAs, you just copy it from old to new or you stick it in the sidecar = file. If you=92re serializing a file across *any* streaming serialization protocol, you = sidecar it and if the other side doesn=92t support EAs, fine, the sidecar file = remains there intact and no data-loss has occurred. If it does, it simply combines = the file and sidecar files together and they disappear again. - Jordan