[prev in list] [next in list] [prev in thread] [next in thread] 

List:       evms-devel
Subject:    Re: [Evms-devel] set up mirror and stripe on an old system with a
From:       Jeremy Jackson <jerj () coplanar ! net>
Date:       2004-05-14 11:20:35
Message-ID: 40A4AB83.5030704 () coplanar ! net
[Download RAW message or body]

Kevin Corry wrote:
> On Tuesday 11 May 2004 4:12 pm, Jeremy Jackson wrote:

> There were some discussions on lkml a little while back about wanting to 
> "merge" DM and MD at some point. A number of people seem interested in the 
> idea, but I don't believe anyone has started designing/coding anything yet. 
> Search the lkml archives for discussions about "EMD".

The metadata updates need to be in the kernel.  When I go to single user 
mode, I don't want the array to die.
device-mapper has a better user-space API than md.
compatibility with many metadata formats should note duplicate io-path code.

I haven't studied the EMD proposal in detail, but here's .02:

This guy's got it:

From:       Jeff Garzik <jgarzik () pobox ! com>

http://marc.theaimsgroup.com/?l=linux-kernel&m=108043451920267&w=2

	I do think that metadata management needs to be fairly cleanly
	separately (I like what emd did, there) such that a user needs
	three in-kernel pieces:
	* device mapper
	* generic raid1 engine
	* personality module

There are 3 layers... not quite those 3 though.

1) the bottom is device-mapper, handling the io path,  block duplication 
for raid1, parity for raid5, and disk failure handling.  This encompases 
the "device mapper" and "generic raid1 engine" mentioned in the above 
post.  No metadata code please, just use the callback provided by the 
personality module when the array dm mappings were set up.  Quick, 
everyone get rid of your io code (the ATA-Raid1 modules are candidates) 
and use DM.

2) The "personality module(s)" can handle the disk failure events, by 
updating whatever metadata format they support.  Most of the current MD 
logic should be moved here, just changed to use DM as the io-path.  No 
iopath code in this layer please, just handle the iopath events and 
update your metadata & signal userspace module (it's free to ignore if 
it's API can't pass to userspace)

3) The userspace communication layer modules can provide dm, md, or 
other APIs.  of course dm would likely be the best, but letting others 
continue to use the MD API would allow the common code to be merged, 
while not alienating one user group or the other.  (well ok someone 
usually gets upset)

Do as much in userspace as possible, like setting up new disks' metadata.

Darn that's a lot of work!  I would really benefit from a community 
approach.  A united one more so.  Consider this an open call to all cat 
herders.

Regards,

Jeremy

> 
> Obviously RAID-linear and RAID-0 can already be done in DM (since EVMS already 
> does). Multipath development has also already moved to DM. So the real 
> discussion is how to merge RAID-1, -5, and -6. There's already a mirroring 
> module for DM (in the -udm patchset), which could/should be used to "merge" 
> RAID-1. No work has been done yet on adding RAID-5 or -6 support in DM.
> 
> If you have some concrete ideas, please let us know. You might also want to 
> cross-post to linux-kernel and/or linux-raid.
> 


-- 
Jeremy Jackson
Coplanar Networks
(519)897-1516
http://www.coplanar.net


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
Evms-devel mailing list
Evms-devel@lists.sourceforge.net
To subscribe/unsubscribe, please visit:
https://lists.sourceforge.net/lists/listinfo/evms-devel
[prev in list] [next in list] [prev in thread] [next in thread]