[LU-3165] umask broken on master

• Type: Bug
• Resolution: Fixed
• Priority: Blocker
• Fix Version/s: Lustre 2.4.0
• Affects Version/s: Lustre 2.4.0
• Labels: LB
• Severity: 3
• Assignee: Lai Siyao
• Reporter: Christopher Morrone (Inactive)

Description

umask handling appears to be broken again on master. With x86_64 servers running 2.3.63-5chaos, and ppc64 clients at either 2.3.58 or 2.3.63, umask does not appear to be honored.

vulcanlac2:/p/lscratchv/morrone$ mkdir foo
vulcanlac2:/p/lscratchv/morrone$ touch bar
vulcanlac2:/p/lscratchv/morrone$ ls -la
total 298
drwx------    3 morrone morrone   5632 Apr 12 15:51 .
drwxr-xr-x 2121 root    root    293376 Apr 12 15:05 ..
-rw-rw-rw-    1 morrone morrone      0 Apr 12 15:51 bar
drwxrwxrwx    2 morrone morrone   5632 Apr 12 15:51 foo
vulcanlac2:/p/lscratchv/morrone$ umask
0077

Servers are running ZFS.

Comments

[Peter Jones]

Landed for 2.4

[Ned Bass (Inactive)]

Lai, your patch takes care of the umask problem. Thanks

[Lai Siyao]

Both rr_flags_h and rr_umask are missing in mdt_rec_reint, the patch is on http://review.whamcloud.com/#change,6054

[Ned Bass (Inactive)]

It looks like mdt_rec_create.cr_umask uses the rr_padding_3 field from the template struct mdt_rec_reint, but lustre_swab_mdt_rec_reint() was never updated to swab that field.

[Peter Jones]

Lai

Could you please look into this one?

Thanks

Peter

[Christopher Morrone (Inactive)]

Perhaps another swabbing bug introduced in the umask handling code when it was recently reworked? An x86_64 client running lustre 2.1.4-3chaos does not see the umask problem. So either the server behaves differently for the older client, or the different is the architecture of the client.