This post is more than 5 years old
40 Posts
0
3010
Nested File System - Pros and Cons - Going Beyond 16TB
So here's the issue: Our share is currently as 15 TB and reaching MAX size for a Celerra File System. I'm the lucky one that will migrate/replicate this data over to our CX4-960 that is now connected to the same NAS Gateway. Can I create X amount of File Systems such as:
Images1
Images2
Images3
Images4
Each @ 10 TB
Add then together to form a 40 TB File System?
Add the end of the day I only want to access two shares. Will this setup stripe my data across all file systems? Or am I interpreting Nested File Systems incorrectly.
I'm picturing Nested File Systems as Meta-LUNs.
Thanks for all the support,
Damian
idsdtapia
40 Posts
0
August 23rd, 2010 10:00
My apologies for not being clear. The end goal is as follows:
Migrate our 15TB file system to a new File System larger than the 16TB limit on Celerra.
I'm envisioning the following (numbers are NOT concrete). Multiple File Systems in NMFS were I then can copy our current File System.
Something like the following (again NOT concrete):
4-5 File Systems that are 5-8 TB each; combined we will have 25TB to 40 TB. Start the copy/migration process to ONE NMFS as opposed to ONE component File System.
Does this make sense?
Thanks Again for all your help,
Damian
Rainer_EMC
8.6K Posts
0
August 23rd, 2010 10:00
If you mean how you get from your current fs to a nmfs than that's easy
you don't have to copy or replicate the data
just create the nmfs and mount your fs underneath it
please take a look at the Managing Volumes and File Systems Manually manual that describes the steps
I would also suggest to try it with a small test fs first to understand that your share will look differently
Rainer_EMC
8.6K Posts
0
August 23rd, 2010 10:00
only if you tell it to by running multiple emcopy's to different component fs (subdir)
do not underestimate how long it takes to copy 15TB
Do you understand that NMFS does need at least one subdir between the root and the component?
Rainer_EMC
8.6K Posts
0
August 23rd, 2010 10:00
you lost me there - I don't understand what you are trying to do
Rainer_EMC
8.6K Posts
0
August 23rd, 2010 10:00
In terms of copying you would need to do that on a component level
and if you do want to distribute the data from the current 15gb to several smaller fs then yes it would have to be file-based (host copy, server_archive or ndmpcopy) and slow
if you app can tolerate the new path then the fastest would be to just mount the existing 15gb fs under a nmfs and create some more component fs
or seriously look at the FMA option
idsdtapia
40 Posts
0
August 23rd, 2010 10:00
We need to keep the same UNC path for the application. I was thinking something like EMCopy.
Will the copy process distribute the files over the smaller file systems?
ScottHolmanBG
13 Posts
0
August 26th, 2010 08:00
How about using symbolic links?
I've a pair of 16 TB file systems that were close to capacity (dedupe has now given me a lot of breathing space), so have been investigating thewhether it is possible to split the file systems into smaller chucks, but still keep the data structure seen by the user.
I tested NFS, but but that would ahve changed the data structure, so a linux bod at the desk next to me suggested symbolic links. the Celerra supports it and I've found them to work perfectly during testing. I replicate the file systems, and tested ndmp backup at the other side. ndmp does not follow the symbolic link, so you'll have to backup each file system individually, and be aware of where to pull restores.
Due to dedupe saving the day (for now) I've not put this into production, but plan to in the future; assuming futher testing is successful.
Is this not an option?
cheers