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