Question about file size 0 after filesystem recovery

[jaeho jo]

Despite using the fsync() , the file was restored to size 0.

Both fsync() and fsyncdata() are mapped to 'rtems_rtems_fdatasync'.

file path : cpukit/libfs/src/rfs/rtems-rfs-rtems-file.c
const rtems_filesystem_file_handlers_r rtems_rfs_rtems_file_handlers = {
  .open_h      = rtems_rfs_rtems_file_open,
  .close_h     = rtems_rfs_rtems_file_close,
  .read_h      = rtems_rfs_rtems_file_read,
  .write_h     = rtems_rfs_rtems_file_write,
  .ioctl_h     = rtems_filesystem_default_ioctl,
  .lseek_h     = rtems_rfs_rtems_file_lseek,
  .fstat_h     = rtems_rfs_rtems_fstat,
  .ftruncate_h = rtems_rfs_rtems_file_ftruncate,
  .fsync_h     = rtems_rfs_rtems_fdatasync,
  .fdatasync_h = rtems_rfs_rtems_fdatasync,
  .fcntl_h     = rtems_filesystem_default_fcntl,
  .kqfilter_h  = rtems_filesystem_default_kqfilter,
  .poll_h      = rtems_filesystem_default_poll,
  .readv_h     = rtems_filesystem_default_readv,
  .writev_h    = rtems_filesystem_default_writev
};

I think fsyncdata() is not updating the file's metadata.

Therefore, the file does not appear to be fully recovered. Is it possible
to update the metadata by modifying the code?

thanks!

On Tue, Jan 5, 2021 at 10:46 PM 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.
>
> --joel
>
>
>> thanks!
>> jhjo
>> _______________________________________________
>> 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/20210113/82955354/attachment.html>