linux-kernel - Re: [Patch 15/18] fs/logfs/super.c

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]

Date:	Sun, 10 Jun 2007 20:33:05 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Jörn Engel <joern@...ybastard.org>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mtd@...ts.infradead.org, akpm@...l.org,
	Sam Ravnborg <sam@...nborg.org>,
	John Stoffel <john@...ffel.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Jamie Lokier <jamie@...reable.org>,
	Artem Bityutskiy <dedekind@...radead.org>,
	CaT <cat@....com.au>, Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	Evgeniy Polyakov <johnpol@....mipt.ru>,
	David Weinehall <tao@....umu.se>, Willy Tarreau <w@....eu>,
	Kyle Moffett <mrmacman_g4@....com>,
	Dongjun Shin <djshin90@...il.com>, Pavel Machek <pavel@....cz>,
	Bill Davidsen <davidsen@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Albert Cahalan <acahalan@...il.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Roland Dreier <rdreier@...co.com>,
	Ondrej Zajicek <santiago@...reenet.org>,
	Ulisses Furquim <ulissesf@...il.com>
Subject: Re: [Patch 15/18] fs/logfs/super.c

On Sunday 10 June 2007, Jörn Engel wrote:
> On Sun, 10 June 2007 18:27:49 +0200, Arnd Bergmann wrote:
> > On Sunday 03 June 2007, Jörn Engel wrote:

> > How about using submit_bio here instead of going to the page cache?
> > That would avoid doubling all the memory consumption here.
> 
> That may make sense, yes.  "May", because there is no simple mapping
> between physical data and logical data.  In ext3, everything is
> block-aligned, usually to 4KiB == PAGE_SIZE.  So the exact same content
> would exists in two pages.  In LogFS, data is compressed and
> byte-aligned.  A bdev page can contain several full objects that after
> uncompression get stored in one page each.

Then maybe the submit_bio logic should only be done for the ->write
path, not for ->read. The data that gets written out should already
be present in the page cache for the files, so there is not much point
having again, while you can see the read path as blockdev readahead:
When you read a physical block that contains a logical block, it's
likely to also contain part of another logical block that is going
to be read in the near future.

This way, you would also get exclusively clean pages in the block
device address_space, which can be easily discarded.

Also, maintaining correct ordering between write requests can be
done easier if you insert the bios directly, instead of waiting
for the lru writeback.

	Arnd <><
-
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/