On Wed, 01 Mar 2017 07:29:28 +1100 NeilBrown <neilb@xxxxxxxx> wrote: > Thanks. That makes it easy. > Test works with my patch applied. Thanks for fixing that. If anybody is curious, the application for this capability is as follows. For live systems running from a USB flashdrive, we need to loop-mount an ext4 filesystem image from the fat32-formatted flashdrive. Unfortunately, the maximum file size on fat32 is 4GB, which is a severe limitation, when 128GB flashdrives are commonly available. The solution is to split the ext4 image into multiple sub-4GB chunks, associate a /dev/loop device with each of those files, have mdadm turn those into a single RAID device, and mount that as the ext4 filesystem. It is preferable to use non-metadata, linear-mode RAID for this, because we can then convert back and forth between the single filesystem image and its constituent chunks using the non-privileged utilities "cat" and "split". With a maximum of 27 RAID component devices, the maximum filesystem size would be 108GB, which is not quite a complete solution. On Fri, 24 Feb 2017 15:46:19 -0500 Phil Turmel <philip@xxxxxxxxxx> wrote: > Note that build mode doesn't support a bunch of other MD raid features > either, like all of the parity raid levels. That it doesn't support > v1+ metadata isn't a surprise, and isn't the only legacy feature that > only uses legacy metadata (built-in kernel auto-assembly gets the most > whining, actually). > If you think its trivial to implement --build with v1.x metadata, go > right ahead. Post your patches for review. I haven't tested "mdadm --build" with parity RAID myself (although the /dev/loop trick would probably suffice for that too), but if this is so, would the change to provide that be as simple as the patch to remove the 27-component limitation? (Although I suppose that unlike linear mode, the component devices for parity mode would have to be initialized with consistent data, first.) Somebody might find a use for non-metadata, parity-mode RAID, if it were available. -- Ian Bruce -- 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
