> With RAID-Z stripes can be of variable width meaning that, say, a > single row > in a 4+2 configuration might have two stripes of 1+2. In other words, > there > might not be enough space in the new parity device.
Wow -- I totally missed that scenario. Excellent point. > I did write up the > steps > that would be needed to support RAID-Z expansion Good write up. If I understand it, the basic approach is to add the device to each row and leave the unusable fragments there. New stripes will take advantage of the wider row but old stripes will not. It would seem that the mythical bp_rewrite() that I see mentioned here and there could relocate a stripe to another set of rows without altering the transaction_id (or whatever it's called), critical for tracking snapshots. I suspect this function would allow background defrag/coalesce (a needed feature IMHO) and deduplication. With background defrag, the extra space on existing stripes would not immediately be usable, but would appear over time. Many thanks for the insight and thoughts. Bluntly, how can I help? I have cut a lifetime of C code in a past life. Cheers, Marty -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
