Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 9 Sep 2014 18:01:09 +0200
From:      Simon Toedt <simon.toedt@gmail.com>
To:        Rick Macklem <rmacklem@uoguelph.ca>
Cc:        freebsd-hackers@freebsd.org, Richard Yao <ryao@gentoo.org>, Jordan Hubbard <jkh@ixsystems.com>, Jan Bramkamp <crest@rlwinm.de>, Lionel Cons <lionelcons1972@gmail.com>
Subject:   Re: Tool to access ZFS/NFSv4 alternate data streams on FreeBSD?
Message-ID:  <CAPL6_jR8O4W6Ad_yDR_khJvUV-mgsDW1AM7aWF=K3JTfA9AiYg@mail.gmail.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 9, 2014 at 1:47 PM, Rick Macklem <rmacklem@uoguelph.ca> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPL6_jR8O4W6Ad_yDR_khJvUV-mgsDW1AM7aWF=K3JTfA9AiYg>