On Tue, Dec 29, 2015 at 05:26:28AM +0100, Christoph Anton Mitterer wrote: > On Mon, 2015-12-28 at 19:03 -0500, Sanidhya Solanki wrote: > > That sounds like an absolutely ghastly idea. > *G* and it probably is ;) > > > > Lots of potential for > > mistakes and potential data loss. I take up the offer to implement > > such a feature. > > Only question is should it be in-place replacement or replace out to > > another disk or storage type. Will wait for comments on that question > > before implementing. > I guess you really should have a decent discussion with some of the > core btrfs developers (which I am not) before doing any efforts on this > (and possibly wasting great amounts of work). > > I spoke largely from the user/admin side,... running a quite big > storage Tier-2, we did many IO benchmarks over time (with different > hardware RAID controllers) and also as our IO patterns changed over > time... > The result was that our preferred RAID chunk sizes changed over > time,... > > Being able to to an online conversion (i.e. on the mounted fs) would be > nice of course (from the sysadmin's side of view)
In theory this is possible with current on-disk data structures. The stripe length is property of btrfs_chunk and changing it should be possible the same way we do other raid transformations. The implementation might be tricky at some places, but basically boils down to the "read-" and "write-" stripe size. Reading chunks would always respect the stored size, writing new data would use eg. the superblock->stripesize or other value provided by the user. > but even if that > doesn't seem feasible an offline conversion may be useful (one simply > may not have enough space left elsewhere to move the data of and create > a new fs with different RAID chunk size from scratch) Currently the userspace tools are not capable of the balance/relocation functionality equivalent. > Both open of course many questions (how to deal with crashes, etc.)... > maybe having a look at how mdadm handles similar problems could be > worth. The crash consistency should remain, other than that we'd have to enhance the balance filters to process only the unconverted chunks to continue. -- 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
