linux-kernel - Re: [PATCH] fs: Add romfs version 2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8734b7880708060043i125419e0w3db5d4431496985f@mail.gmail.com>
Date:	Mon, 6 Aug 2007 17:43:54 +1000
From:	"Lindsay Roberts" <lindsay.roberts.os@...il.com>
To:	"Pavel Machek" <pavel@....cz>
Cc:	"Matt Mackall" <mpm@...enic.com>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	celinux-dev@...e.celinuxforum.org
Subject: Re: [PATCH] fs: Add romfs version 2

On 7/26/07, Pavel Machek <pavel@....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.

-- Lindsay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/