| |||||||||||||
|
| |||||||||||||
The 2007 Linux Storage and File Systems WorkshopThe 2007 Linux Storage and File Systems WorkshopPosted Mar 20, 2007 11:22 UTC (Tue) by nix (subscriber, #2304)In reply to: The 2007 Linux Storage and File Systems Workshop by job Parent article: The 2007 Linux Storage and File Systems Workshop
s/better/worse/
Tail packing gives you all the complexity and potential bugs of blocksizes != PAGE_SIZE (namely, that multiple files in a single page read off disk should end up in different pages in the page cache) combined with offset horrors and repacking nightmares (how do you handle expansion of a file currently located at the start of a tail-packed group? You need to unpack on the fly and so on. Unless you're careful you may end up with file *shrinkage* requiring new data blocks...)
Tail packing strikes me as being like softupdates: a really nice idea but *so* hard to get right that it's probably not worth it. (I remain astonished that anyone managed to implement either at all.)
(Log in to post comments)
The 2007 Linux Storage and File Systems Workshop Posted Mar 20, 2007 19:35 UTC (Tue) by job (subscriber, #670) [Link] I see. I kind of assumed the block cache was aware of the tails so to avoid caching the same data twice. I figured that must be quite simple compared to freeing/moving all those sub-blocks, which obviously is possible since Reiser can do it (and fast, too).
The 2007 Linux Storage and File Systems Workshop Posted Mar 22, 2007 11:53 UTC (Thu) by nix (subscriber, #2304) [Link] The page cache is aware of blocksizes differing from PAGE_SIZE, which provides a lot of what's needed, but that code is complex and delicate, and extending it to allow pieces of multiple files to co-exist in a single page-cache page is quite unlikely to be done (the memory savings are, after all, marginal, at half a page per file, and the complexity increase is significant).
|
|
||||||||||||