On Sat, Mar 09, 2013 at 10:31:25PM +0100, Harald Glatt wrote: > On Sat, Mar 9, 2013 at 9:31 PM, Hugo Mills <h...@carfax.org.uk> wrote: > > > Some time ago, and occasionally since, we've discussed altering the > > "RAID-n" terminology to change it to an "nCmSpP" format, where n is the > > number of copies, m is the number of (data) devices in a stripe per copy, > > and p is the number of parity devices in a stripe. > > > > The current kernel implementation uses as many devices as it can in the > > striped modes (RAID-0, -10, -5, -6), and in this implementation, that is > > written as "mS" (with a literal "m"). The mS and pP sections are omitted > > if the value is 1S or 0P. > > > > The magic look-up table for old-style / new-style is: > > > > single 1C (or omitted, in btrfs fi df output) > > RAID-0 1CmS > > RAID-1 2C > > DUP 2CD > > RAID-10 2CmS > > RAID-5 1CmS1P > > RAID-6 1CmS2P > > > > The following patch set modifies userspace tools to accept C/S/P formats > > in input (mkfs and the restriper). The older formats are also accepted. It > > also prints the newer formats by default in btrfs fi df, with an option to > > show the older format for the traditionalists. > > > > I'm not sure whether we should omit the 1C in btrfs fi df output, or > > make it explicit even in the "single" case. > > > > Hugo. > > > > Hugo Mills (5): > > Use nCmSpP format for mkfs > > Move parse_profile to utils.c > > Convert balance filter parser to use common nCmSpP replication-level > > parser > > Change output of btrfs fi df to report new (or old) RAID names > > Add man page description for nCmSpP replication levels > > > > cmds-balance.c | 23 +++------ > > cmds-filesystem.c | 135 > > +++++++++++++++++++++++++++++++++++++++++++-------- > > man/btrfs.8.in | 9 ++++ > > man/mkfs.btrfs.8.in | 24 ++++++++- > > mkfs.c | 35 ++++--------- > > utils.c | 94 +++++++++++++++++++++++++++++++++++ > > utils.h | 1 + > > 7 files changed, 258 insertions(+), 63 deletions(-) > > > > -- > > 1.7.10.4 > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > I vote make it explicit to give people a chance to understand the new way > it works even with just one device. The idea for this new naming scheme is > great, I like it!! Will btrfs allow for things like 2C10SP2 too? Basically > two RAID6 arrays with 12 drives each (10 for data, 2 for parity), if I > understand it right with the entire array being mirrored to another one.
You wouldn't necessarily get exactly the same semantics. 2C10S2P would require at least 24 drives, and in the traditional "mirrored pair of RAID-6" configuration, you could lose drives 1-14, and still rebuild successfully from the the remaining degraded RAID-6 array. The btrfs implementation probably wouldn't let you go so far -- you'd only get a guarantee of being able to lose any four devices; anything after that would be quite likely to destroy the array, because the allocation of "position" to device in any given stripe isn't as regimented as for the traditional RAID configurations. Basically, both would provide the same minimum safety guarantees, but the odds of the btrfs array losing (some) data after that point are considerably higher. This is all moot for now, anyway, because as far as I know there aren't any plans for generalising this completely. Chris is definitely planning fixed values for mS (so you can ask for, say, exactly 4 stripes and one parity), and values for nC greater than 2. As far as I know, there aren't any plans for nC > 1 and pP > 0 together. I haven't got far enough into the kernel code to work out whether that's simple or not to implement. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- What's a Nazgûl like you doing in a place like this? ---
signature.asc
Description: Digital signature
