On Wednesday 21 March 2007 08:55,
ian@brightstareng.com wrote:
> On Tuesday 20 March 2007 17:15, Charles Manning wrote:
> > On Wednesday 21 March 2007 01:50, ian@brightstareng.com wrote:
> > > On Tuesday 20 March 2007 06:31, Vitaly Wool wrote:
> > > > > The attached patch implements saving of yaffs checkpoint
> > > > > in case fs is remounted read-only. This allows the usage
> > > > > of checkpoint mechanizm even if, for some reason, the
> > > > > system can not cleanly unmount yaffs filesystem but can
> > > > > remount it read-only.
> > >
> > > Does this change mean that when a user mounts Yaffs fs
> > > read-only that write operations may take place to the NAND
> > > media?
> >
> > I'd have to go through the code but I believe that this is the
> > case in certain conditions.
> >
> > If there is no checkpoint and yaffs scans, then as stuff is
> > being scanned the obsolete stuff can be deleted. It is perhaps
> > hard to understand why this might happen, but here is a
> > scenario:
> >
> > If you have a file open and unlink it, that file still exists
> > and can be used. It only gets deleted when the handle to the
> > file is released. If the system was reset (unclean power
> > down), then the scan would pick this up and could do the
> > deletion.
>
> 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.
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 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.
>
> 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. Progress isn't always forward.
(text/plain)