How to determine freeze/unfreeze status of a filesystem?

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











up vote
1
down vote

favorite












I use xfs_freeze to freeze and unfreeze my xfs filesystem:



xfs_freeze -f /blahblah

xfs_freeze -u /blahblah


After I run the unfreeze command I want to make sure that the filesystem is not frozen for sure. This command does not return any value or message.



I know I can try remounting the filesystem but that one is not full-proof.



Also if I run the unfreeze command again on an unfrozen filesystem I will get something like this:



xfs_freeze: cannot unfreeze filesystem mounted at /blahblah: Invalid
argument


This method is not fool-proof either because the message is not accurate.



Is there a command I can use that would tell me the freeze status of the filesystem, or is there a fool-proof method that I can use to determine this?



Any hint?










share|improve this question



























    up vote
    1
    down vote

    favorite












    I use xfs_freeze to freeze and unfreeze my xfs filesystem:



    xfs_freeze -f /blahblah

    xfs_freeze -u /blahblah


    After I run the unfreeze command I want to make sure that the filesystem is not frozen for sure. This command does not return any value or message.



    I know I can try remounting the filesystem but that one is not full-proof.



    Also if I run the unfreeze command again on an unfrozen filesystem I will get something like this:



    xfs_freeze: cannot unfreeze filesystem mounted at /blahblah: Invalid
    argument


    This method is not fool-proof either because the message is not accurate.



    Is there a command I can use that would tell me the freeze status of the filesystem, or is there a fool-proof method that I can use to determine this?



    Any hint?










    share|improve this question

























      up vote
      1
      down vote

      favorite









      up vote
      1
      down vote

      favorite











      I use xfs_freeze to freeze and unfreeze my xfs filesystem:



      xfs_freeze -f /blahblah

      xfs_freeze -u /blahblah


      After I run the unfreeze command I want to make sure that the filesystem is not frozen for sure. This command does not return any value or message.



      I know I can try remounting the filesystem but that one is not full-proof.



      Also if I run the unfreeze command again on an unfrozen filesystem I will get something like this:



      xfs_freeze: cannot unfreeze filesystem mounted at /blahblah: Invalid
      argument


      This method is not fool-proof either because the message is not accurate.



      Is there a command I can use that would tell me the freeze status of the filesystem, or is there a fool-proof method that I can use to determine this?



      Any hint?










      share|improve this question















      I use xfs_freeze to freeze and unfreeze my xfs filesystem:



      xfs_freeze -f /blahblah

      xfs_freeze -u /blahblah


      After I run the unfreeze command I want to make sure that the filesystem is not frozen for sure. This command does not return any value or message.



      I know I can try remounting the filesystem but that one is not full-proof.



      Also if I run the unfreeze command again on an unfrozen filesystem I will get something like this:



      xfs_freeze: cannot unfreeze filesystem mounted at /blahblah: Invalid
      argument


      This method is not fool-proof either because the message is not accurate.



      Is there a command I can use that would tell me the freeze status of the filesystem, or is there a fool-proof method that I can use to determine this?



      Any hint?







      filesystems freeze xfs fsfreeze






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Dec 7 at 8:13









      Rui F Ribeiro

      38.6k1479128




      38.6k1479128










      asked Dec 7 at 0:25









      kaptan

      1847




      1847




















          2 Answers
          2






          active

          oldest

          votes

















          up vote
          1
          down vote













          TL;DR:



          While there is no direct way to query if a filesystem is frozen, you can abuse the fact that nested freezing attempts don't work. For example, I have an XFS filesystem mounted at /xfs_test:



          [root@testvm1 ~]# mount | grep xfs_test
          /dev/sdb1 on /xfs_test type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

          [root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Initial freeze
          [root@testvm1 ~]# echo $?
          0

          [root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Subsequent freeze attempt
          xfs_freeze: cannot freeze filesystem at /xfs_test/: Device or resource busy
          [root@testvm1 ~]# echo $?
          1


          The same analogy works for un-freezing or thawing the filesystem:



          [root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Same filesystem, currently frozen
          [root@testvm1 ~]# echo $?
          0

          [root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Thawed filesystem
          xfs_freeze: cannot unfreeze filesystem mounted at /xfs_test/: Invalid argument
          [root@testvm1 ~]# echo $?
          1



          I had to do some digging to find out if the frozen/thawed state query was possible. Although the technical details were a little beyond my understanding, this is what I have put together.



          Freezing and thawing a filesystem was a feature initially built for XFS. It was eventually brought forward to the Linux kernel, allowing the functionality to work for other filesystems as well. As this LWN article explains:




          Takashi Sato proposes taking an XFS-specific feature and moving it
          into the filesystem code. The patch would provide an ioctl() for
          suspending write access to a filesystem, freezing, along with a
          thawing option to resume writes.



          ...



          Essentially the patch just exports the freeze_bdev() kernel function
          in a user accessible way.freeze_bdev() locks a file system into a
          consistent state by flushing the superblock and syncing the device.
          The patch also adds tracking of the frozen state to the struct
          block_device state field.




          At this point, nested freezing and thawing were possible. As I understand it, a counter variable in the code kept track of the nested freezing and thawing attempts. The variable would increment when freezing, and decrement when thawing. Only when the counter was 0 would the filesystem actually thaw.



          After that, I found this patch discussion from 2016, which is about adding a new ioctl call to query the filesystem's state: fs: add the FIGETFROZEN ioctl call. As far as I can tell, this patch has not been merged into the kernel.



          The patch discussion provided a few key points:




          And, besides, polling for frozenness from userspace is inherently racy
          - by the time the syscall returns, the information may be incorrect, so you can't rely on it for decision making purposes in userspace.




          And then:




          I [sic] quick dig shows nesting was intentionally broken more than 5
          years ago in making the freeze ioctl work on btrfs.




          This led me to the, ahem, solution shown above.




          Yet another possibility is covered in this answer over at StackOverflow. If you try to remount a filesystem which is frozen, the attempt will fail with a 'device is busy' error. The mount could also be busy for a number of other reasons, so this solution is admittedly not fool-proof.






          share|improve this answer
















          • 1




            While the mount could be busy for a number of other reasons, the filesystem being frozen is about one of the only ones that most people are likely to encounter that will cause a mount -o remount to fail with -EBUSY.
            – Austin Hemmelgarn
            Dec 7 at 20:49











          • @Haxiel Thanks for digging this up : )
            – kaptan
            Dec 8 at 2:40










          • @kaptan Much appreciated. If my answer works for you, please do remember to upvote and/or accept it.
            – Haxiel
            Dec 13 at 6:04










          • @Haxiel I have already upvoted. Let me implement your solution and see how it goes.
            – kaptan
            2 days ago

















          up vote
          0
          down vote













          I think you will have to write your own command that will check.



          #!/bin/bash

          function touchFs()
          echo "mp: $1";
          touch "$1/frzn-5tst";
          if [ -f "$1/frzn-5tst" ]; then
          rm "$1/frzn-5tst" &> /dev/null;
          fi


          function usage()
          echo "$0 <mountpoint>";
          exit 1;


          if [ -z $1 ]; then
          usage;
          fi

          touchFs $1&
          ppid=$!;
          state=`ps -o s= -p $ppid`;

          if [ -z "$state" ]; then
          echo "device is unfrozen";
          elif [ "$state" == "S" ]; then
          echo "device is frozen";
          fi





          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',
            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%2f486484%2fhow-to-determine-freeze-unfreeze-status-of-a-filesystem%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








            up vote
            1
            down vote













            TL;DR:



            While there is no direct way to query if a filesystem is frozen, you can abuse the fact that nested freezing attempts don't work. For example, I have an XFS filesystem mounted at /xfs_test:



            [root@testvm1 ~]# mount | grep xfs_test
            /dev/sdb1 on /xfs_test type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

            [root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Initial freeze
            [root@testvm1 ~]# echo $?
            0

            [root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Subsequent freeze attempt
            xfs_freeze: cannot freeze filesystem at /xfs_test/: Device or resource busy
            [root@testvm1 ~]# echo $?
            1


            The same analogy works for un-freezing or thawing the filesystem:



            [root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Same filesystem, currently frozen
            [root@testvm1 ~]# echo $?
            0

            [root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Thawed filesystem
            xfs_freeze: cannot unfreeze filesystem mounted at /xfs_test/: Invalid argument
            [root@testvm1 ~]# echo $?
            1



            I had to do some digging to find out if the frozen/thawed state query was possible. Although the technical details were a little beyond my understanding, this is what I have put together.



            Freezing and thawing a filesystem was a feature initially built for XFS. It was eventually brought forward to the Linux kernel, allowing the functionality to work for other filesystems as well. As this LWN article explains:




            Takashi Sato proposes taking an XFS-specific feature and moving it
            into the filesystem code. The patch would provide an ioctl() for
            suspending write access to a filesystem, freezing, along with a
            thawing option to resume writes.



            ...



            Essentially the patch just exports the freeze_bdev() kernel function
            in a user accessible way.freeze_bdev() locks a file system into a
            consistent state by flushing the superblock and syncing the device.
            The patch also adds tracking of the frozen state to the struct
            block_device state field.




            At this point, nested freezing and thawing were possible. As I understand it, a counter variable in the code kept track of the nested freezing and thawing attempts. The variable would increment when freezing, and decrement when thawing. Only when the counter was 0 would the filesystem actually thaw.



            After that, I found this patch discussion from 2016, which is about adding a new ioctl call to query the filesystem's state: fs: add the FIGETFROZEN ioctl call. As far as I can tell, this patch has not been merged into the kernel.



            The patch discussion provided a few key points:




            And, besides, polling for frozenness from userspace is inherently racy
            - by the time the syscall returns, the information may be incorrect, so you can't rely on it for decision making purposes in userspace.




            And then:




            I [sic] quick dig shows nesting was intentionally broken more than 5
            years ago in making the freeze ioctl work on btrfs.




            This led me to the, ahem, solution shown above.




            Yet another possibility is covered in this answer over at StackOverflow. If you try to remount a filesystem which is frozen, the attempt will fail with a 'device is busy' error. The mount could also be busy for a number of other reasons, so this solution is admittedly not fool-proof.






            share|improve this answer
















            • 1




              While the mount could be busy for a number of other reasons, the filesystem being frozen is about one of the only ones that most people are likely to encounter that will cause a mount -o remount to fail with -EBUSY.
              – Austin Hemmelgarn
              Dec 7 at 20:49











            • @Haxiel Thanks for digging this up : )
              – kaptan
              Dec 8 at 2:40










            • @kaptan Much appreciated. If my answer works for you, please do remember to upvote and/or accept it.
              – Haxiel
              Dec 13 at 6:04










            • @Haxiel I have already upvoted. Let me implement your solution and see how it goes.
              – kaptan
              2 days ago














            up vote
            1
            down vote













            TL;DR:



            While there is no direct way to query if a filesystem is frozen, you can abuse the fact that nested freezing attempts don't work. For example, I have an XFS filesystem mounted at /xfs_test:



            [root@testvm1 ~]# mount | grep xfs_test
            /dev/sdb1 on /xfs_test type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

            [root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Initial freeze
            [root@testvm1 ~]# echo $?
            0

            [root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Subsequent freeze attempt
            xfs_freeze: cannot freeze filesystem at /xfs_test/: Device or resource busy
            [root@testvm1 ~]# echo $?
            1


            The same analogy works for un-freezing or thawing the filesystem:



            [root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Same filesystem, currently frozen
            [root@testvm1 ~]# echo $?
            0

            [root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Thawed filesystem
            xfs_freeze: cannot unfreeze filesystem mounted at /xfs_test/: Invalid argument
            [root@testvm1 ~]# echo $?
            1



            I had to do some digging to find out if the frozen/thawed state query was possible. Although the technical details were a little beyond my understanding, this is what I have put together.



            Freezing and thawing a filesystem was a feature initially built for XFS. It was eventually brought forward to the Linux kernel, allowing the functionality to work for other filesystems as well. As this LWN article explains:




            Takashi Sato proposes taking an XFS-specific feature and moving it
            into the filesystem code. The patch would provide an ioctl() for
            suspending write access to a filesystem, freezing, along with a
            thawing option to resume writes.



            ...



            Essentially the patch just exports the freeze_bdev() kernel function
            in a user accessible way.freeze_bdev() locks a file system into a
            consistent state by flushing the superblock and syncing the device.
            The patch also adds tracking of the frozen state to the struct
            block_device state field.




            At this point, nested freezing and thawing were possible. As I understand it, a counter variable in the code kept track of the nested freezing and thawing attempts. The variable would increment when freezing, and decrement when thawing. Only when the counter was 0 would the filesystem actually thaw.



            After that, I found this patch discussion from 2016, which is about adding a new ioctl call to query the filesystem's state: fs: add the FIGETFROZEN ioctl call. As far as I can tell, this patch has not been merged into the kernel.



            The patch discussion provided a few key points:




            And, besides, polling for frozenness from userspace is inherently racy
            - by the time the syscall returns, the information may be incorrect, so you can't rely on it for decision making purposes in userspace.




            And then:




            I [sic] quick dig shows nesting was intentionally broken more than 5
            years ago in making the freeze ioctl work on btrfs.




            This led me to the, ahem, solution shown above.




            Yet another possibility is covered in this answer over at StackOverflow. If you try to remount a filesystem which is frozen, the attempt will fail with a 'device is busy' error. The mount could also be busy for a number of other reasons, so this solution is admittedly not fool-proof.






            share|improve this answer
















            • 1




              While the mount could be busy for a number of other reasons, the filesystem being frozen is about one of the only ones that most people are likely to encounter that will cause a mount -o remount to fail with -EBUSY.
              – Austin Hemmelgarn
              Dec 7 at 20:49











            • @Haxiel Thanks for digging this up : )
              – kaptan
              Dec 8 at 2:40










            • @kaptan Much appreciated. If my answer works for you, please do remember to upvote and/or accept it.
              – Haxiel
              Dec 13 at 6:04










            • @Haxiel I have already upvoted. Let me implement your solution and see how it goes.
              – kaptan
              2 days ago












            up vote
            1
            down vote










            up vote
            1
            down vote









            TL;DR:



            While there is no direct way to query if a filesystem is frozen, you can abuse the fact that nested freezing attempts don't work. For example, I have an XFS filesystem mounted at /xfs_test:



            [root@testvm1 ~]# mount | grep xfs_test
            /dev/sdb1 on /xfs_test type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

            [root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Initial freeze
            [root@testvm1 ~]# echo $?
            0

            [root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Subsequent freeze attempt
            xfs_freeze: cannot freeze filesystem at /xfs_test/: Device or resource busy
            [root@testvm1 ~]# echo $?
            1


            The same analogy works for un-freezing or thawing the filesystem:



            [root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Same filesystem, currently frozen
            [root@testvm1 ~]# echo $?
            0

            [root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Thawed filesystem
            xfs_freeze: cannot unfreeze filesystem mounted at /xfs_test/: Invalid argument
            [root@testvm1 ~]# echo $?
            1



            I had to do some digging to find out if the frozen/thawed state query was possible. Although the technical details were a little beyond my understanding, this is what I have put together.



            Freezing and thawing a filesystem was a feature initially built for XFS. It was eventually brought forward to the Linux kernel, allowing the functionality to work for other filesystems as well. As this LWN article explains:




            Takashi Sato proposes taking an XFS-specific feature and moving it
            into the filesystem code. The patch would provide an ioctl() for
            suspending write access to a filesystem, freezing, along with a
            thawing option to resume writes.



            ...



            Essentially the patch just exports the freeze_bdev() kernel function
            in a user accessible way.freeze_bdev() locks a file system into a
            consistent state by flushing the superblock and syncing the device.
            The patch also adds tracking of the frozen state to the struct
            block_device state field.




            At this point, nested freezing and thawing were possible. As I understand it, a counter variable in the code kept track of the nested freezing and thawing attempts. The variable would increment when freezing, and decrement when thawing. Only when the counter was 0 would the filesystem actually thaw.



            After that, I found this patch discussion from 2016, which is about adding a new ioctl call to query the filesystem's state: fs: add the FIGETFROZEN ioctl call. As far as I can tell, this patch has not been merged into the kernel.



            The patch discussion provided a few key points:




            And, besides, polling for frozenness from userspace is inherently racy
            - by the time the syscall returns, the information may be incorrect, so you can't rely on it for decision making purposes in userspace.




            And then:




            I [sic] quick dig shows nesting was intentionally broken more than 5
            years ago in making the freeze ioctl work on btrfs.




            This led me to the, ahem, solution shown above.




            Yet another possibility is covered in this answer over at StackOverflow. If you try to remount a filesystem which is frozen, the attempt will fail with a 'device is busy' error. The mount could also be busy for a number of other reasons, so this solution is admittedly not fool-proof.






            share|improve this answer












            TL;DR:



            While there is no direct way to query if a filesystem is frozen, you can abuse the fact that nested freezing attempts don't work. For example, I have an XFS filesystem mounted at /xfs_test:



            [root@testvm1 ~]# mount | grep xfs_test
            /dev/sdb1 on /xfs_test type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

            [root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Initial freeze
            [root@testvm1 ~]# echo $?
            0

            [root@testvm1 ~]# xfs_freeze -f /xfs_test/ # Subsequent freeze attempt
            xfs_freeze: cannot freeze filesystem at /xfs_test/: Device or resource busy
            [root@testvm1 ~]# echo $?
            1


            The same analogy works for un-freezing or thawing the filesystem:



            [root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Same filesystem, currently frozen
            [root@testvm1 ~]# echo $?
            0

            [root@testvm1 ~]# xfs_freeze -u /xfs_test/ # Thawed filesystem
            xfs_freeze: cannot unfreeze filesystem mounted at /xfs_test/: Invalid argument
            [root@testvm1 ~]# echo $?
            1



            I had to do some digging to find out if the frozen/thawed state query was possible. Although the technical details were a little beyond my understanding, this is what I have put together.



            Freezing and thawing a filesystem was a feature initially built for XFS. It was eventually brought forward to the Linux kernel, allowing the functionality to work for other filesystems as well. As this LWN article explains:




            Takashi Sato proposes taking an XFS-specific feature and moving it
            into the filesystem code. The patch would provide an ioctl() for
            suspending write access to a filesystem, freezing, along with a
            thawing option to resume writes.



            ...



            Essentially the patch just exports the freeze_bdev() kernel function
            in a user accessible way.freeze_bdev() locks a file system into a
            consistent state by flushing the superblock and syncing the device.
            The patch also adds tracking of the frozen state to the struct
            block_device state field.




            At this point, nested freezing and thawing were possible. As I understand it, a counter variable in the code kept track of the nested freezing and thawing attempts. The variable would increment when freezing, and decrement when thawing. Only when the counter was 0 would the filesystem actually thaw.



            After that, I found this patch discussion from 2016, which is about adding a new ioctl call to query the filesystem's state: fs: add the FIGETFROZEN ioctl call. As far as I can tell, this patch has not been merged into the kernel.



            The patch discussion provided a few key points:




            And, besides, polling for frozenness from userspace is inherently racy
            - by the time the syscall returns, the information may be incorrect, so you can't rely on it for decision making purposes in userspace.




            And then:




            I [sic] quick dig shows nesting was intentionally broken more than 5
            years ago in making the freeze ioctl work on btrfs.




            This led me to the, ahem, solution shown above.




            Yet another possibility is covered in this answer over at StackOverflow. If you try to remount a filesystem which is frozen, the attempt will fail with a 'device is busy' error. The mount could also be busy for a number of other reasons, so this solution is admittedly not fool-proof.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Dec 7 at 17:40









            Haxiel

            936310




            936310







            • 1




              While the mount could be busy for a number of other reasons, the filesystem being frozen is about one of the only ones that most people are likely to encounter that will cause a mount -o remount to fail with -EBUSY.
              – Austin Hemmelgarn
              Dec 7 at 20:49











            • @Haxiel Thanks for digging this up : )
              – kaptan
              Dec 8 at 2:40










            • @kaptan Much appreciated. If my answer works for you, please do remember to upvote and/or accept it.
              – Haxiel
              Dec 13 at 6:04










            • @Haxiel I have already upvoted. Let me implement your solution and see how it goes.
              – kaptan
              2 days ago












            • 1




              While the mount could be busy for a number of other reasons, the filesystem being frozen is about one of the only ones that most people are likely to encounter that will cause a mount -o remount to fail with -EBUSY.
              – Austin Hemmelgarn
              Dec 7 at 20:49











            • @Haxiel Thanks for digging this up : )
              – kaptan
              Dec 8 at 2:40










            • @kaptan Much appreciated. If my answer works for you, please do remember to upvote and/or accept it.
              – Haxiel
              Dec 13 at 6:04










            • @Haxiel I have already upvoted. Let me implement your solution and see how it goes.
              – kaptan
              2 days ago







            1




            1




            While the mount could be busy for a number of other reasons, the filesystem being frozen is about one of the only ones that most people are likely to encounter that will cause a mount -o remount to fail with -EBUSY.
            – Austin Hemmelgarn
            Dec 7 at 20:49





            While the mount could be busy for a number of other reasons, the filesystem being frozen is about one of the only ones that most people are likely to encounter that will cause a mount -o remount to fail with -EBUSY.
            – Austin Hemmelgarn
            Dec 7 at 20:49













            @Haxiel Thanks for digging this up : )
            – kaptan
            Dec 8 at 2:40




            @Haxiel Thanks for digging this up : )
            – kaptan
            Dec 8 at 2:40












            @kaptan Much appreciated. If my answer works for you, please do remember to upvote and/or accept it.
            – Haxiel
            Dec 13 at 6:04




            @kaptan Much appreciated. If my answer works for you, please do remember to upvote and/or accept it.
            – Haxiel
            Dec 13 at 6:04












            @Haxiel I have already upvoted. Let me implement your solution and see how it goes.
            – kaptan
            2 days ago




            @Haxiel I have already upvoted. Let me implement your solution and see how it goes.
            – kaptan
            2 days ago












            up vote
            0
            down vote













            I think you will have to write your own command that will check.



            #!/bin/bash

            function touchFs()
            echo "mp: $1";
            touch "$1/frzn-5tst";
            if [ -f "$1/frzn-5tst" ]; then
            rm "$1/frzn-5tst" &> /dev/null;
            fi


            function usage()
            echo "$0 <mountpoint>";
            exit 1;


            if [ -z $1 ]; then
            usage;
            fi

            touchFs $1&
            ppid=$!;
            state=`ps -o s= -p $ppid`;

            if [ -z "$state" ]; then
            echo "device is unfrozen";
            elif [ "$state" == "S" ]; then
            echo "device is frozen";
            fi





            share|improve this answer


























              up vote
              0
              down vote













              I think you will have to write your own command that will check.



              #!/bin/bash

              function touchFs()
              echo "mp: $1";
              touch "$1/frzn-5tst";
              if [ -f "$1/frzn-5tst" ]; then
              rm "$1/frzn-5tst" &> /dev/null;
              fi


              function usage()
              echo "$0 <mountpoint>";
              exit 1;


              if [ -z $1 ]; then
              usage;
              fi

              touchFs $1&
              ppid=$!;
              state=`ps -o s= -p $ppid`;

              if [ -z "$state" ]; then
              echo "device is unfrozen";
              elif [ "$state" == "S" ]; then
              echo "device is frozen";
              fi





              share|improve this answer
























                up vote
                0
                down vote










                up vote
                0
                down vote









                I think you will have to write your own command that will check.



                #!/bin/bash

                function touchFs()
                echo "mp: $1";
                touch "$1/frzn-5tst";
                if [ -f "$1/frzn-5tst" ]; then
                rm "$1/frzn-5tst" &> /dev/null;
                fi


                function usage()
                echo "$0 <mountpoint>";
                exit 1;


                if [ -z $1 ]; then
                usage;
                fi

                touchFs $1&
                ppid=$!;
                state=`ps -o s= -p $ppid`;

                if [ -z "$state" ]; then
                echo "device is unfrozen";
                elif [ "$state" == "S" ]; then
                echo "device is frozen";
                fi





                share|improve this answer














                I think you will have to write your own command that will check.



                #!/bin/bash

                function touchFs()
                echo "mp: $1";
                touch "$1/frzn-5tst";
                if [ -f "$1/frzn-5tst" ]; then
                rm "$1/frzn-5tst" &> /dev/null;
                fi


                function usage()
                echo "$0 <mountpoint>";
                exit 1;


                if [ -z $1 ]; then
                usage;
                fi

                touchFs $1&
                ppid=$!;
                state=`ps -o s= -p $ppid`;

                if [ -z "$state" ]; then
                echo "device is unfrozen";
                elif [ "$state" == "S" ]; then
                echo "device is frozen";
                fi






                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Dec 7 at 5:36

























                answered Dec 7 at 4:23









                NiteRain

                1104




                1104



























                    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.





                    Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                    Please pay close attention to the following guidance:


                    • 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%2f486484%2fhow-to-determine-freeze-unfreeze-status-of-a-filesystem%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?