linux-kernel - Re: limits on raid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 22 Jun 2007 11:41:49 -0700 (PDT)
From:	david@...g.hm
To:	Bill Davidsen <davidsen@....com>
cc:	David Greaves <david@...eaves.com>, Neil Brown <neilb@...e.de>,
	linux-kernel@...r.kernel.org, linux-raid@...r.kernel.org
Subject: Re: limits on raid

On Fri, 22 Jun 2007, Bill Davidsen wrote:

> By delaying parity computation until the first write to a stripe only the 
> growth of a filesystem is slowed, and all data are protected without waiting 
> for the lengthly check. The rebuild speed can be set very low, because 
> on-demand rebuild will do most of the work.
>>
>>  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... 
>
> Those two paragraphs are mutually exclusive. The fs can be simple because it 
> rests on a simple device, even if the "simple device" is provided by LVM or 
> md. And LVM and md can stay simple because they rest on simple devices, even 
> if they are provided by PATA, SATA, nbd, etc. Independent layers make each 
> layer more robust. If you want to compromise the layer separation, some 
> approach like ZFS with full integration would seem to be promising. Note that 
> layers allow specialized features at each point, trading integration for 
> flexibility.
>
> My feeling is that full integration and independent layers each have 
> benefits, as you connect the layers to expose operational details you need to 
> handle changes in those details, which would seem to make layers more 
> complex. What I'm looking for here is better performance in one particular 
> layer, the md RAID5 layer. I like to avoid unnecessary complexity, but I feel 
> that the current performance suggests room for improvement.

they both have have benifits, but it shouldn't have to be either-or

if you build the seperate layers and provide for ways that the upper 
layers can query the lower layers to find what's efficiant then you can 
have some uppoer layers that don't care about this and trat the lower 
layer as a simple block device, while other upper layers find out what 
sort of things are more efficiant to do and use the same lower layer in a 
more complex manner

the alturnative is to duplicate effort (and code) to have two codebases 
that try to do the same thing, one stand-alone, and one as a part of an 
integrated solution (and it gets even worse if there end up being multiple 
integrated solutions)

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