# fsck.f2fs on F2FS root file system ?

## lost-distance

I have encountered a problem with fsck.f2fs - it will not check a read-only F2FS root file system.

It works fine on other unmounted F2FS file systems. But if I try to check a read-only F2FS root file system it gives the following error:

```
Error: In use by the system!
```

Applying the followiing hack to the f2fs-tools package will fix the problem:

```
--- ./lib/libf2fs.c   2015-03-07 14:55:06.359869742 +0000

+++ ./lib/libf2fs.c   2015-10-28 11:00:42.640291180 +0000

@@ -402,20 +402,6 @@

       return -1;

    }

 

-   /*

-    * If f2fs is umounted with -l, the process can still use

-    * the file system. In this case, we should not format.

-    */

-   if (stat(c->device_name, &st_buf) == 0 && S_ISBLK(st_buf.st_mode)) {

-      int fd = open(c->device_name, O_RDONLY | O_EXCL);

-

-      if (fd >= 0) {

-         close(fd);

-      } else if (errno == EBUSY) {

-         MSG(0, "\tError: In use by the system!\n");

-         return -1;

-      }

-   }

    return 0;

 }

 

```

So I am left wondering how others check a F2FS rootfs.

----------

## frostschutz

If possible you should do fsck from a rescue/recovery system. Having a filesystem fsck itself (using fsck binary stored on the filesystem itself) is a bit of a hen-and-egg problem, you're not supposed to mount corrupt filesystems in the first place... so how could you expect it to check itself? The filesystem has to be intact first so you can mount it and get at the fsck binaries...

Another problem is that read-only mounted filesystems usually expect the device itself to be read-only.

If you mount something read-only, and then write to the underlying block device (as fsck would if it fixes anything), the mounted file system will give you corrupted results, because the (still mounted) read-only filesystem expects the device to not change what-so-ever. The root fs running fsck on itself just isn't a good idea, if you do that and anything had to be repaired, you should reboot...

This sometimes happens with card readers, when you accidentally replace the card w/o umounting the filesystem first, and then the still mounted read-only filesystem from the old card tries to read "metadata" from the new card [which has completely different contents] and you get funny random filenames.

If you're asking about fsck as a regular maintenance thing during boot, you could put the fsck into initramfs.

PS: I prefer to run fsck manually; fsck is short for 'file system crunch killer', it changes things in the filesystem and there is no way to undo those changes. If it made the wrong changes, it multiplied the damage instead of decreasing it. If you have a corrupt filesystem in a data recovery situation, making changes (writing anything) is forbidden, so you should use snapshot / overlay / raw copy to run experiments and see what works best and undo things that don't work.

----------

## lost-distance

Thank you for your comments.

I was surprised that fsck.f2fs itself refused to check the rootfs. This contrasts with fsck.jfs, which will happily check a read-only rootfs (for example in single-user mode).

I am developing an embedded system with its rootfs on eMMC, so booting from external rescue/recovery media is not really an option.

Your comment about running fsck from an initramfs does seem to be the way to go, at least for development systems. Production systems will have a permanently read-only rootfs, so corruption should never arise.

----------

