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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4672CA72.1010505@argo.co.il>
Date:	Fri, 15 Jun 2007 20:20:50 +0300
From:	Avi Kivity <avi@...o.co.il>
To:	Jan Engelhardt <jengelh@...putergmbh.de>
CC:	Neil Brown <neilb@...e.de>, david@...g.hm,
	linux-kernel@...r.kernel.org, linux-raid@...r.kernel.org
Subject: Re: limits on raid

Jan Engelhardt wrote:
> On Jun 15 2007 14:10, Avi Kivity wrote:
>   
>> Some things are not achievable with block-level raid.  For example, with
>> redundancy integrated into the filesystem, you can have three copies for
>> metadata, two copies for small files, and parity blocks for large files,
>> effectively using different raid levels for different types of data on
>> the same filesystem.
>>     
>
> Sounds like you want RAIF, not RAID.
>
>   

If you mean taking a bunch of single-disk filesystems and layering
another filesystem on top, then no.  The underlying filesystems will
only serve as object allocators, and all the directory hierarchy,
journalling, and other capabilities will end up as overhead.  Fairly
significant overhead, too -- I've once worked on a similar environment. 
Performance sucked until the underlying filesystems were removed.

Abstraction layers are good for dividing large problems, but they have
their costs.  Consider NUMA for example: you can treat it as a large
blob of memory, but much performance can be gained of you don't. 
Similarly, with disks, you can put them in a big RAID and treat them as
a large disk, but if you don't, there are large rewards.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

-
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/