On Tue, Jan 5, 2021 at 6:47 AM Joel Sherrill <j...@rtems.org> wrote: > > > On Tue, Jan 5, 2021 at 12:48 AM jaeho jo <hot486...@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@rtems.org >> http://lists.rtems.org/mailman/listinfo/users > > _______________________________________________ > users mailing list > users@rtems.org > http://lists.rtems.org/mailman/listinfo/users
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
