32-bit Linux applications on Isilon question

We have a site with some 32-bit Linux server running applications.

When they running applications will show error.

After we use 32-bit file IDs over NFSv3, those applications can run smoothly.

My question is…

What should we pay more attention when we use 32-bit file IDs over NFS?

Does it will limit all 64-bit file IDs environment? Connections or file size will be impact too?

Responses(18)

Rdamal

2 Intern

•

165 Posts

0

October 27th, 2014 17:00

HI Tim, thanks for the input

Yes, the output is from client server. The files are written to export by content manager application and it only few files that gets 660 permissions but expected is 664, this happens randomly and only for the files that have inode value >7.

This NFSv3 export and required ACL's are provided to the user (also defined on cluster although not required) and user can perform chmod command successfully. As a temp fix, scripts are ran on the export to change posix bits from 660 to 664 if at all there are any .JPG generated with 660.

I

ICPSR

10 Posts

0

December 10th, 2014 11:00

I should add a little additional clarification. It's not simply that the client is 32-bit, but more particularly, that the revision of the filesystem API (particularly the stat() system call) doesn't support 64-bit inode numbers on the client.

In our case, our NFS client machine was RHEL6 x64. The problems only hit us with the binary distributions of acroread and firefox .

tim_wright

29 Posts

0

December 10th, 2014 11:00

Hello Rdamal,

I'm sorry, this dropped off my radar. Did you make any headway?

If not could you please open a case with support. I can assist a support engineer on an SR if we get one going.

Regards,

Tim

1
2

View All

No Events found!