Hi,
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.
Regards,
Volker
Am 01.02.2018 um 10:36 schrieb Ketil Froyn:
> On 30 January 2018 at 21:15, Andre Renaud <andre@ignavus.net> wrote:
>> Hi Charles,
>>
>> On Wed, 31 Jan 2018 at 09:05 Charles Manning <cdhmanning@gmail.com> 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
> yaffs@stoneboat.aleph1.co.uk
> http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
(text/plain)