The exact scenario I have tried to address is when yaffs2 is used as a root
file system.
As a part of reboot sequence, it might be hard to unmount it completely, but
remount read-only should be easily achivable.
You might argue that this is not very good solution, but it is a real life
example. :-(
I think remount readonly-to-readonly should be addressed, but it looks
rather theoretical. You never know though, there might be a compeling
reason to do that.
If write protect condition is triggered in the middle, the checkpoint might
be partially saved, but it should be already taken care of by overall
chekpoint integrity verification mechanizm. Also some unsaved data might be
flushed to media, but personally I would expect something like this to
happen.
M.
On 3/20/07,
yaffs-request@lists.aleph1.co.uk <
yaffs-request@lists.aleph1.co.uk> wrote:
>
> Send yaffs mailing list submissions to
> yaffs@lists.aleph1.co.uk
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
> or, via email, send a message with subject or body 'help' to
> yaffs-request@lists.aleph1.co.uk
>
> You can reach the person managing the list at
> yaffs-owner@lists.aleph1.co.uk
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of yaffs digest..."
>
>
> Today's Topics:
>
> 1. Re: Saving checkpoint on remount read-only (ian@brightstareng.com)
> 2. Re: Saving checkpoint on remount read-only (Vitaly Wool)
> 3. problem mounting yaffs2 : No such device or address
> (Richard Genoud)
> 4. Re: problem mounting yaffs2 : No such device or address
> (Charles Manning)
> 5. Re: Saving checkpoint on remount read-only (Charles Manning)
> 6. Re: Saving checkpoint on remount read-only (ian@brightstareng.com)
> 7. Re: Saving checkpoint on remount read-only (Charles Manning)
> 8. Re: Saving checkpoint on remount read-only (Michael Arm)
> 9. Re: Saving checkpoint on remount read-only (Charles Manning)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 20 Mar 2007 09:50:30 -0400
> From: ian@brightstareng.com
> Subject: Re: [Yaffs] Saving checkpoint on remount read-only
> To: yaffs@lists.aleph1.co.uk
> Message-ID: <200703200950.31060.ian@brightstareng.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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?
>
> -imcd
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 20 Mar 2007 06:17:02 -0800
> From: "Vitaly Wool" <vitalywool@gmail.com>
> Subject: Re: [Yaffs] Saving checkpoint on remount read-only
> To: "ian@brightstareng.com" <ian@brightstareng.com>
> Cc: yaffs@lists.aleph1.co.uk
> Message-ID:
> <acd2a5930703200717u1673c769n413b398ad2d49307@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 3/20/07, ian@brightstareng.com <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?
>
> IMV, the only situation where it potentially can happen is when a
> filesystem was mounted read-only and is remounted with read-only flag
> as well.
> This (
> http://git.infradead.org/?p=users/vwool/mtd-2.6.git;a=commit;h=31ba38d77f48e5841281ccc5f7e9d92031a2d9e3
> )
> should fix it anyway.
>
> Vitaly
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 20 Mar 2007 17:31:29 +0100
> From: "Richard Genoud" <richard.genoud@gmail.com>
> Subject: [Yaffs] problem mounting yaffs2 : No such device or address
> To: yaffs@lists.aleph1.co.uk
> Message-ID:
> <80b317760703200931r641c6576pa95aa53f11d0f08d@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hi !
> I'm using the latest yaffs2 tree (from today 2007.03.20) on an atmel
> at91sam9261-ek board.
> my kernel is 2.6.20 with the at91 patch
> here is what I'm getting :
> mount -t yaffs2 /dev/mtdblock0 /mnt/mtd0/
> mount: Mounting /dev/mtdblock0 on /mnt/mtd0/ failed: No such device or
> address
>
> I tried with jffs2 and all is ok on that device.
> I tried also with a dummy block device :
> mount -t yaffs2 /dev/loop0 /mnt/mtd0/
> yaffs: dev is 7340032 name is "loop0"
> yaffs_read_super: Using yaffs2
> yaffs_read_super: block size 4096
> yaffs: Attempting MTD mount on 7.0, "loop0"
> mount: Mounting /dev/loop0 on /mnt/mtd0/ failed: Invalid argument
> it shows that yaffs is in the kernel...
>
> i don't know if this could be a clue, but in /proc/filesystems, I have :
> # cat /proc/filesystems
> nodev sysfs
> nodev rootfs
> nodev bdev
> nodev proc
> nodev sockfs
> nodev usbfs
> nodev pipefs
> nodev futexfs
> nodev tmpfs
> nodev eventpollfs
> nodev devpts
> nodev ramfs
> nodev nfs
> nodev jffs2
> yaffs
> yaffs2
> nodev rpc_pipefs
>
> there's no "nodev" before yaffs*...
> does it tell something to anyone ?
> regards.
> Richard Genoud
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 21 Mar 2007 09:03:02 +1200
> From: Charles Manning <manningc2@actrix.gen.nz>
> Subject: Re: [Yaffs] problem mounting yaffs2 : No such device or
> address
> To: yaffs@lists.aleph1.co.uk
> Message-ID: <200703210903.02516.manningc2@actrix.gen.nz>
> Content-Type: text/plain; charset="utf-8"
>
> On Wednesday 21 March 2007 04:31, Richard Genoud wrote:
> > Hi !
> > I'm using the latest yaffs2 tree (from today 2007.03.20) on an atmel
> > at91sam9261-ek board.
> > my kernel is 2.6.20 with the at91 patch
> > here is what I'm getting :
> > mount -t yaffs2 /dev/mtdblock0 /mnt/mtd0/
> > mount: Mounting /dev/mtdblock0 on /mnt/mtd0/ failed: No such device or
> > address
>
> You are not getting any yaffs:xxx messages so it looks like the call is
> being
> rejected by mount even before it gets to call any specific yaffs code.
>
> You can also try turning on more yaffs tracing to see if that helps.
>
> >
> > I tried with jffs2 and all is ok on that device.
> > I tried also with a dummy block device :
> > mount -t yaffs2 /dev/loop0 /mnt/mtd0/
> > yaffs: dev is 7340032 name is "loop0"
> > yaffs_read_super: Using yaffs2
> > yaffs_read_super: block size 4096
> > yaffs: Attempting MTD mount on 7.0, "loop0"
> > mount: Mounting /dev/loop0 on /mnt/mtd0/ failed: Invalid argument
>
> Not suprising. /dev/loop0 is a block device. YAFFS works with mtd devices.
>
> > it shows that yaffs is in the kernel...
> >
> > i don't know if this could be a clue, but in /proc/filesystems, I have :
> > # cat /proc/filesystems
> > nodev sysfs
> > nodev rootfs
> > nodev bdev
> > nodev proc
> > nodev sockfs
> > nodev usbfs
> > nodev pipefs
> > nodev futexfs
> > nodev tmpfs
> > nodev eventpollfs
> > nodev devpts
> > nodev ramfs
> > nodev nfs
> > nodev jffs2
> > yaffs
> > yaffs2
> > nodev rpc_pipefs
> >
> > there's no "nodev" before yaffs*...
> > does it tell something to anyone ?
>
> yaffs requires a device, so I would not expect to see nodev.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 21 Mar 2007 09:15:56 +1200
> From: Charles Manning <manningc2@actrix.gen.nz>
> Subject: Re: [Yaffs] Saving checkpoint on remount read-only
> To: yaffs@lists.aleph1.co.uk
> Cc: ian@brightstareng.com
> Message-ID: <200703210915.56361.manningc2@actrix.gen.nz>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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.
>
> -- CHarles
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 20 Mar 2007 16:55:12 -0400
> From: ian@brightstareng.com
> Subject: Re: [Yaffs] Saving checkpoint on remount read-only
> To: yaffs@lists.aleph1.co.uk
> Cc: Charles Manning <manningc2@actrix.gen.nz>
> Message-ID: <200703201655.12834.ian@brightstareng.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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?
>
> If the underlying media were write-protected, as with the button
> on a VAX RA81 drive, the 'clean-up' write/erase would fail.
>
> -imcd
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 21 Mar 2007 10:18:58 +1200
> From: Charles Manning <manningc2@actrix.gen.nz>
> Subject: Re: [Yaffs] Saving checkpoint on remount read-only
> To: yaffs@lists.aleph1.co.uk
> Cc: ian@brightstareng.com
> Message-ID: <200703211018.59047.manningc2@actrix.gen.nz>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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.
>
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 20 Mar 2007 14:28:56 -0700
> From: "Michael Arm" <micharmel@gmail.com>
> Subject: Re: [Yaffs] Saving checkpoint on remount read-only
> To: yaffs@lists.aleph1.co.uk
> Message-ID:
> <c7cd81130703201428o4bc80623ie35447f772c41196@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> >> 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.
>
>
> It seems like YAFFS would be a perfect candidate for implementing
> recoverable file versioning. Is that something you've ever considered
> doing?
>
>
>
> ------------------------------
>
> Message: 9
> Date: Wed, 21 Mar 2007 10:55:12 +1200
> From: Charles Manning <manningc2@actrix.gen.nz>
> Subject: Re: [Yaffs] Saving checkpoint on remount read-only
> To: yaffs@lists.aleph1.co.uk
> Cc: Michael Arm <micharmel@gmail.com>
> Message-ID: <200703211055.12238.manningc2@actrix.gen.nz>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Wednesday 21 March 2007 09:28, Michael Arm wrote:
> > >> 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.
> >
> > It seems like YAFFS would be a perfect candidate for implementing
> > recoverable file versioning. Is that something you've ever considered
> > doing?
>
> No it isn't perfect for doing this at all. An overwrite does just that, it
> overwrites and old data is lost.
>
> A roll-back fs is interesting from an academic perspective, but probably
> is
> not that practical because the OS calls don't support it and nor does
> POSIX.
> There's already too much stuff to do just keeping YAFFS doing POSIX.
>
> -- CHarles
>
>
>
>
> ------------------------------
>
> _______________________________________________
> yaffs mailing list
> yaffs@lists.aleph1.co.uk
> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
>
>
> End of yaffs Digest, Vol 22, Issue 16
> *************************************
>
(text/plain)