i really wish a product like acopia could work with live oracle data over nfs as well. we would purchase this in a heartbeat.
-- Daniel Leeds Manager, Storage Operations Edmunds, Inc. 1620 26th Street, Suite 400 South Santa Monica, CA 90404
310-309-4999 desk 310-430-0536 cell
-----Original Message----- From: owner-toasters@mathworks.com on behalf of John Stoffel Sent: Fri 3/28/2008 2:09 PM To: Scott Miller Cc: John Stoffel; toasters@mathworks.com Subject: Re: Some thoughts and questions on A-sis
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