lkml.org 
[lkml]   [2007]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: limits on raid
david@lang.hm wrote:
> On Fri, 22 Jun 2007, David Greaves wrote:
>
>> That's not a bad thing - until you look at the complexity it brings -
>> and then consider the impact and exceptions when you do, eg hardware
>> acceleration? md information fed up to the fs layer for xfs? simple
>> long term maintenance?
>>
>> Often these problems are well worth the benefits of the feature.
>>
>> I _wonder_ if this is one where the right thing is to "just say no" :)
> so for several reasons I don't see this as something that's deserving of
> an atomatic 'no'
>
> David Lang

Err, re-read it, I hope you'll see that I agree with you - I actually just meant
the --assume-clean workaround stuff :)

If you end up 'fiddling' in md because someone specified --assume-clean on a
raid5 [in this case just to save a few minutes *testing time* on system with a
heavily choked bus!] then that adds *even more* complexity and exception cases
into all the stuff you described.

I'm very much for the fs layer reading the lower block structure so I don't have
to fiddle with arcane tuning parameters - yes, *please* help make xfs self-tuning!

Keeping life as straightforward as possible low down makes the upwards interface
more manageable and that goal more realistic...

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-06-22 14:43    [W:0.126 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site