On 2 December 2013 17:07, Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> wrote: > > On Dec 2, 2013, at 9:27, Sebastian Feld <sebastian.n.feld@xxxxxxxxx> wrote: > >> On Mon, Dec 2, 2013 at 2:29 PM, Trond Myklebust >> <trond.myklebust@xxxxxxxxxxxxxxx> wrote: >>> >>> On Dec 2, 2013, at 7:13, Joshuah Hurst <joshhurst@xxxxxxxxx> wrote: >>> >>>> We need to access NFSv4 Alternate Data Streams (what Solaris, >>>> NexentaOS, Omnios and SmartOS can openat() with the O_XATTR flag) from >>>> a (Suse) Linux client. >>>> >>>> OS is Suse Linux 12.3, x86-64, 64bit >>>> >>>> Does anyone know how to archive this? >>> >>> Why can’t you access Solaris-specific extensions from a Solaris client? >> >> This isn't a Solaris-specific extension, its part of the original Sun >> NFSv4 spec. Unfortunately the ARC/ARchitecture Cases from >> Opensolaris.org are no longer available, otherwise the background, >> e.g. feature parity with CIFS/NTFS, and the overall usefulness of such >> a feature, would be clearer. > > The open(O_XATTR) _is_ a Solaris specific extension. It isn’t something that we have been planning to support on Linux. When NFS version 4 was conceived by SUN long ago it was already decided that Alternate Data Streams should be a mandatory core feature. Alternate Data Streams were officially supported in Solaris 9 (with most kernel parts already added with Solaris 8 updates, minus implementations in the various file systems; a custom filesystem however can use ADS on S8 using the S9 includes) and NFSv4 development ran in parallel, together with the spec which would've introduced that feature as part of the next Single Unix Standard. The SUS spec itself was more or less "grounded" when SUN's POSIX team was laid off (the sad day of Fri, Jan 23, 2009) as a desperate measure to save money, but that didn't invalidate the valid concept or idea of Alternate Data Streams. What's *sad* is that there is a lot of FUD spread related to Alternate Data Streams, usually from the camp which wishes to promote Extended Attributes - which are not even closely related nor a competition - both serve different purposes and should be able to exist happily alongside each other. > >> There are many many applications coming from either the Windows world >> or the HPC camp (like nih.org or GE Healthcare) who mandatory rely on >> the existence of this feature (well, at least enough so that AT&T >> cloud services and the related toolchain (e.g. AST, including ksh93) >> now have extensive support for O_XATTR). > > What do they use it for? Usually to provide per-file context data, stuff like cookies (like Internet Explorer does), tags or per application index files. That doesn't mean they are small - as you can read in http://permalink.gmane.org/gmane.os.freebsd.devel.hackers/51891 such files can be in the TB range (OK, that's CERN for you, but the usage in the nih.gov toolchain can easily hit a few dozens GB as well if the parent germ database file is a few hundred GB). > Last I heard, Microsoft was deprecating the use of streams. I’m assuming that means they plan to get rid of it. Could you please give me an URL for this? The comments we (Institute Pasteur) got from Microsoft and what's behind their support paywall indicate that they intend to extend that feature with more support in tools and applications. This matches the recent flurry of new developments from AT&T Research, CERN and others in that direction. I think Microsoft would be clubbed to death by their own customers if they try to EOF that feature... Ced -- Cedric Blancher <cedric.blancher@xxxxxxxxx> Institute Pasteur -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
