Re: NFSv4 alternate data streams?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 18, 2023 at 3:49 PM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote:
>
>
> > On Dec 18, 2023, at 3:33 AM, Martin Wege <martin.l.wege@xxxxxxxxx> wrote:
> >
> > On Thu, Nov 30, 2023 at 3:03 PM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote:
> >>
> >>> On Nov 29, 2023, at 10:59 PM, Martin Wege <martin.l.wege@xxxxxxxxx> wrote:
> >>>
> >>> Hello,
> >>>
> >>> does the Linux NFSv4 server has support for alternate data streams?
> >>> Solaris surely has, but we want to replace it. As our Windows
> >>> applications (DB) rely on alternate data streams the question is
> >>> whether the Linux NFSv4 server can fully replace the Solaris NFSv4
> >>> server in that respect.
> >>
> >> Hi Martin -
> >>
> >> Linux NFSD does not support alternate data streams because none of
> >> the underlying file systems on Linux implement them. Very much like
> >> the HIDDEN and ARCHIVE attributes.
> >>
> >> I believe Solaris and their storage appliance are the only
> >> implementations of NFS that do support them, since they have
> >> implemented streams in ZFS.
> >>
> >> Instead, Linux NFSD implements extended attributes (that's what
> >> our native file systems and user space support). I realize that
> >> the semantics of those are not the same as stream support.
> >
> > SMB server on Linux supports Alternate Data Streams -
>
> I was not aware of that support. I need more information about
> how that is done.
>
>
> > why can't the same be done for NFSv4?
>
> I mean, yes the standard NFSv4 protocol provides a way to access
> these, and NFSD can be made to support that. But where would it
> store that content?
>
> NFSD can support what is readily available from the VFS API. If
> alternate streams were to become a premier part of the Linux
> file system stack, it would be straightforward for NFSD to
> support them.
>
> IOW first NFSD needs the communities responsible for the VFS and
> file systems to implement them. Everyone has to agree on how
> these are stored, we can't just make something up. Otherwise
> there is no hope for interoperation between local applications
> and applications that access these via SMB or NFS.

Yeah, that's a good one(TM). Seriously? You try to pull on a 'John
Reiser' on me?
for those who do not remember, or are too young. Once upon a time
there was ReiserFS-NG, which had support for that, and the VFS people
dragged him and his project through the mud for religious reasons.

The 'religion' here being that Alternate Data Streams are from
WIndows, and therefore this is BAD(TM), EVIL(TM), and SATAN(TM).Even
if someone would come up with a serious, technical sound patch they
would just bicker at the patches so long and so often that they just
rot. Death by a thousand cuts (or nasty review comments). Remember,
for faith people will do anything, just look up the "dark ages" in
Europe.
And just the tip of the iceberg, I bet someone will deliver the
argument that John Reiser murdered his wife, children and family dog,
and that's why Alternate Data Streams will never be part of VFS.

So back to the topic: SAMBA people just support ADS by sticking a :
between filename and stream name on the SAMBA server side
("filename:adsname"), and are happy with that.
Why can't NFSv4 do the same?

Thanks,
Martin





[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux