All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Useche <luis-43oy+cWvsXk3uPMLIKxrzw@public.gmane.org>
To: NILFS Users mailing list <users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org>
Subject: Re: Stressing GC
Date: Fri, 12 Jun 2009 11:02:12 -0400	[thread overview]
Message-ID: <20090612150212.GA15879@meg.local> (raw)
In-Reply-To: <debc30fc0906110951j4d32efb1xd3f73c0cd07a06e1-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Thu, Jun 11, 2009 at 12:51:17PM -0400, Jérôme Poulin wrote:
> >
> > On Thu, Jun 11, 2009 at 11:39:50AM -0400, Luis Useche wrote:
> > With the current GC implementation, I am unable to do my experiment. I set
> > "protection_period 0" but still have the problem. Besides, this is
> > probably not the right solution either since the GC can do unnecessary work
> > that can underestimate the potential of nilfs. I need the first option (1)
> > from the first paragraph above.
> >
> 
> For this situation, would it be possible instead, to have to GC collect all
> the space that can be freed, have the filesystem informed of what blocks can
> be freed anytime (like a memory cache which can be flushed anytime), and
> have the FS give the free space information for what it calculated as
> removable? So with this we could have checkpoint for longuer than the
> protection_period and still have the free space available for thing the
> filesystem can just overwrite. I really don't know how it is coded as I'm
> just a user for now, but that would be even greater.

I am in favor of this solution. Ideally, if the user does not want to
protect any data (like in my case), the filesystem should not report space
shortage when plenty of space is available to overwrite. Instead, the GC
must start working right away to make enough room for the incoming writes.

-- 
Luis Useche <luis-43oy+cWvsXk3uPMLIKxrzw@public.gmane.org>
Ph.D. Student
Florida International University

      parent reply	other threads:[~2009-06-12 15:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-10 21:08 Stressing GC Luis Useche
     [not found] ` <20090610210859.GA17619-F34IG+UkkWQ4ZZIPogyGsg@public.gmane.org>
2009-06-11  4:17   ` Dave
     [not found]     ` <4A30856F.3000103-/hCUnnzDXf0AvxtiuMwx3w@public.gmane.org>
2009-06-11 15:39       ` Luis Useche
     [not found]         ` <20090611153950.GA26921-F34IG+UkkWQ4ZZIPogyGsg@public.gmane.org>
2009-06-11 15:20           ` Reinoud Zandijk
     [not found]             ` <20090611152040.GF21314-5cYspOl2ggRz6xQTk39kMVfVdRo2wo/d@public.gmane.org>
2009-06-11 16:51               ` Jérôme Poulin
     [not found]                 ` <debc30fc0906110951j4d32efb1xd3f73c0cd07a06e1-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-06-12 15:02                   ` Luis Useche [this message]

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=20090612150212.GA15879@meg.local \
    --to=luis-43oy+cwvsxk3upmlikxrzw@public.gmane.org \
    --cc=users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.