From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 9 16:01:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C3A17E2 for ; Tue, 9 Sep 2014 16:01:10 +0000 (UTC) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 41568F94 for ; Tue, 9 Sep 2014 16:01:10 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id v10so9293187pde.19 for ; Tue, 09 Sep 2014 09:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HIA87nbMENTFV5SU0qQlIDcjJ+58I8QeRmMd1X/57Ak=; b=LnygK7S3Fg5U1e3Sxs6sUM7VyWBonuqAb/qW+UIZOS2oR5DgV6VOWMzGIjOF0O79OA 74ovJPRurp00d0rpxVmw2FT7rlxWWwzcevfq6jZYytlJ1EUi616I29EFIeYWHff8hQn2 PDn42SXDdIVi8+wWOmkkJasID89yVTNc4RMPuQOWIR/TdheIF6haYitiHP6JC7+00Ma4 ufPGuWT801pwUEfmv4oQACO7xMuIkcSTeNxTy8zmpClVlm1tBW3BWXvEQeywMJxn71ts 0Xu5M0PWH7C9tH0mm5GGi5dalTHX2L/1JMnf31t7taiHdPkhyR6IGJwI4H1jn4Wwegkg ABfg== MIME-Version: 1.0 X-Received: by 10.70.130.138 with SMTP id oe10mr60336848pdb.115.1410278469098; Tue, 09 Sep 2014 09:01:09 -0700 (PDT) Received: by 10.66.82.37 with HTTP; Tue, 9 Sep 2014 09:01:09 -0700 (PDT) In-Reply-To: <1207532459.33927535.1410263267363.JavaMail.root@uoguelph.ca> References: <9F4D2C26-F077-4CA7-A532-BA4CE562C50D@ixsystems.com> <1207532459.33927535.1410263267363.JavaMail.root@uoguelph.ca> Date: Tue, 9 Sep 2014 18:01:09 +0200 Message-ID: Subject: Re: Tool to access ZFS/NFSv4 alternate data streams on FreeBSD? From: Simon Toedt To: Rick Macklem Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Richard Yao , Jordan Hubbard , Jan Bramkamp , Lionel Cons X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 16:01:10 -0000 On Tue, Sep 9, 2014 at 1:47 PM, Rick Macklem wrote: > Jordan Hubbard wrote: >> Yep. I was just describing the experience that OS X went through in >> implementing extattrs / legacy resource fork support. To recap it >> very briefly: Having NFSv4 support extattrs (or even named streams, >> if you want to go that far) is the comparatively easy part. It=E2=80=99= s >> backing them up / copying them around that gets more involved, and >> if you can=E2=80=99t back up certain attributes then you=E2=80=99re not = likely to >> get anyone to want to use them, at which point the whole =E2=80=9Csharin= g=E2=80=9D >> aspect kind of takes a back seat. >> > Yep. I strongly suspect you are correct. > > The question then becomes: > - Do we wait and see if someone chooses to get around to doing all > the hard userland work. Solaris tools already have support for this. Also AT&T AST from David Korn have support for O_XATTR, too. > or > - Do the easy part in the kernel and then hope someone does the > hard userland work because they need it. > or > - Just decide that the Linux style extended attributes are adequate > and not do resource forks at all? -1 for adopting the Linux junk. Basically, as they evolve, they go and evolve into Solaris's O_XATTR in the next ten years, with the pain of constant API changes on the way. Each month someone cries about size limit in the Linux style extended attributes or that listing or tar support doesn't work etc Solaris O_XATTR support has the beauty that it works now and is even supported on NFSv4 and is compatible to both Windows and MacOS resource forks. Simon