Unsolved

This post is more than 5 years old

3 Posts

1830

August 27th, 2014 19:00

CentOS 7 + SMB 2.1 with OneFS 7.1.0.3 = File too large

Hey all -- we have recently done a fresh install of CentOS 7 (7.0.1406) x86_64, and have the latest cifs-utils package installed, along with a killer onboard broadcomm dual port 10Gb NIC.

When I try to mount our SMB shares using -o vers=1.0 we can read and write fine, but of course, since it's SMB 1.0, the rsize and wsize are severely limited (what is it, 64k?) -- and over 10Gb, this is not good; we need the speed to handle our workflow. 

We mostly deal with ProRes HQ 4:2:2 video files...so a trailer will be ~10GB and a feature will be ~150GB.

If I use -o vers=2.0 or -o vers=2.1, I can mount the shares from Isilon fine, but any file over 4GB I try to copy over to the cluster fails...it starts the copy, and then craps out after 4GB and says "the file is too large"


Just to rule out Isilon as the cause of this, we have a Windows 2008 R2 domain controller with enough space on an internal SATA drive to accommodate a 150GB file, and I have the same issue there. 

If I force the CentOS 7 box to connect at SMB 1 (-o vers=1.0), it copies the file fine over 10Gb (slowly, but fine).

If I set -o vers=2.0 or 2.1, I get the same error message about the file being too large on the Windows 2008 R2 DC SMB share.

Although I think it's fair to say this is not an Isilon problem (proved that by trying the same thing with the Windows 2008 R2 server), this is pretty crappy in general, as our planned upgrade path for the past few months has been to go to CentOS 7 on most if not all of our Linux servers that are currently running 6.5, since CentOS 6.x has no built in support anything greater than SMB 1.0.

I know what you're thinking -- don't use SMB, use NFS -- unfortunately, that is not an option for us at the present time...we want to preserve the SMB ACLs, as all of our other Linux and Mac workstations and servers connect this way, and we don't have an LDAP server or services for Unix set up on our AD server.

The AD manages the SMB ACLs, and I use remote to local SMB user mapping to preserve the ACLs (ie. -o user=isilonuser,password=whatever,uid=locallinuxuser,forceuid).

Also looking forward to trying SMB 3, as the cifs-utils package in CentOS 7 supports it...although our current oneFS version does not...but I believe we have at least one Windows 2012 server that does.

Any thoughts or suggestions are appreciated besides using NFS...not an option.

Thanks all.

93 Posts

August 28th, 2014 12:00

Sounds like a CentOS problem...

Your choices are limited; go to a later OneFS with SMB 3 support or...

What if for the copy part of the workflow you used NFS?  Setup a script that (on the client) copies/move a file for the user. You could then add an appropriate ACL/ownership via a shell script or (depending on which version of OneFS you are on) set via a REST/API command.  All behind the scenes so the users' workflow is not impacted (except for having to run a shell script to copy/move the file).

Make sense?

Cheers,
Matt

3 Posts

August 28th, 2014 16:00

Unfortunately we don't have the REST APIs implemented and probably won't.

I tried SMB3 with a Windows 2012 server today and I have the same problem.

Updated the kernel to the latest one, same issue...looks like a CentOS problem....very disappointed, but I guess that's what happens when you go with operating systems that have community support.
No response from the samba guys about why this is happening except if I force -o vers=1.0.

Very depressing...I guess we will have to use NFS.

-Nick

0 events found

No Events found!

Top