There are different portions to a FS that actually need to be treated indivudually: - Bricks / Blocks / Blob data. - Metadata / Tags / Xactional data. The de

There are different portions to a FS that actually need to be treated indivudually: - Bricks / Blocks / Blob data. - Metadata / Tags / Xactional data. The deal is that any DB <-> FS has to support both of these separately. The Bricks/Blocks are optimized for raw performance/seek/access pattern with very low overhead; The Metadata are optimized for fancy querying / fast lookup semantics. Any DB/Key Value store for large data could be modeled on top of a volume layer, like LVM / ZVOL; This could absolutely become the foundation of a FS as well. The deal is that extensible / flexible storage space used to be something filesystems used to provide, but those functions have been moved to a volume manager in regular systems. The reliability and metadata part can be moved to the database layer, so that leaves the filesystem doing a No-Op.