From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <423A77D8.1020006@altlinux.com> Date: Fri, 18 Mar 2005 09:40:24 +0300 From: Anton Farygin User-Agent: Mozilla Thunderbird 1.0 (X11/20050202) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ALT Linux kernel packages development , Michael Shigorin Content-Type: multipart/mixed; boundary="------------060709020005050607050203" Cc: Subject: [d-kernel] [Fwd: Re: [Unionfs] UnionFS as step towards a big/reliable/fast virtual disk?] X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ALT Linux kernel packages development List-Id: ALT Linux kernel packages development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2005 06:41:44 -0000 Archived-At: List-Archive: List-Post: This is a multi-part message in MIME format. --------------060709020005050607050203 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Еще одно интересное письмо на эту же тему. Rgds, Rider --------------060709020005050607050203 Content-Type: message/rfc822; name="Re: [Unionfs] UnionFS as step towards a big/reliable/fast virtual disk?" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: [Unionfs] UnionFS as step towards a big/reliable/fast virtual disk?" Return-Path: X-Original-To: rider@altlinux.com Delivered-To: rider@master.altlinux.ru Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by master.altlinux.ru (Postfix) with ESMTP id 75CA2E4856 for ; Fri, 18 Mar 2005 02:45:37 +0300 (MSK) Received: from filer.fsl.cs.sunysb.edu (IDENT:eRg+OJunCKJz6bseh5T7oFZvtQse0+4x@localhost.localdomain [127.0.0.1]) by filer.fsl.cs.sunysb.edu (8.12.8/8.12.8) with ESMTP id j2HNjVDr027653; Thu, 17 Mar 2005 18:45:33 -0500 Received: from agora.fsl.cs.sunysb.edu (agora.fsl.cs.sunysb.edu [130.245.126.12]) by filer.fsl.cs.sunysb.edu (8.12.8/8.12.8) with ESMTP id j2HNjPDp027643; Thu, 17 Mar 2005 18:45:25 -0500 Received: from agora.fsl.cs.sunysb.edu (localhost.localdomain [127.0.0.1]) by agora.fsl.cs.sunysb.edu (8.13.1/8.13.1) with ESMTP id j2HNjOO3004644; Thu, 17 Mar 2005 18:45:24 -0500 Received: (from ezk@localhost) by agora.fsl.cs.sunysb.edu (8.13.1/8.12.8/Submit) id j2HNjOKf004641; Thu, 17 Mar 2005 18:45:24 -0500 Date: Thu, 17 Mar 2005 18:45:24 -0500 Message-Id: <200503172345.j2HNjOKf004641@agora.fsl.cs.sunysb.edu> From: Erez Zadok To: "Gordon Mohr (Internet Archive)" Subject: Re: [Unionfs] UnionFS as step towards a big/reliable/fast virtual disk? In-reply-to: Your message of "Thu, 17 Mar 2005 15:27:50 PST." <423A1276.1060001@archive.org> X-MailKey: Erez_Zadok Cc: unionfs@filer.fsl.cs.sunysb.edu X-BeenThere: unionfs@mail.fsl.cs.sunysb.edu X-Mailman-Version: 2.1.5 Precedence: list List-Id: Unionfs users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: unionfs-bounces@fsl.cs.sunysb.edu Errors-To: unionfs-bounces@fsl.cs.sunysb.edu In message <423A1276.1060001@archive.org>, "Gordon Mohr (Internet Archive)" writes: > The first application that came to my mind after learning about > UnionFS was using it to create a big and reliable and/or fast > virtual disk out of many smaller disks -- a sort of > filesystem-level RAID (raifs?). > > Has there been any work (or speculation) in this direction for > UnionFS? Yes, we've already been working on something like that for months: http://www.fsl.cs.sunysb.edu/project-raif.html Unfortunately, we're unable to report anything yet. > Some questions that come to mind for such usage: > > - Is there any hard limit to the branch fanout? (10? 100? 1000? more?) No. > - How would performance be expected to degrade with high fanout? Currently, linearly or worse (we tested the scalability in an older prototype). Unionfs doesn't scale well to many branches. It wasn't meant for that; in another effort, later on, we'll consider how to scale our fan-out infrastructure so we have very light-weight branches created on the fly. This is necessary for fine-grained snapshotting. > - How would performance degrade or memory usage rise if a particular > directory in one branch, or across multiple branches, had millions > or tens of millions of files (assuming the underlying filesystem > handles such quantities acceptably)? Aside from above issues, unionfs ops such as readdir and others are more costly than a single regular f/s b/c they have to merge contents of several branches, eliminate dups, and more. > - How does UnionFS handle detected disk failures on one of the > underlying branches? (Could a remove/rebuild/replace cycle be > triggered?) EIO is one example. We've built a replication f/s that automatically removes branches that produce "hard" errors like EIO, and failover to other "good" branches (load-balancing etc.) > - Are there inherent factors which would prevent a future > revision of UnionFS from... > - optionally operating under the assumption that the same path > on different branches represents an identical file, and > fanning-out reads for greater speed? > - choosing from more than one r/w branch to write a particular > file (or at least offering some way to force a particular > open/copy into a deeper branch)? Wait for our journal article please. :-) > Any thoughts on the possibilities here welcome. Thanks. > - Gordon @ IA Erez. _______________________________________________ unionfs mailing list unionfs@mail.fsl.cs.sunysb.edu http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs --------------060709020005050607050203--