Andreas Dilger wrote: > Too bad everyone is spending time on 10 similar-but-slightly-different > filesystems. This will likely end up with a bunch of filesystems that > implement some easy subset of features, but will not get polished for > users or have a full set of features implemented (e.g. ACL, quota, fsck, > etc). While I don't think there is a single answer to every question, > it does seem that the number of filesystem projects has climbed lately. > > Maybe there should be a BOF at OLS to merge these filesystem projects > (btrfs, chunkfs, tilefs, logfs, etc) into a single project with multiple > people working on getting it solid, scalable (parallel readers/writers on > lots of CPUs), robust (checksums, failure localization), recoverable, etc. > I thought Val's FS summits were designed to get developers to collaborate, > but it seems everyone has gone back to their corners to work on their own > filesystem? > > Working on getting hooks into DM/MD so that the filesystem and RAID layers > can move beyond "ignorance is bliss" when talking to each other would be > great. Not rebuilding empty parts of the fs, limit parity resync to parts > of the fs that were in the previous transaction, use fs-supplied checksums > to verify on-disk data is correct, use RAID geometry when doing allocations, > etc. How many of these feature could be (at least partially) implemented in the core code so that it was easier to port filesystems to use them. Certainly versioning should be able to be implemented, possible without any FS support at all, in the core code. Centralising the implementations could allow a great deal of FS custiomisation/improvements with very little new per FS code. Jack - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
