Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem

[Jamie Lokier <jamie@shareable.org>]

Marco Stornelli wrote:
> 2009/6/24 Jamie Lokier <jamie@shareable.org>:
> > Marco wrote:
> >> > Second question: what happens if the system crashing _during_ a write
> >> > to a file.  Does it mean that file will fail it's checksum when it's
> >> > read at the next boot?
> >> >
> >> > Maybe files aren't so important.  What about when you write a file,
> >> > and then rename it over an existing file to replace it.  (E.g. a
> >> > config file), and the system crashes _during_ the rename?  At the next
> >> > boot, is it guaranteed to see either the old or the new file, or can
> >> > the directory be corrupt / fail it's checksum?
> >>
> >> First of all I have to explain better the current policy: the checksum
> >> works at inode and superblock level and currently there isn't a recovery
> >> function as the journaling. About the superblock it's easy to use a
> >> redundant policy to be more robust.
> >
> > To be honest, superblock robustness is less of a concern.  The real
> > concern is losing file or directory contents, so it can't be used to
> > store persistent configuration data, only debugging logs.
> >
> >> About the inode, at the moment when the checksum doesn't match the
> >> inode it's marked as bad calling the function make_bad_inode().
> >
> > Let's see if I understand right.
> >
> > If it lose power when writing to a file, after boot the file is likely
> > to be marked bad and so return -EIO instead of any file contents?
> 
> Depends on the checksum. If you lose power before the checksum update
> of the inode
> you'll have a bad inode and then an -EIO at the next access.
> 
> >

> > If it loses power when doing atomic rename (to replace config files,
> > for example), it's likely that the whole /pramfs/configs/ directory
> > will be corrupt, because the rename is writing to the directory inode,
> > so you lose access to all names in that directory?
> >
> > That sounds like it can't be used for persistent configuration data.
> 
> It's true from this point of view currently there is a lack for this
> and it needs a bit of effort to resolve this problem.  >From this
> point of view I'd like to point out that I know that there was some
> aspects to study in a deeper way, so I'll need of more then one
> review :) but since this fs has been abandoned since 2004 and it
> hadn't ever reviewed, it was important to do a serious review with
> the kernel community to understand all the problems.

That's reasonable.

What do you think of my suggestion to double-buffer writes using a
single fixed position block, as explained elsewhere in this thread?

It should give the power fail safety with very little code.  I don't
know how much it would slwo down writing.  That probably depends on
whether it's the checksum which is slow (which only needs to be done
once when double-buffering), or the writing.

-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html