1

What does reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_POWER_OFF, NULL) syscall do with filesystems exactly?

I know some still cache-in-memory data will be lost, but if I never call umount()(or umount failed) before reboot(), is it possible that I end up with an broken filesystem which can't be mount() as rw again directly?

I know this is filesystem type dependent, so I would like to know more detail about journal filesystems and more simple filesystems like ext2.

炸鱼薯条德里克
  • 1,337
  • 1
  • 12
  • 31

2 Answers2

3

Unmounting a filesystem will sync all the associated cache-in-memory data. The reboot() call can lose data, exactly because it does not unmount the filesystems cleanly. (lennart is salty about this :-).

However I would only call the filesystem "broken" if it was not using journalling (or equivalent). Apart from that case, e.g. ext4/xfs/btrfs should be repaired 100% reliably using the journal. This can be (and is) performed automatically. Unlike a full check/repair, it does not involve scanning the entire filesystem, so it is pretty quick. Unless you had a lot of unsynced metadata changes that need to be sorted out.

You can see some example messages from ext4 here: Does "recovering journal" prove an unclean shutdown/unmount?

In the linked example, it appears that fsck.ext4 recovers the journal. However, I think the kernel can also recover the ext4 journal automatically when the filesystem is mounted. For xfs/btrfs, fsck never does anything (see the relevant man pages), so it is always handled by the kernel.

By contrast, ext2 did not have a journal. fsck.ext2 has a good reputation, but as I understand it, it does not cover every possible case that journalling can. It might end up losing filenames and dropping their content into the lost+found directory. Or the correct fix might not be 100% unambiguous, so it would need to ask the user permission before applying its best guess.

The above assumes your storage device fulfils the filesystem's expectations. For example there is a known case regarding power failures which interrupt write operations: some SD card style storage may lose the entire 128KB flash erase block, that contained the disk block (e.g. 4KB) you were writing to. The above filesystems are not designed to survive such data loss :-).

sourcejedi
  • 48,311
  • 17
  • 143
  • 296
  • By "broken", I mean, filesystem data structure consistency is corrupted, like partially written metadata kind of thing that will never exist on a cleanly unmounted filesystem. Do you mean that kind of thing might happen on reboot()? – 炸鱼薯条德里克 Feb 23 '19 at 13:57
  • @炸鱼薯条德里克 Yes, reboot() does not perform a clean unmount. You are supposed to do the unmount before calling reboot(). Or for the root filesystem, you should remount it read-only, unless the root filesystem is a tmpfs or something :-). https://unix.stackexchange.com/a/499705/29483 – sourcejedi Feb 23 '19 at 14:33
  • 1
    @炸鱼薯条德里克 I hesitate to define exactly what "data structure consistency is corrupted" means. In theory you might design some filesystem to follow the "crash-only" concept. https://www.usenix.org/legacy/events/hotos03/tech/full_papers/candea/candea_html/index.html E.g. do we want to call it inconsistent, when all the correct data has been saved in the journal? – sourcejedi Feb 23 '19 at 14:38
  • 1
    This is one of the differences that one has to be aware of in cross-platform systems programming. On the BSDs, `reboot()` in the normal case also implies a `sync()`. – JdeBP Feb 23 '19 at 14:53
  • I edited the question a little bit. I want to know without a clean umount (like direct reboot syscall or power fail), will my filesystem be unusable. For what I understand, journal filesystem wouldn't suffer from this (next time I mount, kernel would automatically repair it), even though some data will be lost. While I also heard that on old computers, lacking of a clean umount might destroy(can't be mounted as rw or even completely unreadable any more) the whole filesystem such as FAT32 or ext2. – 炸鱼薯条德里克 Feb 23 '19 at 16:51
  • @炸鱼薯条德里克 interesting. In my example messages it is `fsck.ext4` that recovered the journal. However, given that `man ext4` shows there is a mount option `norecovery`, I *think* the kernel is able to recover ext4 on its own. – sourcejedi Feb 23 '19 at 17:26
0

Pedantically, no. Restart and poweroff events are userspace concepts, not kernel concepts. Graceful power-off or restart is handled by systemd on most modern Linux distributions. It's also the userpace tooling which checks filesystems on start-up and mounts them if they are in a usable state.

Yes to the extent that the filesystem drivers implement journalling to keep the filesystems consistent even in the case of an ungraceful shutdown or restart.

Yes to the extend that the kernel provides the API by which the userspace tooling can check and manage the filesystems.

itsbruce
  • 1,744
  • 1
  • 10
  • 12