From: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
To: joern@logfs.org
Cc: akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] nilfs2: continuous snapshotting file system
Date: Sat, 30 Aug 2008 01:37:29 +0900 (JST) [thread overview]
Message-ID: <20080830.013729.49169215.ryusuke@osrg.net> (raw)
In-Reply-To: <20080829104459.GB27647@logfs.org>
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
next prev parent reply other threads:[~2008-08-29 16:38 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-20 2:45 Ryusuke Konishi
2008-08-20 7:43 ` Andrew Morton
2008-08-20 8:22 ` Pekka Enberg
2008-08-20 18:47 ` Ryusuke Konishi
2008-08-20 16:13 ` Ryusuke Konishi
2008-08-20 21:25 ` Szabolcs Szakacsits
2008-08-20 21:39 ` Andrew Morton
2008-08-20 21:48 ` Szabolcs Szakacsits
2008-08-21 2:12 ` Dave Chinner
2008-08-21 2:46 ` Szabolcs Szakacsits
2008-08-21 5:15 ` XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system) Dave Chinner
2008-08-21 6:00 ` gus3
2008-08-21 6:14 ` Dave Chinner
2008-08-21 7:00 ` Nick Piggin
2008-08-21 8:53 ` Dave Chinner
2008-08-21 9:33 ` Nick Piggin
2008-08-21 17:08 ` Dave Chinner
2008-08-22 2:29 ` Nick Piggin
2008-08-25 1:59 ` Dave Chinner
2008-08-25 4:32 ` Nick Piggin
2008-08-25 12:01 ` Jamie Lokier
2008-08-26 3:07 ` Dave Chinner
2008-08-26 3:50 ` david
2008-08-27 1:20 ` Dave Chinner
2008-08-27 21:54 ` david
2008-08-28 1:08 ` Dave Chinner
2008-08-21 14:52 ` Chris Mason
2008-08-21 6:04 ` Dave Chinner
2008-08-21 8:07 ` Aaron Carroll
2008-08-21 8:25 ` Dave Chinner
2008-08-21 11:02 ` Martin Steigerwald
2008-08-21 15:00 ` Martin Steigerwald
2008-08-21 17:10 ` Szabolcs Szakacsits
2008-08-21 17:33 ` Szabolcs Szakacsits
2008-08-22 2:24 ` Dave Chinner
2008-08-22 6:49 ` Martin Steigerwald
2008-08-22 12:44 ` Szabolcs Szakacsits
2008-08-23 12:52 ` Szabolcs Szakacsits
2008-08-21 11:53 ` Matthew Wilcox
2008-08-21 15:56 ` Dave Chinner
2008-08-21 12:51 ` [PATCH RFC] nilfs2: continuous snapshotting file system Chris Mason
2008-08-26 10:16 ` Jörn Engel
2008-08-26 16:54 ` Ryusuke Konishi
2008-08-27 18:13 ` Jörn Engel
2008-08-27 18:19 ` Jörn Engel
2008-08-29 6:29 ` Ryusuke Konishi
2008-08-29 8:40 ` Arnd Bergmann
2008-08-29 10:51 ` konishi.ryusuke
2008-08-29 11:04 ` Jörn Engel
2008-08-29 10:45 ` Jörn Engel
2008-08-29 16:37 ` Ryusuke Konishi [this message]
2008-08-29 19:16 ` Jörn Engel
2008-09-01 12:25 ` Ryusuke Konishi
2008-08-20 9:47 ` Andi Kleen
2008-08-21 4:57 ` Ryusuke Konishi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080830.013729.49169215.ryusuke@osrg.net \
--to=konishi.ryusuke@lab.ntt.co.jp \
--cc=akpm@linux-foundation.org \
--cc=joern@logfs.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®