Celerra runs AVM (Automated Volume Manager) which manages the creation of slice/stripe/meta volumes using the available disks while creating a file system. Unless there is a solid reason not to use the AVM and manually administer the volumes and file systems, we'll prefer to let AVM take care of the same.

What is the need to put both the file systems on the same Celerra Disk (CLARiiON LUN)?

I'll suggest not to worry about this and let AVM manage it, which it does quite well.

You may consider referring the following technical documents available on powerlink -

1) Managing Celerra Volumes and File Systems with Automatic Volume Management

2) Managing Celerra Volumes and File Systems Manually

Hope this helps.

Regards,
Sandip

Hmmh,

if you really want to do this I can see the following options:

- use manual volume management - that will give you exact control over the layout

- create a user-defined pool that just contains the dvol you want to use

- if these are the only two LUNs available for that system pool you can create the first user file system, then create a dummy file system the size of your second LUN, create your second user file system and finally delete that dummy file system

I agree with Sandip though to stay with the normal AVM behaviour, unless you have very specific reasons and know about Celerra performance best practices

Hi Rainer,

Nice to see you back on the forums. I guess you were on vacation - we missed you while you were out. Hope you had a wonderful vacation.

Cheers,
Sandip

let me elaborate on what AVM does (in short):

when you request a certain size file system to be created from a system pool it goes out and tries to find a number (normally 4,3,2,1) of equal size LUNs (dvols) that can be striped together.

For this striping it will consider balancing between SP's, backend buses and so on and it will NOT stripe between LUNs that are on the same disks

It will then create this stripe and also create a slice of the size you requested from it.

If you requested more than whats available in that stripe it will concat more slices

When deciding which stripe to use it will also "distribute" the load - meaning it will prefer stripes that dont contain file systems yet.
That is controlled by the is_greedy parameter, which can be changed for user-defined pools but not for system pools.
That behaviour was put in some releases (years) ago, since we were seeing performance problems due to "file system stacking"
i.e. customers that had enough disks, but created their most important and small file systems first and these ended up being on the same disks even though there were lots of more disks available.

This is detailed in the AVM manual

Rainer
P.S.: whatever you do, DONT stripe between LUNs that are on the same disks (raidgroup) - tests have shown that in this case concat performs much better than striping

thanks - Yes, I was indeed on vacation.
It was nice to get away from EMail but the weather could have been better