Date: Wed, 17 Jun 2015 14:36:24 -0700 From: John Nemeth <jnem...@cue.bc.ca> Message-ID: <201506172136.t5hlaogg020...@server.cornerstoneservice.ca>
| Given that a GPT typically has a minimum of 128 slots, would | you do gpt->raid->gpt? Why not just create a sufficient number of | RAID partitions? Recovery workload. Consider 2 drives, on which there are to be 30-40 filesystems, all mirrored. One raid, with 40 partitions (wedges) on it is one possibility, 40 partitions (wedges) each containing a raidframs, each containing a single filesystem is another. When everything is working (and to some extent, initial config) there is little real difference between those two approaches (the gtp->raidframs way means more raidframe overhead but that is not really significant). But when one of the drives dies, and is replaced, the raidframe->gpt way requires (the operator) to arrange reconstruction of a single raid array (issuing raidctl to add in the replacement) just once, the gtp->raidrame way required doing that once for each of he raid arrays. For me, that's enough to prefer fewer raid arrays. Of course, if a drive develops bad spots, the single raidframe approach will fail that drive, and none of the filesystems will be mirrored until the drive is replaced or the bad spots corrected - the multiple raidframe approach will only file the arrays where the bad spots occur, other filesystems would remain mirrored. kre