gpfs 3.5 and Samba Compatibility

[Nimrod Sapir]

Hi

I've been working with this patch and gpfs 3.5 for the last few weeks, and 
it seem to be working great. Is this patch expected to be merged in any 
time soon?

Thanks
Nimrod Sapir
IBM - XIV, Israel
NAS Development Team
Office: +972-3-689-7763
Cell:   +972-54-7726-320




From:   Ralph Wuerthner <ralphw at de.ibm.com>
To:     Nimrod Sapir/Israel/IBM at IBMIL, 
Cc:     Christof Schmitt <christof.schmitt at us.ibm.com>, samba-technical 
<samba-technical at lists.samba.org>, Maxim Kalaev/Israel/IBM at IBMIL, Dan 
Cohen1/Israel/IBM at IBMIL, Shai Koffman/Israel/IBM at IBMIL, Lior 
Chen/Israel/IBM at IBMIL
Date:   04/06/2012 14:03
Subject:        Re: gpfs 3.5 and Samba Compatibility



On Sun, 3 Jun 2012 11:00:53 +0300
Nimrod Sapir <NIMRODS at il.ibm.com> wrote:

> You are right, of course. Also, I can't really think of a possible 
> solution from the GPFS side that will solve the problem while keeping 
> backward-compatibility. Is gpfs 3.5 compatibility included in the
> Samba roadmap? for which version? Is there anyone in the community
> (beside our team) which already started to examine this
> configuration? 
> 
> Thanks!
> 
> Christof Schmitt <christof.schmitt at us.ibm.com> wrote on 01/06/2012 
> 00:55:13:
> 
> 
> > From a brief look, making this change would tie Samba to GPFS
> > 3.5. A proper solution should allow a binary of the vfs_gpfs
> > module to work with GPFS 3.5 and older versions.
> > 
> > I am not sure if this can be done automatically, there is always
> > the fallback of adding a config option to specify the format.
> > When reading an ACL, simply allocating enough space and then
> > deciding according to the gpfs_acl header could be
> > enough. Writing might be more complicated as the Samba module
> > would not know beforehand which format to try.
> > 
> > Regards,
> > 
> > Christof Schmitt || IBM || SONAS System Development || Tucson, AZ
> > christof.schmitt at us.ibm.com  ||  +1-520-799-2469  (T/L: 321-2469)

I noticed the same build failure with GPFS 3.5 last week when I tried
to build Samba packages on a GPFS 3.5 system. I prepared the following
patch to address this build issue:

---
commit bcfe3632b5223c21e8bd0d22f06471cf89a49597
Author: Ralph Wuerthner <ralph.wuerthner at de.ibm.com>
Date:   Fri Jun 1 13:43:11 2012 +0200

    vsf_gpfs: fix ACL length calculation
 
    GPFS 3.5 introduces ACL enhancements which are breaking our ACL length
    calculations.
 
    Signed-off-by: Ralph Wuerthner <ralph.wuerthner at de.ibm.com>

diff --git a/source3/modules/vfs_gpfs.c b/source3/modules/vfs_gpfs.c
index ba756f6..d54405c 100644
--- a/source3/modules/vfs_gpfs.c
+++ b/source3/modules/vfs_gpfs.c
@@ -401,9 +401,10 @@ static bool gpfsacl_process_smbacl(files_struct *fsp, 
SMB4ACL_T *smbacl)
                 SMB4ACE_T               *smbace;
                 struct gpfs_acl *gacl;
                 TALLOC_CTX *mem_ctx  = talloc_tos();
+                int gacl_base_len = ((caddr_t)gacl->ace_v1) - 
((caddr_t)gacl);
 
-                gacl_len = sizeof(struct gpfs_acl) +
- (smb_get_naces(smbacl)-1)*sizeof(gpfs_ace_v4_t);
+                gacl_len = gacl_base_len + smb_get_naces(smbacl) *
+                                sizeof(gpfs_ace_v4_t);
 
                 gacl = (struct gpfs_acl *)TALLOC_SIZE(mem_ctx, gacl_len);
                 if (gacl == NULL) {
@@ -662,16 +663,11 @@ static struct gpfs_acl *smb2gpfs_acl(const SMB_ACL_T 
pacl,
                 gpfs_aclLen_t len;
                 struct gpfs_acl *result;
                 int i;
-                union gpfs_ace_union
-                {
-                                gpfs_ace_v1_t  ace_v1[1]; /* when 
GPFS_ACL_VERSION_POSIX */
-                                gpfs_ace_v4_t  ace_v4[1]; /* when 
GPFS_ACL_VERSION_NFS4  */
-                };
+                int base_len = ((caddr_t)result->ace_v1) - 
((caddr_t)result);
 
                 DEBUG(10, ("smb2gpfs_acl: Got ACL with %d entries\n", 
pacl->count));
 
-                len = sizeof(struct gpfs_acl) - sizeof(union 
gpfs_ace_union) +
-                                (pacl->count)*sizeof(gpfs_ace_v1_t);
+                len = base_len + (pacl->count)*sizeof(gpfs_ace_v1_t);
 
                 result = (struct gpfs_acl *)SMB_MALLOC(len);
                 if (result == NULL) {

---

In my opinion the ultimate solution would be to ask GPFS to provide a
function/macro similar like this:

size_t gpfs_acl_len(gpfs_aclLevel_t acl_level,
                    gpfs_aclVersion_t acl_version,
                    gpfs_aclType_t    acl_type,
                    gpfs_aclCount_t   acl_nace);

This should allow maximum backward compatibility and allow GPFS to
enhance the ACL type if future features require this.


Regards

   Ralph

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1338 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120701/52bba215/attachment.gif>