About :: TODO :: Blog :: RSS :: Old blog :: Projects :: GIT :: Gallery :: Notes

Tue, 26 Jun 2007

fsblocks and buffer heads.


Nick Piggin from SuSE announced several days ago his rework of the buffer_head interface, which is used as a layer between block layer and filesystems. Its main goal is to obtain a memory region which directly represents content of the storage if read, or memory region, which will be written to the given position on storage. Buffer heads have number of disadvantages, mainly high overhead and possibility to deadlock writeout (i.e. to write a page to disk to free it it might require to have additional allocation). Interface is not that good too.
Fsblocks are supposed to fix that. Although it does have set of advantages over buffer_heads already, not everyone is happy with approach - namelt XFS guys, who want to be able to map arbitrary blocks to storage, namely extents, so better name was suggested - 'buffer_heads on steroids' only due to existing limits of both buffer_heads and fsblocks. So far, only minix filesystem was converted to fsblocks, so there are quite a lot of work yet to be done.

This discussion forced me to recall my fs design notes, one of the main issues I wanted was/is to avoid buffer_heads usage at all (well, it is only needed to map a page without the ugly needs to have a buffer_head for each block which can reside in the given page), i.e. each object on the storage is always aligned to a page size (PAGE_CACHE_SIZE actually, which is 4k), i.e. each inode will have about 100-200 bytes of control information and then will have the rest of the page filled with file's a or directory entries. That would greatly speedup small file lookup and processing as long as directory reading (including fairly trivial directory readahead absence of which is a serious limitation of ext234 filesystems, which leadsto major directory reading performance degradation when directory contains decent amount of files/subdirs).
Such approach can be described by something which gets good parts from both extents and delayed allocation.
So far it is a silent sleeping idea, maybe I will discuss it on KS.

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

Comments are closed for this story.