Re: [ADSM-L] Good or bad idea?...offsite disk.

2007-04-02 13:38:04
Subject: Re: [ADSM-L] Good or bad idea?...offsite disk.
From: "Allen S. Rout" <asr AT UFL DOT EDU>
Date: Mon, 2 Apr 2007 13:37:50 -0400
>> On Mon, 2 Apr 2007 10:40:30 -0600, Kelly Lipp <lipp AT STORSERVER DOT COM> 
>> said:

> 2. Aggressively reclaim the storage pool.  Perhaps set reclaim to 30
> rather than the standard 60.  This will have lots of data movement, but
> will tend to keep as much space as possible available in the pool.

I've been considering using FILE devclasses in place of DISK for some
time, but I've got some questions and some design ideas I wanted to
run by someone, and

> Additional questions: fire away.  I've done a good bit of work on
> this...

YOU just volunteered!  Woot.

1) reusedelay.  In circumstances where I'm thinking of these FILE vols
   as replacing DISK vols, I don't want to have to hold on to that
   space for a few days before it becomes available again.  Just
   reusedelay=0, and view the data as ephemeral?

2) Performance management.  Currently I'm on Big ol' raids of 36G SSA,
   which can accept 30MB/s per raid.  I allocate a stripe across all
   my RAIDs to each DISK stgpool, which means I've got e.g. 9 or 11
   different performance contention domains.  This works really well:
   if all my servers are booming, I still have really nicely spread

   If I go against FILE devclasses, especially pre-allocated, it seems
   like I lose that, and I could easily have all my servers trying to
   write to the same one or two LUNs.  How would you handle that?
   Just throw it all at the disk devices' cache and hope it's enough?

3) Free space consolidation.  The biggest reason I want to use FILEs
   is that I'd like to be able to deploy my 3TB of landing pad in such
   a way that any server, any FILE stpool, can temporarily overflow
   without any OS-level reallocation nonsense; just changing
   maxscratch or some such.  I thought I might be able to do this with
   a library handing out the FILE vols; am I insane?

- Allen S. Rout