On Tue, 29 Dec 2015 19:06:44 +0100 David Sterba <dste...@suse.cz> wrote:
> 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. I was having misgivings about the conversion project, but after re-reading this part, I will try and get a patch in by Wednesday. I still have my reservations about the following two parts: - Checksumming: I have no experience with how the CRC implementation would deal with the changed blocksizes. Would the checksum be different just because the superblock size has been changed? This would make confirming if the transformation was successful much more difficult. Another way to deal with this would be ti read the data instead and compare it directly, instead of using checksums. - Performance: Should it have a higher throughput by using larger data sizes (which may reduce performance in scenarios such as databases and video editing) or by having multiple transformations in parallel on smaller data blocks. I am not sure if you can implement things such as OpenMP in kernel space. Or spawn multiple kworkers in parallel to deal with multiple streams of data. I am not too worried about dealing with crashes, as we can just implement something like a table that contains the addresses currently undergoing changes (which may further reduce throughput, but make it more space) or do it by using a serial transformation, which ensures a block was committed to storage before proceeding to the next transformation. Essentially a time vs. CPU usage vs. Memory usage trade-off. Please chime in with your thoughts, developers and administrators. Thanks. -- 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
