linux-kernel - Re: [PATCH 25/27] nilfs2: block cache for garbage collection

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] [day] [month] [year] [list]

Date:	Sat, 20 Sep 2008 13:04:59 +0200
From:	Jörn Engel <joern@...fs.org>
To:	Ryusuke Konishi <konishi.ryusuke@....ntt.co.jp>
Cc:	akpm@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, kihara.seiji@....ntt.co.jp,
	amagai.yoshiji@....ntt.co.jp
Subject: Re: [PATCH 25/27] nilfs2: block cache for garbage collection

On Sat, 20 September 2008 19:43:58 +0900, Ryusuke Konishi wrote:
> 
> > But that would be inefficient in several cases.  When
> > GC'ing data that is dirty in the caches, you move the old stale data
> > during GC and write the new data soon after.  And you always flush the
> > caches after GC, even if your machine has no better use for the memory.
> 
> As for as NILFS2, the dirty blocks and the blocks to be moved by GC
> never overlap because the dirty blocks make a new generation.
> So, they rather must be written individually.
> 
> Though we can reuse pages in the GC cache, the effect of this
> optimization may be much lower than usual LFSes because most of
> blocks in the pages may not belong to the latest generation.

Yet again I've tried to apply techniques that simply don't work with
checkpoints in the equation.

> NILFS2 needs explication than usual file systems; it needs time
> perspective as well as it is an LFS. :)

At least if you take me as a standard, I think you have proven that
point rather well. :)

Jörn

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
-- Brian W. Kernighan
--
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/