On Mon, May 29, 2017 at 12:00 PM, Richard Weinberger <richard@xxxxxx> wrote: > Amir, Hyunchul, > > Am 29.05.2017 um 07:40 schrieb Amir Goldstein: >> On Mon, May 29, 2017 at 7:40 AM, Hyunchul Lee <hyc.lee@xxxxxxxxx> wrote: >>> >>> and I missed the following case. >>> >>> in some embedded systems, clean-up for shutdown should be fast. >>> during this clean-up, freeze file system to guarantee integrity. >>> umount with MNT_DETACH is not suitable because of not killing tasks. > > more details please, UBIFS is designed to survive a power-cut/reboot/etc. > at any time. How would it corrupt? > >> Interesting point. It seems that good old "sync; reboot" does not cut >> it anymore. >> Not even emergency remount read-only sysrq trigger. >> >> Some of you may have been following this thread on fsdevel: >> https://www.spinics.net/lists/linux-xfs/msg06953.html >> >> Probably less have been following this longer thread on xfs list: >> https://www.spinics.net/lists/linux-xfs/msg06883.html > > Well, UBIFS is a bit different. > The UBIFS journal is not an add-on feature, you have to replay it in > any case. Otherwise you're facing corrupted data. Yes, I suppose you are right. I guess there is no equivalent of mount -oro,{norecovery,noload} for ubifs. I don't know the ubifs journal implementation details. Can ubifs_run_commit() when writers are frozen contribute to shorter journal replay time after boot with some workloads? Amir.
