Question about file size 0 after filesystem recovery

[Charles Manning]

What you get will depend very much on what file system you are using. Each
file system has different behaviours.

If you have an application where you can yank power without a clean
shutdown then it is advisable to use a file system with a more predictable
caching policy.

For example, Yaffs (the file system I wrote) guarantees that the write has
made it to media when the file is synced (fsync() and fdatasync() ) or
closed.

If the file system's fsync()and close() only guarantee that that data is
written into the block device's buffers then you have no guarantees.



On Wed, Jan 6, 2021 at 5:07 AM Gedare Bloom <gedare at rtems.org> wrote:

>
>
> 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
>
> _______________________________________________
> 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/20210106/8d2ed2f5/attachment.html>