On 19/05/13 20:34, Chris Murphy wrote: > On May 19, 2013, at 12:59 PM, Martin <m_bt...@ml1.co.uk> wrote: >> >> btrfs-raid offers a greater variety and far greater flexibility of >> raid options individually for filedata and metadata at the >> filesystem level. > > Well it really doesn't. The btrfs raid advantages leverage prior work > that makes btrfs what it is.
Indeed, the "btrfs raid" as evolving looks to be tightly part of btrfs itself, shaped by what is being done in btrfs... And also there is the work going into how the 'raid' semantics operate for data and the filesystem metadata. Also tied into that is storage balancing and load (io bandwidth) balancing with most recently developers looking how to move 'hot' data onto preferred physical drives? >> OK... So we make all of lvm, md-raid, and drbd all redundant! > > No they are different things for different use cases. What you seem > to be asking for is for a ZFS-like feature that allows other file > systems to exist on ZFS, and thereby gaining some of the advantage of > the underlying file system. That's going a little too deep... My thoughts are much more shallow. Can the raid and load balancing work being done for btrfs be bundled up so as to permit that to also be used instead as a filesystem layer that then utilises /any/ underlying filesystem? So, instead of btrfs style file-level raid and load balancing only on devices which have been formatted with btrfs, the raid and load balancing operates as a filsystem layer that coordinates storing files on any motley collection of multiple whatever filesystem-on-device. Obvious enough for raid1 to 'tee' a file out to multiple filesystems. For the other raids, filenames would need to be munged to denote their multiple parts (simply always append a 6 character index?). raid0 would need a file to be split into parts and then those file parts concatenated upon reading under the original filename. raid5/6 would similarly need file splitting but also the data redundancy added. For example, for paranoid redundancy and fast operation: raid1 + load balance | V btrfs on HDD1, ext4 on HDD2, NILFS on flash1, nfs to host2 Obviously, doing that loses any features (such as snapshots) not common across all the group. As for a use case? Would that be a good idea or not? :-) One thought is that users could set up funky redundant operation across networked devices using nfs. Another thought is that we go to an awful lot of trouble to accommodate extremely different storage technologies that are only ever going to physically diverge further. For example, we have HDDs and SSDs. We also have much cheaper flash with very limited wear levelling ideal for 'cold' data. Or even raw flash without all the proprietary firmware obscurity... Hence dedicate a particular filesystem to each rather than one monster for all? The "raid + load balance" could be a well defined layer with no or few special hooks into the lower layers. All just a thought... Regards, Martin -- 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
