[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080827181904.GD1371@logfs.org>
Date: Wed, 27 Aug 2008 20:19:04 +0200
From: Jörn Engel <joern@...fs.org>
To: Ryusuke Konishi <konishi.ryusuke@....ntt.co.jp>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] nilfs2: continuous snapshotting file system
On Wed, 27 August 2008 01:54:30 +0900, Ryusuke Konishi wrote:
> On Tue, 26 Aug 2008 12:16:19 +0200, Jorn Engel wrote:
> >
> >Interesting approach. Does that mean that every block lookup involves
> >two disk accesses, one for the DAT and one for the actual block?
>
> Simply stated, it's Yes.
>
> But the actual number of disk accesses will become fewer because the DAT is
> cached like regular files and read-ahead is also applied.
> The cache for the DAT works well enough.
Yep. It is not a bad tradeoff. You pay with some extra seeks when the
filesystem is freshly mounted but gain a lot of simplicity in garbage
collection.
More questions. I believe the first two answer are no, but would like
to be sure.
Do you support compression?
Do you do wear leveling or scrubbing?
How does garbage collection work? In particular, when the filesystem
runs out of free space, do you depend on the userspace daemon to make
some policy decisions or can the kernel make progress on its own?
Jörn
--
There are two ways of constructing a software design: one way is to make
it so simple that there are obviously no deficiencies, and the other is
to make it so complicated that there are no obvious deficiencies.
-- C. A. R. Hoare
--
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/
Powered by blists - more mailing lists