linux-kernel - Re: [PATCH 01/27] nilfs2: add document

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080918.025241.88481333.ryusuke@osrg.net>
Date:	Thu, 18 Sep 2008 02:52:41 +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 01/27] nilfs2: add document

On Wed, 17 Sep 2008 16:54:38 +0200, Jörn Engel wrote:
> On Mon, 15 September 2008 04:07:58 +0900, Ryusuke Konishi wrote:
> > +
> > +The logs include regular files, directory files, symbolic link files
> > +and several meta data files.  The mata data files are the files used
> > +to maintain file system meta data.  The current version of NILFS2 uses
> > +the following meta data files:
> > +
> > + 1) Inode file (ifile)             -- Stores on-disk inodes
> > + 2) Checkpoint file (cpfile)       -- Stores checkpoints
> > + 3) Segment usage file (sufile)    -- Stores allocation state of segments
> > + 4) Data address translation file  -- Maps virtual block numbers to usual
> > +    (DAT)                             block numbers.  This file serves to
> > +                                      make on-disk blocks relocatable.
> > + 5) Sketch file (sketch)           -- Keeps read-only data which can be
> > +                                      associated with checkpoints (optional)
> 
> How are the sufile and the DAT written?  If you naively stick to the
> log-structured approach, their contents will reflect a filesystem state
> prior to writing them and be outdated by the time they hit the medium.
> So either you bend the rules here and update those files in-place or you
> do something tricky.  Can you explain your solution?

That's right.  The DAT, sufile, and cpfile are written at a time so
that they will become consistent and self contained.

Checkpoint creations are predictable, so the cpfile is OK.  But the
sufile depends on the length of logs, therefore it depends on
construction of other files including DAT and the super root block.
Since the virtual block numbers are assigned also to the sufile, there
is a circulation problem.

So, nilfs2 makes the sufile in a speculative way; it will retry
collection of dirty blocks for these three files if it turned out that
more segments are required than expected.  It is not a problem for the
case that expected segments are too many because allocation of
oversupplied segments can be cancelled without breaking consistency.
nilfs2 does this retry on memory and writes the three files at a time
to avoid I/O penalty.

Regards,
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/