RE: [Yaffs] Saving checkpoint on remount read-only

> -----Original Message-----
> From: yaffs-bounces@lists.aleph1.co.uk
> [mailto:yaffs-bounces@lists.aleph1.co.uk] On Behalf Of
> ian@brightstareng.com
> Sent: Thursday, 22 March 2007 1:50 a.m.
> To: yaffs@lists.aleph1.co.uk
> Cc: Charles Manning
> Subject: Re: [Yaffs] Saving checkpoint on remount read-only
>
> On Tuesday 20 March 2007 18:13, Vitaly Wool wrote:
> > On 3/20/07, ian@brightstareng.com <ian@brightstareng.com> wrote:
> > > I can follow this logic -- but I'm still left with an
> uneasy feeling
> > > that the media state might be changed when I mount a filesystem
> > > read-only. I would not expected it to write/erase anything --
> > > shouldn't the 'clean-up' be elided when mounting RO?
> >
> > Can you please elaborate on how it relates to the case being
> > discussed? If you look at the current code, you'll see that
> once the
> > read-only flag is set for the current mount, the added
> function just
> > does nothing.
>
> Your change to add the 'remount' call is good, thanks.
>
> I wanted to discuss the behaviour of write/erase operations
> on a filesystem mounted 'read-only'. Charles has raised some
> interesting points. I think it is good for us all to
> understand the semantics of read-only, especially versus
> write-protected.
>
> It appears from the discussion so far, that Yaffs needs
> write/erase access to the underlying block device even for
> read-only mounts.
> This is not sitting comfortably with me, not yet anyway.
>
> On Tuesday 20 March 2007 18:18, Charles Manning wrote:
> > On Wednesday 21 March 2007 08:55, ian@brightstareng.com wrote:
> > > I can follow this logic -- but I'm still left with an
> uneasy feeling
> > > that the media state might be changed when I mount a filesystem
> > > read-only. I would not expected it to write/erase anything --
> > > shouldn't the 'clean-up' be elided when mounting RO?
> >
> > I share that uneasy feeling.
> >
> > What RO should mean is not exactly clear.
> > From a pure logical perspective, it probably means that the media
> > should not be modified in any way.
>
> This is what's not making me feel good.
>
> > From a more practical perspective, I think it can also be
> interpreted
> > to mean that the OS may not change fs state.
> > However the media **might** still be changed.
> >
> > As an example, consider a disk-based system. If blocks go
> bad during
> > reads, the bad block handling will likely be triggered anyway to
> > attempt to correct the problem. The same could happen under
> yaffs too
> > ( except that yaffs will wait until a write to do the
> actual bad block
> > handling) and fixing bad blocks during RO is something that
> yaffs will
> > likely need to do with the less reliable MLC NAND.
>
> I see, I how have to reassess where Yaffs sits
> architecturally, it's part OS (fs) and part disk-controller.
> A read-only mount can keep the Yaffs filesystem quiescent,
> but not the Yaffs disk-controller.

Quite. Most fs just rely on the underlying block driver (also part of
the OS) and underlying disk controller(part of the hw) and shut their
eyes to any impure behaviour.

It is this mixing of fs + media control that makes a flash file system
different from a regular fs.

Another area where this sort of thing occurs is in caching. YAFFS caches
some writes (sort op cache) which is "poor form" for a fs. Convention is
that a fs should be immediately writing through to the block driver, so
yaffs is "wrong". However in most OS situations (eg. Linux) the block
driver does write-path caching for performance reasons so practically
there is little difference.

But, back to the main thread. It would be possible to make yaffs
strictly RO. As we move more and more towards 2 bits per cell and 4 bits
per cell we can expect the flash reliability to decrease. What should we
do if an ECC error is detected on read? (A) Wait until a write to fix
it, or (B) fix it ASAP. In a strict RO situation we will have no
opportunity to fix the problem and slowly watch as the storage degrades
until it becomes unrecoverable.

<snip>
> > Good one! Those were real computers! I really liked the VAX file
> > system model with recoverable file versioning.
>
> But that feature depended on whether you ran VMS, Ultrix or
> BSD on your VAX -- guess which two I ran; well yes I did use
> the other one too.

Running anything other than VMS on VAX is a bit like wearing open-toed
sandals with socks. It denies you the full experience!

-- Charles