On 04/27/16 18:40, Juan Alberto Cirez wrote: > If this is so, then it leaves even confused. I was under the > impression that the driving imperative for the creation of btrfs was > to address the shortcomings of current filesystems (within the context > of distributed data). That the idea was to create a low level > filesystem that would be the primary choice as a block/brick layer for a > scale-out, distributed data storage... I can't speak for who was or is motivated by what. Btrfs was a necessary reaction to ZFS, and AFAIK this had nothing to do with distributed storage but rather growing concerns around reliability (checksumming), scalability and operational ease: snapshotting, growing/shrinking etc. It's true that some of btrfs' capabilities make it look like a a good candidate, and e.g. Ceph started out using it. For many reasons that didn't work out (AFAIK btrfs maturity + extensibility) - but it also did not address a fundamental mismatch in requirements, which other filesystems (ext4, xfs) could not address either. btrfs simply does "too much" because it has to; you cannot remove or turn off half of what makes a kernel-based filesystem a usable filesystem. This is kind of sad because at its core btrfs *is* an object store with various trees for metadata handling and whatnot - but there's no easy way to turn off all the "Unix is stupid" stuff. AFAIK Gluster will soon also start managing xattrs differently, so this is not limited to Ceph. I've been following this saga for several years now and it's absolutely *astounding* how many bugs and performance problems Ceph has unearthed in existing filesystems, simply because it stresses them in ways they never have been stressed before..only to create the illusion of a distributed key/value store, badly. I don't want to argue about details, you can read more about some of the reasons in [1]. [grumble grumble exokernels and composable things in userland grumble] cheers Holger [1] http://www.slideshare.net/sageweil1/ceph-and-rocksdb -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
