All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: Lindsay Roberts <lindsay.roberts.os@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	celinux-dev@tree.celinuxforum.org
Subject: Re: [PATCH] fs: Add romfs version 2
Date: Mon, 6 Aug 2007 12:20:03 -0500	[thread overview]
Message-ID: <20070806172002.GW11115@waste.org> (raw)
In-Reply-To: <8734b7880708060043i125419e0w3db5d4431496985f@mail.gmail.com>

On Mon, Aug 06, 2007 at 05:43:54PM +1000, Lindsay Roberts wrote:
> On 7/26/07, Pavel Machek <pavel@ucw.cz> 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.

  reply	other threads:[~2007-08-06 17:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-13  6:01 [PATCH] fs: Add romfs version 2 Lindsay Roberts
2007-07-17  8:36 ` Andrew Morton
2007-07-17 19:21   ` Matt Mackall
2007-07-18  3:16     ` Lindsay Roberts
2007-07-18 17:02       ` Tim Bird
2007-07-25  7:28         ` [Celinux-dev] " Greg Ungerer
2007-07-25 18:40       ` Pavel Machek
2007-08-06  7:43         ` Lindsay Roberts
2007-08-06 17:20           ` Matt Mackall [this message]
2007-07-30 18:12 ` Phillip Susi
2007-07-30 18:29   ` Rene Herman
2007-08-06 19:41 ` Sergey Vlasov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070806172002.GW11115@waste.org \
    --to=mpm@selenic.com \
    --cc=akpm@linux-foundation.org \
    --cc=celinux-dev@tree.celinuxforum.org \
    --cc=lindsay.roberts.os@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.