Will the kernel ensure filesystems be in a clean state when restart/poweroff?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












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.










share|improve this question




























    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.










    share|improve this question


























      1












      1








      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.










      share|improve this question
















      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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Feb 23 at 16:31







      炸鱼薯条德里克

















      asked Feb 23 at 12:33









      炸鱼薯条德里克炸鱼薯条德里克

      5831316




      5831316




















          2 Answers
          2






          active

          oldest

          votes


















          2














          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 :-).






          share|improve this answer

























          • 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 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


















          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.






          share|improve this answer






















            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
            );



            );













            draft saved

            draft discarded


















            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









            2














            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 :-).






            share|improve this answer

























            • 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 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















            2














            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 :-).






            share|improve this answer

























            • 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 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













            2












            2








            2







            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 :-).






            share|improve this answer















            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 :-).







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Feb 23 at 17:40

























            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 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

















            • 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 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
















            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













            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.






            share|improve this answer



























              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.






              share|improve this answer

























                0












                0








                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.






                share|improve this answer













                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.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Feb 23 at 13:55









                itsbruceitsbruce

                1,104710




                1,104710



























                    draft saved

                    draft discarded
















































                    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.




                    draft saved


                    draft discarded














                    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





















































                    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






                    Popular posts from this blog

                    How to check contact read email or not when send email to Individual?

                    Displaying single band from multi-band raster using QGIS

                    How many registers does an x86_64 CPU actually have?