Re: performance of filesystem xattrs with Samba4

[Steve French <smfrench@austin.rr.com>]

Anton wrote
> I have been mulling over in my head for quite a while what 
> to do about an interface for "advanced ntfs features" but so far I have 
> always pushed this to the back of my mind.  After all no point in 
> providing advanced features considering we don't even provide full 
> read-write access yet.  I just thought I would mentione NTFS when I saw 
>
>But to answer your question I definitely would envisage an interface to 
>the kernel driver

The same issue has been on my mind for other filesystems too - since I 
can return similar information to NTFS.  The "easy" things
to return that could be useful to apps (including Samba4, but also 
backup apps etc.) include:

1) file creation time
2) "dos" attribute bits
3) perhaps ACL mapping into "POSIX ACL" (getfacl/setfacl's Linux xattr) 
format from the CIFS/NTFS style.
4) streams (which could be mapped in a few cases to xattrs, but are getting
increasingly used and therefore important for certain types of apps - like
network backup e.g. to be able to get access to)

The first two are in the on disk format already of various filesytems (NTFS, VFAT, even JFS, and would be trivial 
for me to export in the cifs vfs.  I suspect NFSv4 which is similar to CIFS in many ways would also have
an easy time of exporting a few of those.   The first two of these could of course be simply special casings
the reserved xattr name "User.DosAttribute" or equivalent used by Samba4.  This has a few advantages - local apps work 
and migrations to Linux from Windows are easier (as more data is preserved)  :)

Note that NTFS now has a form of symlink stored in "OS/2 EAs" on disk (I see them show up on test systems 
when the Unix Services are loaded) as well as Unix like devices - very strange but potentially could 
be mapped into something that made sense to Linux.