Zbr's days.
October
Sun Mon Tue Wed Thu Fri Sat
 
14
     
2007
Months
Oct

About TODO Blog RSS Old blog Projects Gallery Notes

Sun, 14 Oct 2007

Scaling inodes.

I have in mind an interesting design idea of the inode management structure in my (so far theoretical future) filesystem - so called scaling inodes. Basic idea is to have inodes of the several standard sizes like 256, 512, 1k, 2k and 4k, which will contain meta-information about data object and its data embedded at the end of the structure. Such design reduces number of seeks to get data from disk, reduce fragmentation, since bigger inodes will be allocated at the new locations as a new object, allows to reuse old one for new inode, simplifies copy-on-write semantics, greatly reduce directory reading speed (for limited degree though - there is number of factors - for example my current mainline 2.6 git tree contains about 1500 objects, files with smaller than 4k is more than 60%, about the same statistics is for /etc: about 1600 total, where more than 1300 are smaller than 4k).
This is of course a total speculation, but idea worth further investigation...

/devel/fs :: Link / Comments (0)

Please solve this captcha to be allowed to post (need to reload in a minute): 6 * 28

Comments are closed for this story.