Question about file size 0 after filesystem recovery

[Gedare Bloom]

On Tue, Jan 5, 2021 at 6:47 AM Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Tue, Jan 5, 2021 at 12:48 AM jaeho jo <hot486two at gmail.com> wrote:
>
>> Hello!
>>
>> I am testing filesystem recovery and I have a question.
>>
>> If the reset is not a power-on reset, my application attempts to restore
>> the filesystem.
>>
>> If the file was closed prior to reset, the file was restored.
>>
>> If a reset occurs while a file is open, the file was not recovered after
>> the reset. The file was created, but its size is 0. Is this the
>> intended behavior of RTEMS?
>>
>> I tested the OS version using RTEMS4.11.1 and 5.1, and the file system
>> using RFS and dosFS. The results were all the same. A file of size 0 has
>> been created.
>>
>
> If the file and underlying disk buffers are not flushed before reset, then
> nothing has been committed to the non-volatile storage.
>
> I would say this is expected and intended behavior if you do not have an
> orderly write of a file on shutdown/reset on any operating system.
>
> My quick look at the source code for both filesystems you mention indicate
> the sync calls like fsync() and fdatasync() are supported. Here is the
> POSIX page for fsync(). Notice the discussion at the bottom about automated
> testing and reset.
>
> https://pubs.opengroup.org/onlinepubs/009695399/functions/fsync.html
>
> I assume this also flushes the block device cache but I didn't look beyond
> the file system implementations.
>
>
In general, a filesystem needs journalling (or an equivalent
transaction-based mechanism) to support arbitrary recovery after reset.


> --joel
>
>
>> thanks!
>> jhjo
>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20210105/3945b1ae/attachment.html>