svn commit: r217828 - projects/graid/head/sys/geom/raid

[Alexander Motin]

Robert Watson wrote:
> On Tue, 25 Jan 2011, John Baldwin wrote:
>> Hmm, so this allocates bio's to make the dump work.  I believer other
>> dump routines in other drivers do not do this, but instead use
>> pre-allocated commands to schedule dump I/O requests.  Would it be
>> possible to pre-allocate the bio that is used here when dumping is
>> enabled and reuse it for each g_raid_dump() call without free'ing it
>> when the I/O is finished?
> 
> Yeah, same concern here: memory allocation and freeing in the dump path
> leads to less robustness.  Part of why the existing geom/dump
> interaction was so simplistic was to avoid exactly this problem by not
> needing lots of bio allocaiton/replication/etc on the way up/down the
> stack.  Likewise, the goal was to minimise dependence on correct
> operation of the kernel scheduler.  Some storage device drivers are
> poorly behaved in this regard, but introucing new dependencies in the
> stack just makes it harder to fix those drivers.
> 
> (A similar discussion is taking place in the context of network dumping,
> where it's really important not to introduce further large kernel
> subsystem dependencies: you want debugging paths to depend on as little
> in the way of sensitive global data structures, locks, etc, as possible.)

That's all true. Those who want maximum robustness should use dedicated
drive on the most trivial dedicated controller to make dumping reliable.
If we are going above that - there are always some compromises.

What's about dumping to GEOM, I think that with r217827 change (in
projects/graid/head) it should be possible to implement robust dumping
to gmirror and gstripe without doing any allocations and GEOM
interaction. With some efforts it could also be done to graid by writing
specialized minimalistic dumping routines for every transformation
module (at least it seems trivial for RAID0/RAID1).

-- 
Alexander Motin