[gpfsug-discuss] question about why unix extensions = no is recommended when using samba + gpfs?

[Sabuj Pattanayek]

> include = /etc/samba/template_shares.conf
>> include = /etc/samba/test_shares.conf
>>
>
> That is stupid, you need to use registry share definitions with CTDB.
> Having them in files is bad bad bad.


Will look into it.


> ### template_shares.conf ###
>
>>
>> [template_nfs4]
>> comment = GPFS Cluster on smb using %R protocol
>> path = /dors/testfs
>> writeable = yes
>> vfs objects = shadow_copy2 gpfs fileid
>>
>
> Hum, might have changed in Samba 4.x but in Samba 3.5/3.6 you can only
> have one vfs objects line in the entire smb.conf file and I did not thing
> it was a per share option either. Well you can have more than one, but the
> later ones just override the previous ones.



Yup, it's definitely per share in 4.1.x and the later ones probably do
override the previous one if the same vfs functions are overloaded, but in
the case above there's no overlap and shadow_copy2 and gpfs do work.



>
> I am not well versed with Samba 4.x but a quick check says that share
> modes = yes conflicts with SMB2 and durable handles. Given in Samba 4.1 max
> protocol is SMB2 by default ...
>

I was able to do SMB2 (at least in terms of performance over SMBv1) with
sharemodes = yes or sharemodes = no. Durable / persistent handles don't
work in that active read/write I/O will not continue if  smb/ctdb is
disabled on one of the samba nodes. The client will not have to
re-map/re-connect but any active I/O other than file deletions and perhaps
metadata operations will continue unaffected.


>
> I have not seen a definitive answer anywhere about whether SMB2 and CTDB
> can be used in combination and if so what versions of CTDB/Samba one should
> be using however.


I'm using ctdb 1.0.114 packaged by sernet along with sernet samba 4.1.6 .
They said they would release re-packaged v2 rpm at some point. Again, SMB2
works in so far as I can tell with its much improved read/write performance
over SMB1.


>>
>> No, but they're all set to no, including map hidden which was missing
>> above but according to man smb.conf is by default set to no, so wouldn't
>> these not be mapped/stored in GPFS anyways? What EA file would these be
>> stored in if these were set to yes?
>>
>
> They are not stored in an extended attribute they are stored in the GPFS
> file system itself. The various settings that I listed are so that Samba
> tells the GPFS VFS module to store them in the extended attributes. Howeve
> the GPFS VFS module then goes and stores/retrieves them directly from the
> file system. It's all part of GPFS being able to run on Windows. There are
> genuine file creation times as well
>
> I suggest that you explicitly test and make sure it is working.
>

Yup, they're working, they're being stored wherever they're supposed to be
stored in GPFS itself. I set a file to hidden and it disappeared from the
explorer window. Went into a command prompt and ran dir/a and it appeared.
Then ran mmlsattr -L on the file and it showed ARCHIVE HIDDEN in the
Windows attributes section.



> Put simply no you are not working around it, it is the cause of your
> issues with Office. More precisely the issue with Office is down to how the
> mapping of NTFS ACLS to GPFS is working, because storing the NTFS ACLS in
> extended attributes works. I am telling you don't mix Posix and NFSv4 ACL's
> in GPFS it won't work. Whether you listen is up to you.
>

It doesn't work if the ACL on the file is POSIX or has been promoted to
NFS4. In any case, we have need for the ACLs support to be both POSIX and
NFS4 where needed for the window shares and we can't/won't split up the
filesystem.


>
> I suggest you use a development/test GPFS cluster to verify it.


Yes, we're going to need a test/dev cluster for testing these for future
upgrades, etc so I will try an FS that's pure nfs4 ACLs only and see if it
behaves any differently.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20140403/5f38f99f/attachment.htm>