Scott> no symlinks, automounter sub-mount maps. I have 600+ qtrees in Scott> 3 sites with NFS caches in between, in a single name space Scott> using a gory mesh of automount maps and automounter variables Scott> defined on clients.
We've done that, but when a single project out grows a volume, then we start needing to shuffle data... it's a pain.
If I could have more volumes, then I'd use them over qtrees, but then when an Aggr fills, I need to move volumes. It's a pain.
That's why I like the idea of the Acopia product. I wish NetApp would realize that and come out with their own storage virtualization product to put in front of backend NetApps. Would be really nice.
Course I'm a mostly NFS only shop.
Scott> this is worth doing if the data set is A-sis friendly.
It probably is actually, but hard to know.
Scott> Future OnTap versions are going to make A-sis an aggregate Scott> behavior, not a volume one, which removes the volume size Scott> limit.
Scott> and reinforces the silly 16T aggregate limit ;-)
Yeah, that's another silly limit, esp with raid sets and RaidDP stuff. They should just let it scale and scale and scale.
Scott> really a problem with 1 TB disks; 16 drives, onr Raid-DB group Scott> per aggregate. stinky performance.
I personally *like* one big volume, with bunches of qtrees. What I'd really like is qtrees on multiple levels, or the raising of the number of volumes that are supported in an aggregate. That would help.
And speeing up SnapVault. And a pony... :]
John