Re: [ADSM-L] Good or bad idea?...offsite disk.
>> On Mon, 2 Apr 2007 10:40:30 -0600, Kelly Lipp <lipp AT STORSERVER DOT COM>
> 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
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