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
*************************************