It won't help here, but something similar is useful. For small files,
all 15 block pointers can be direct. When you need the first indirect
block pointer, the 3 extra block pointers go into the new block.
Now you have 12 direct block pointers and 3 indirect block pointers
in the inode. As soon as you need a double-indirect block pointer,
evict the extra two indirect block pointers and put them in the
double-indirect block. Now you have two double-indirect block pointers
in the inode. Evict one when you need a triple-indirect block pointer.
This is a lot of complexity for probably very little gain. The major
savings come from files of very specific sizes: 12k to 15k. From an
academic viewpoint, it's a neat hack. From an engineering perspective,
it's almost certainly not worth it.
There's a similar idea which was floated around earlier, which involved
storing the actual data of files of less than 60 bytes in the inode
itself itself. We do this for symbolic links, since most symbolic links
need less than 60 bytes worth of space. But the number of data files
which are smaller than 60 bytes are so small as to be insignificant, and
so the extra complexity simply wasn't worth it.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu