All of lore.kernel.org
 help / color / mirror / Atom feed
From: Koji Sato <koji-sG5X7nlA6pw@public.gmane.org>
To: NILFS Users mailing list <users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org>
Subject: Re: Garbage Collection Schemes
Date: Fri, 30 Nov 2007 09:59:00 +0900	[thread overview]
Message-ID: <474F6054.9050905@osrg.net> (raw)
In-Reply-To: <200711261512.11121.jsa-MJZuZBXGww0Jmq/UkTHWNaxOck334EZe@public.gmane.org>

Hello John.
Sorry for my late reply.

> I am new to NILFS, so bear with me.
> 
> I would like to ask, (without reading the entire archive of messages) if
> any thought to other garbage collection schemes has been contemplated.
> 
> For instance: This file system looks like it might be very useful for 
> certain types of environments where N sequential revisions of documents
> must be maintained, regardless of the  age or how any given document relates
> to other documents.
> 
> Checkpoints do not seem to do this.
> 
> I would like to see garbage collection options that allow (for example)
> 10 copies retained (of EACH file), each bearing different dates.  
> 
> Garbage collection would erase the 11th (oldest copy) if, (and only if) the 
> other 10 all had different dates.  This prevents the situation where one user 
> (or rogue process) re-saving a document 15 times a day wipes out all prior 
> copies.
> 
> An option might be garbage collection not based on a NUMBER of iterations
> but rather a period of time (3 years, 7 years, etc, while still purging same 
> date (or same hour, minute, etc) copies.
> 
> This type of garbage collection is found almost nowhere, and this
> file system seems to be the closest possible candidate to do this.
> 
> There are applications, where a consistent representation of all 
> files at a specific point in time (snapshot or checkpoint) is LESS
> important than the ability to roll back individual documents to 
> a number of prior iterations or a number of years.
> 
> Legal documents, financial records, code version archiving, etc, all
> have these requirements.

In the current implementation, NILFS does not automatically create
snapshots. If daily or weekly snapshots are required to be made, the
chcp command should be periodically invoked (using cron or other
mechanisms). The implementation of the automatic snapshot creation based 
on user-defined retention policy is one of our future works. Please let 
us know if you have any suggestion or comment.

Thanks you.

-- 
Koji Sato
Open Source Software Computing Project
NTT Cyber Space Laboratories
Nippon Telegraph and Telephone Corporation

      parent reply	other threads:[~2007-11-30  0:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-26 23:12 Garbage Collection Schemes John Andersen
     [not found] ` <200711261512.11121.jsa-MJZuZBXGww0Jmq/UkTHWNaxOck334EZe@public.gmane.org>
2007-11-29  3:11   ` Gergely Gábor
2007-11-30  0:59   ` Koji Sato [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=474F6054.9050905@osrg.net \
    --to=koji-sg5x7nla6pw@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.