Re: Solution to provide 400TB single CIFS volume

‎2012-12-1104:34 AM

Just to throw out an idea, how about using DFS to provide the root namespace and then link in an appropriate number of CIFS shares (ie volumes) under that root? You'd need a Windows box to front the DFS root, unless it changed recently, Netapp filers can't be DFS roots.

To actually have a 400 TB NetApp volume is not something I'd want. Just think about managing this beast with regards to snapshots, snapvault etc.

Re: Solution to provide 400TB single CIFS volume

‎2012-12-1209:01 AM

Like c_morrall, I think DFS is about the only way you're going to be able to do this, This works quite well, and makes things a lot more manageable. We've implemented something similar although not with that sort of size, we got sick of a small minority of users filling up a shared area with junk (ripped music / personal photos) and stopping other people saving genuine work related files. We map users a specific drive letter to what is the root of a DFS namespace, under there are DFS folders which point to separate volumes.

I suspect fulfilling this requirement simply is going to be difficult with most system, may be the customer has written the requirement to specifically exclude most storage providers and they have a specific solution in mind (who?).

Also I'd question how some of those OS's will react to seeing a 400TB volume.

An out there crazy way of doing it could be to front end it with a windows server and have some large luns, bonded together via software raid.

Re: Solution to provide 400TB single CIFS volume

‎2013-02-2108:06 AM

point taken, however the 8.2 C mode with the SMB3.0 look promissing and should handle the requirement. however if i step back for a moment, the requirement should be an object storage requirement, it have storage grid written all over it and why does the customer want to use CIFS for such a huge volume. number of files or size of those files. when the requirement says something like handling file that can reach 4GB per file its sounds like sizemic data and the way we do it here is via object storage solutions(storage grid) that will give you the performance, protection and expansion required... but that's just my view