Scott> 6T on 6070's

Heh. I'm running on 960s and 980s now, so this won't help me much, even with an upgrade planned for later this year. Maybe.

Scott> in a few cases, I split big volumes into smaller chunks Scott> and stiched them back together with automount maps an DFS Scott> links (my filesystem namespace is already built that way).

We've don't this too, but it's a total hassle when one volume has to grow, and I don't want to go down symlink hell again if I can help it.

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.

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