On Fri, Jun 09, 2006 at 11:25:02PM -0600, Andreas Dilger wrote: > > The 48-bit support was acutally only a small of the originalreason for > extents, while it seems to be the most popular right now. *nod* > This needs some extra data in the directory entry, which I've already > been thinking about for ext3, so if you are looking at implementing > this for ext3 I'd be happy to share some ideas. Actually, it seems vaguely possible this could be implemented as a layer on top of any normal file system - just use files to store continuation inodes and the like. Then you could use the file system that best suits your workload underneath. (Suparna has a paper in the next OLS talking about something related but not identical, check it out.) Most likely it would be criminally wasteful of space and really slow, but it's something to think about. > > One interesting possibility would be to combine this with the ext2 > > dirty bit patches. > > Put on your asbestos vest before suggesting any changes to ext2 :-). *laugh* What about ext2.5? :) Seriously, ext2 needs to be left alone, but I'm open to the possibility that any of the existing file system code bases could be forked off into a development file system. Some ideas would be more compatible with some code bases than others, and forking might get rid of some constraints - e.g., an XFS fork could get rid of a lot of crufty compat code. -VAL - 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
