[lkml]   [2007]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] fs: Add romfs version 2
On Mon, Aug 06, 2007 at 05:43:54PM +1000, Lindsay Roberts wrote:
> On 7/26/07, Pavel Machek <> wrote:
> > If the fs is read-only.. can we do some tail packing and get _both_
> > speed and space efficiency?
> You mean don't block align files of size less than 1k, and
> intelligently pack them into the gaps left by files that are aligned?
> Does seem that most noticeable performance issues occur on sequential
> reads of large files, this sounds like a good idea, but I would
> welcome comments on this.
> Also I assume romfs currently has a small hidden benefit as a result
> of it storing its file data serially after the inode: the initial read
> of the inode reads and therefore caches the block containing the
> (initial) file data. Obviously with block aligned file data this only
> applies if sequential prefetching is performed. I'd be interested to
> know if this is an issue worth regarding.

It seems to me that the initial design goals of romfs were:

a) space efficiency
b) simplicity

..with performance basically ignored. On an actual ROM-backed
filesystem, alignment doesn't help you until it becomes large enough
that you can execute pages in place.

And I don't think your reproduceability concern was even on the radar.
So naming a new filesystem romfs which has the priorities:

a) performance
b) reproduceability

seems like it's going to disappoint and confuse people who were
aligned with the original goals.

Mathematics is the supreme nostalgia of our time.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-08-06 19:23    [W:0.050 / U:2.020 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site