Re: [Yaffs] Read-Only mounted YAFFS2 - refreshing of NAND pa…

Top Page
Message as email
+ (text/plain)
Delete this message
Reply to this message
To: yaffs
Subject: Re: [Yaffs] Read-Only mounted YAFFS2 - refreshing of NAND pages

Well from my point of view, it would be great if a read-only mounted
filesystem would allow refreshing. And if a scrubbing would be part of
YAFFS2, ensuring that the refresh will take place.

Scanning for bad blocks isn't needed - at least with the chips that I am
using - because if you find one, then it's already too late and a
refresh hasn't been done in time. So a block should only be marked bad
when either erase or write went wrong.

However, although it would be great to have those features, my current
project can easily switch to a writable mount and a scrubbing daemon. -
No big deal for me.



Am 01.02.2018 um 10:36 schrieb Ketil Froyn:
> On 30 January 2018 at 21:15, Andre Renaud <> wrote:
>> Hi Charles,
>> On Wed, 31 Jan 2018 at 09:05 Charles Manning <> wrote:
>>> There is already something a bit like that for r/w partitions since Yaffs
>>> will, occasionally, rewrite the oldest block and thus force it to refresh.
>>> It sounds like what is needed here are:
>>> 1) A bit more active searching for bad pages.
>>> 2) Mount flags to allow fix-up for read-only.
>> I thought I'd just chime in with my 2 cents.
>> We had a system in the past with similar requirements to this. The trouble
>> is that there are two different ideas for read-only.
>> 1. Read-only in the sense that at no point does anything write to the NAND
>> device. This isn't really a good idea, due to read disturb etc..
>> 2. Read-only in the sense that when userspace goes to open a file for
>> writing, it always response with -EROFS. Whether the underlying NAND gets
>> touched is not really a concern for userspace, as long as the system is
>> reliable.
> Two more cents...
> I'd say this distinction is comparable to setting read-only at
> different layers with file systems on ordinary block devices:
> 1. The block device is read-only, for example an SD-card with
> write-block switch set, or a loopback device set up with "losetup -r".
> In this case, nothing can be changed on the block device layer.
> 2. A file system is mounted read-only, but the underlying block device
> is accessible for read-write. For example, even if you mount an ext4
> filesystem read-only, a dirty journal will be written out to the
> device. In cases like this, what actually happens on the block device
> is outside of the scope of "mount -o ro", it just disallows any change
> to the contents of the file system.
> Regards, Ketil
> _______________________________________________
> yaffs mailing list