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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 18 Sep 2008 00:49:53 +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 Thu, 18 September 2008 04:09:45 +0900, Ryusuke Konishi wrote:
> 
> > Using dummy inodes is... unusual.  Why can you not use the actual inodes
> > those blocks belong to?
> 
> Because we have to treat blocks that belong to a same file but have
> different checkpoint numbers.  (NILFS2 keeps up multiple
> checkpoints/snapshots across GC)
> 
> Of course, if the standard inode hash is applicable, I prefer it.
> ilookup5 or its variant may be applicable for this.

If that is possible I would definitely prefer it.

> If so, the remaining problem would be the lock dependencies as you
> mentioned before.

You should have the same problem already - in some shape or another.  If
you can have two data structures for the same content, a real inode and
a dummy inode, you have a race condition.  Quite possibly one involving
data corruption.

Well, one way to avoid both the race and the locking complexity is by
stopping all writes during GC and destroying all dummy inodes before
writes resume.  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.

So unless I missed something important, I believe the locking is well
worth the effort.

BTW: Some of the explanation you just gave me would do well as
documentation in the source file as well.  That's the sort of background
information new developers can spend month of mistakes and reverse
engineering on. :)

Jörn

-- 
Those who come seeking peace without a treaty are plotting.
-- Sun Tzu
--
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/