Will the kernel ensure filesystems be in a clean state when restart/poweroff?
Clash Royale CLAN TAG#URR8PPP
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.
linux filesystems reboot
asked Feb 23 at 12:33
炸鱼薯条德里克炸鱼薯条德里克
5831316
add a comment |
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.
linux filesystems reboot
asked Feb 23 at 12:33
炸鱼薯条德里克炸鱼薯条德里克
5831316
add a comment |
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.
linux filesystems reboot
asked Feb 23 at 12:33
炸鱼薯条德里克炸鱼薯条德里克
5831316
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.
linux filesystems reboot
linux filesystems reboot
asked Feb 23 at 12:33
炸鱼薯条德里克炸鱼薯条德里克
5831316
asked Feb 23 at 12:33
炸鱼薯条德里克炸鱼薯条德里克
5831316
edited Feb 23 at 16:31
炸鱼薯条德里克
asked Feb 23 at 12:33
炸鱼薯条德里克炸鱼薯条德里克
5831316
asked Feb 23 at 12:33
炸鱼薯条德里克炸鱼薯条德里克
5831316
asked Feb 23 at 12:33
炸鱼薯条德里克炸鱼薯条德里克
5831316
5831316
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
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 :-).
answered Feb 23 at 13:00
sourcejedisourcejedi
25.2k444110
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 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 :-). unix.stackexchange.com/a/499705/29483
– sourcejedi
Feb 23 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. usenix.org/legacy/events/hotos03/tech/full_papers/candea/… E.g. do we want to call it inconsistent, when all the correct data has been saved in the journal?
– sourcejedi
Feb 23 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 async().
– JdeBP
Feb 23 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 at 16:51
|
show 1 more comment
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.
answered Feb 23 at 13:55
itsbruceitsbruce
1,104710
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f502513%2fwill-the-kernel-ensure-filesystems-be-in-a-clean-state-when-restart-poweroff%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 :-).
answered Feb 23 at 13:00
sourcejedisourcejedi
25.2k444110
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 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 :-). unix.stackexchange.com/a/499705/29483
– sourcejedi
Feb 23 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. usenix.org/legacy/events/hotos03/tech/full_papers/candea/… E.g. do we want to call it inconsistent, when all the correct data has been saved in the journal?
– sourcejedi
Feb 23 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 async().
– JdeBP
Feb 23 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 at 16:51
|
show 1 more comment
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 :-).
answered Feb 23 at 13:00
sourcejedisourcejedi
25.2k444110
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 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 :-). unix.stackexchange.com/a/499705/29483
– sourcejedi
Feb 23 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. usenix.org/legacy/events/hotos03/tech/full_papers/candea/… E.g. do we want to call it inconsistent, when all the correct data has been saved in the journal?
– sourcejedi
Feb 23 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 async().
– JdeBP
Feb 23 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 at 16:51
|
show 1 more comment
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 :-).
answered Feb 23 at 13:00
sourcejedisourcejedi
25.2k444110
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 :-).
answered Feb 23 at 13:00
sourcejedisourcejedi
25.2k444110
edited Feb 23 at 17:40
answered Feb 23 at 13:00
sourcejedisourcejedi
25.2k444110
answered Feb 23 at 13:00
sourcejedisourcejedi
25.2k444110
answered Feb 23 at 13:00
sourcejedisourcejedi
25.2k444110
25.2k444110
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 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 :-). unix.stackexchange.com/a/499705/29483
– sourcejedi
Feb 23 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. usenix.org/legacy/events/hotos03/tech/full_papers/candea/… E.g. do we want to call it inconsistent, when all the correct data has been saved in the journal?
– sourcejedi
Feb 23 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 async().
– JdeBP
Feb 23 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 at 16:51
|
show 1 more comment
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 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 :-). unix.stackexchange.com/a/499705/29483
– sourcejedi
Feb 23 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. usenix.org/legacy/events/hotos03/tech/full_papers/candea/… E.g. do we want to call it inconsistent, when all the correct data has been saved in the journal?
– sourcejedi
Feb 23 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 async().
– JdeBP
Feb 23 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 at 16:51
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 at 13:57
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 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 :-). unix.stackexchange.com/a/499705/29483
– sourcejedi
Feb 23 at 14:33
@炸鱼薯条德里克 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 :-). unix.stackexchange.com/a/499705/29483
– sourcejedi
Feb 23 at 14:33
1
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. usenix.org/legacy/events/hotos03/tech/full_papers/candea/… E.g. do we want to call it inconsistent, when all the correct data has been saved in the journal?
– sourcejedi
Feb 23 at 14:38
@炸鱼薯条德里克 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. usenix.org/legacy/events/hotos03/tech/full_papers/candea/… E.g. do we want to call it inconsistent, when all the correct data has been saved in the journal?
– sourcejedi
Feb 23 at 14:38
1
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 at 14:53
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 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 at 16:51
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 at 16:51
|
show 1 more comment
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.
answered Feb 23 at 13:55
itsbruceitsbruce
1,104710
add a comment |
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.
answered Feb 23 at 13:55
itsbruceitsbruce
1,104710
add a comment |
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.
answered Feb 23 at 13:55
itsbruceitsbruce
1,104710
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.
answered Feb 23 at 13:55
itsbruceitsbruce
1,104710
answered Feb 23 at 13:55
itsbruceitsbruce
1,104710
answered Feb 23 at 13:55
itsbruceitsbruce
1,104710
answered Feb 23 at 13:55
itsbruceitsbruce
1,104710
1,104710
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f502513%2fwill-the-kernel-ensure-filesystems-be-in-a-clean-state-when-restart-poweroff%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
