Re: [PATCH] BTRFS: Adds an option to select RAID Stripe size

[Sanidhya Solanki <jpage.lkml@gmail.com>]

On Tue, 29 Dec 2015 19:06:44 +0100
David Sterba <dsterba@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.