[d-kernel] [Fwd: Re: [Unionfs] UnionFS as step towards a big/reliable/fast virtual disk?]

[d-kernel] [Fwd: Re: [Unionfs] UnionFS as step towards a big/reliable/fast virtual disk?]

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 57 bytes --]

Еще одно интересное письмо на эту же тему.

Rgds,
Rider


[-- Attachment #2: Re: [Unionfs] UnionFS as step towards a big/reliable/fast virtual	disk? --]
[-- Type: message/rfc822, Size: 4806 bytes --]

From: Erez Zadok <ezk@cs.sunysb.edu>
To: "Gordon Mohr (Internet Archive)" <gojomo@archive.org>
Cc: unionfs@filer.fsl.cs.sunysb.edu
Subject: Re: [Unionfs] UnionFS as step towards a big/reliable/fast virtual disk?
Date: Thu, 17 Mar 2005 18:45:24 -0500
Message-ID: <200503172345.j2HNjOKf004641@agora.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