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.

> I think though that the major benefit of the remount patch is
> that it will save state on a remount, which provides a sane
> time to do this.

Agreed.

>> If the underlying media were write-protected, as with the button
>> on a VAX RA81 drive, the 'clean-up' write/erase would fail.
>
> 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.

-imcd