On Tue, 29 Dec 2015 05:26:28 +0100 Christoph Anton Mitterer <cales...@scientia.net> wrote:
> 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,... What is your experience like about running a production system on what is essentially a beta product? Crashes? Would something like ZFS not be more suited to your environment? Especially as not all disks will be full, and, if a disk was to fail, the entire disk would need to be rebuilt from parity drives (as opposed to ZFS only using the parity data, and not copying empty blocks (another feature that is planned for BTRFS)). That alone sells me on ZFS' capabilities over BTRFS. > 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) 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) > 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. I do not believe it would be possible to guarantee crash or error recovery when using an in-place rebuild, without slowing down the entire rebuild to cache each block before replacing it with the new block. That would slow it down considerably, as you would have to: copy to cache > checksum > write in place on disk > checksum new data > verify checksums I suppose that is the only proper way to do it anyway, but it will definitely be slow. Let me know if that is acceptable, and when the developers come online, they can also input their ideas. 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
