Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753229AbXFORVK (ORCPT ); Fri, 15 Jun 2007 13:21:10 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751495AbXFORUy (ORCPT ); Fri, 15 Jun 2007 13:20:54 -0400 Received: from il.qumranet.com ([82.166.9.18]:53290 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751329AbXFORUx (ORCPT ); Fri, 15 Jun 2007 13:20:53 -0400 Message-ID: <4672CA72.1010505@argo.co.il> Date: Fri, 15 Jun 2007 20:20:50 +0300 From: Avi Kivity User-Agent: Thunderbird 2.0.0.0 (X11/20070419) MIME-Version: 1.0 To: Jan Engelhardt CC: Neil Brown , david@lang.hm, linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org Subject: Re: limits on raid References: <18034.479.256870.600360@notabene.brown> <18034.3676.477575.490448@notabene.brown> <467273AB.9010202@argo.co.il> In-Reply-To: X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (firebolt.argo.co.il [0.0.0.0]); Fri, 15 Jun 2007 20:20:51 +0300 (IDT) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1531 Lines: 35 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/