[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080830.013729.49169215.ryusuke@osrg.net>
Date: Sat, 30 Aug 2008 01:37:29 +0900 (JST)
From: Ryusuke Konishi <konishi.ryusuke@....ntt.co.jp>
To: joern@...fs.org
Cc: akpm@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] nilfs2: continuous snapshotting file system
On Fri, 29 Aug 2008 12:45:00 +0200, Jörn Engel wrote:
> > The GC of NILFS depends on the userspace daemon to make policy decisions.
> > NILFS cannot reclaim disk space on its own though it can work
> > (i.e. read, write, or do other operations) without the daemon.
> > After it runs out of free space, disk full errors will be returned
> > until GC makes new space.
>
> This looks problematic. In logfs I was very careful to define a
> "filesystem full" condition that is independent of GC. So with a single
> writer, -ENOSPC always means the filesystem is full and the only way to
> gain some free space is by deleting data again.
> ...
> > But, usually the GC will make enough disk space in the background
> > before that occurs.
>
> Usually, yes. You just have to make sure that in the unusual cases the
> filesystem continues to behave correctly. ;)
As the side remark, the GC of nilfs runs in the background, not
started after it runs out of free space. Basically the intended
meaning of -ENOSPC is same; it does not mean the GC is ongoing, but
means the deletion is required. Of course this depends on the
condition that the GC has been working with enough speed, so the
meaning is not assured strictly. But, at least I won't return -ENOSPC
so easily, and will deal it more politely if needed.
On the other hand, there are some differences in premise because nilfs
is aiming at racking up past user data and makes it a top priority to
keep data which is overwritten by recent updates. If users want to
preserve much data in nilfs, it will increase the chance of disk fulls
than regular file systems.
Cheers,
Ryusuke
--
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