On Thu, May 21, 2009 at 7:48 AM, Neil Brown <neilb@xxxxxxx> wrote: > On Tuesday May 19, dan.j.williams@xxxxxxxxx wrote: >> On Sat, May 2, 2009 at 2:46 PM, raz ben yehuda <raziebe@xxxxxxx> wrote: >> > Neil Hello >> > The bellow is the raid0 grow code.I have decided to fix raid0 and not >> > perform the transformation raid0-raid4-raid0 due to two reasons: >> > 1. raid0 zones. this patch support any zone transformations. >> > 2. Undesired dependency of raid0 over raid4 re-striping code. >> >> Hi Raz, >> >> Can you explain a bit more about why the raid4 approach is >> undesirable? I think making reshape only available to raid0 arrays >> where all the members are the same size is a reasonable constraint. >> We then get the nice benefit of reusing the raid5 reshape >> infrastructure. In other words I am not convinced that the benefits >> of reimplementing reshape in raid0 outweigh the costs. > > I've been thinking about this too... Is it something we really want to > do? > > My thoughts include: > > - I don't like special cases - it would be nice to support reshape on > all arrays, even RAID0 with different sizes devices. > - Anyone who does this with a raid0 made of simple drives is asking > for trouble. But a RAID0 over a bunch of RAID5 or RAID1 might make > sense. > - Maybe we should support different sized drives in RAID4. As long > as the parity drive is as big as the largest data drive it could be > made to work. Similarly hot spares would need to be big, but you > could have 2 hot spares and take the smallest one that is big > enough. > If a drive in the RAID4+ (or is it is the thing called NORAID?) > failed and was replaced with a bigger drive, it would be cool to be > able to incorporate that extra space into the array. > > If we did all that, then the 0->4->0 conversion could make use of > the same code. > - Surely RAID0 is (like LVM) just a legacy idea until we get sensible > file systems that actually understand multiple devices and do all > this stuff for you are a more sensible level - so why are we > busting a gut(*) to make RAID0 work well?? Answer is of course > that no-one has made a sensible file system yet. (well... maybe zfs > or btrfs, not sure) > - If you read the DDF spec carefully, you find there is a secondary > raid level which stripes over heterogeneous arrays a different way. > You divide every primary array up into N chunks, so the chunk sizes are > different on different arrays. Then you make a secondary array by > striping over those chunks. > So e.g. you might have a 4Gig RAID5 and a 1GIG RAID1. So the > stripes array on top of these could take 4Meg from the RAID5, then > 1Meg from the RAID1, then another 4 from the RAID5 etc. > So we want to support that? And would we want to reshape such a > thing?? > > So: lots of thoughts, some pointing in different directions. > But I'm not against reshape code appearing in RAID0 providing it is > well designed, maintainable, reliable, and doesn't slow down normal > RAID0 processing. I suspect we can get there. > > NeilBrown This may be in a FAQ / wiki somewhere, but is the long range plan of mdraid to stick to the formal "raid levels" or to implement "raid equivalent levels". I am a big fan of the raid equivalent concept and would love to see mdraid moving in that direction. ==> What I mean by raid equivalent levels More and more arrays allow the user to simply say "give me a 100 GB logical volume with Raid 5 equivalent protection. The array then looks at the drives it has available and puts together the necessary pieces. As drives are added, removed it moves the data around under its own control, but maintains the raid equivalent protection. Especially when working with dozens of drives and lots of logical volumes it makes life much easier. Admittedly it may come at a cost of not being able to specify raid levels with the specificity that mdraid currently allows. ==> The reason I ask if this is the goal is that doing so may factor into decisions about how reshaping is implemented. Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
