lkml.org 
[lkml]   [2008]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH RFC] nilfs2: continuous snapshotting file system
>On Wed, 20 Aug 2008 11:45:05 +0900 Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> wrote:
>
>> This is a kernel patch of NILFS2 file system which was previously
>> announced in [1]. Since the original code did not comply with the
>> Linux Coding Style, I've rewritten it a lot.
>
>I expected this email two years ago :)

I'm sorry for that. Thank you to remember this file system :)

>What approach does it take to garbage collection?

Lifetime information is maintained for each (virtualized) address of disk
block to judge whether a given disk block is eliminable or not.

The garbage collector (GC) of NILFS2 works as follows:

1. GC does not remove snapshots, which are the checkpoints marked as snapshot.
Plain checkpoints are not protected from GC except for the recent ones.

2. Disk blocks that do not belong to any snapshots nor the recent checkpoints,
are eliminable. For a given disk block, GC confirms state of every
checkpoints whose serial number is included in the lifetime. It judges
the block is not eliminable if at least one snapshot or a recent checkpoint
is included.

3. GC reclaims disk space in units of segment. (where a segment is equally
divided disk region.)

For a selected segment, removable blocks are just ignored, and
unremovable blocks (live blocks) are copied to a new log appended in the
current segment for writing.

When all the live blocks are copied into the new log, the segment becomes
free and reusable.

4. To make disk blocks relocatable, NILFS2 maintains a table file (called DAT)
which maps virtual disk blocks addresses to usual block addresses.
The lifetime information is recorded in the DAT per virtual block address.

The current NILFS2 GC simply reclaims from the oldest segment, so the disk
partition acts like a ring buffer. (this behaviour can be changed by
replacing userland daemon).

>> Some impressive benchmark results on SSD are shown in [3],
>
>heh. It wipes the floor with everything, including btrfs.
>
>But a log-based fs will do that, initially. What will the performace
>look like after a month or two's usage?

I'm using NILFS2 for my home directory for serveral months, but so far
I don't feel notable performance degradation. Later, I'd like to try
a benchmark for a server.
Anyhow, I have many things to do for performance.

>> however the
>> current NILFS2 performance is sensitive to machine environment due to
>> its immature implementation.
>> ..
>> It is not yet divided into pieces (sorry). Unlike original code
>> available at [4], many code lines to support past kernel versions and
>> peculiar debug code are removed in this patch.
>
>Yes, please do that splitup and let's get down to reviewing it.

Sure, I will.

With regards,
Ryusuke Konishi


\
 
 \ /
  Last update: 2008-08-20 18:11    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site