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-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
