How to capture all disks that don’t have a file system

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











up vote
5
down vote

favorite












I want to capture all disks that do not have a filesystem ( all disks that mkfs not runs on them )



I tried the below, but still gives the OS ( sda ).



What is the best approach with lsblk or other command to capture all disks that are without filesystem?



 lsblk -f | egrep -v "xfs|ext3|ext4"
NAME FSTYPE LABEL UUID
MOUNTPOINT
fd0
sda
└─sda2 LVM2_member v0593a-KiKU-9emb-STbx-ByMz-S95k-jChr0m
├─vg00-lv_swap swap 1beb675f-0b4c-4225-8455-e876cafc5756
[SWAP]
sdg
sdh
sdi
sdj
sdk
sr0






share|improve this question


























    up vote
    5
    down vote

    favorite












    I want to capture all disks that do not have a filesystem ( all disks that mkfs not runs on them )



    I tried the below, but still gives the OS ( sda ).



    What is the best approach with lsblk or other command to capture all disks that are without filesystem?



     lsblk -f | egrep -v "xfs|ext3|ext4"
    NAME FSTYPE LABEL UUID
    MOUNTPOINT
    fd0
    sda
    └─sda2 LVM2_member v0593a-KiKU-9emb-STbx-ByMz-S95k-jChr0m
    ├─vg00-lv_swap swap 1beb675f-0b4c-4225-8455-e876cafc5756
    [SWAP]
    sdg
    sdh
    sdi
    sdj
    sdk
    sr0






    share|improve this question
























      up vote
      5
      down vote

      favorite









      up vote
      5
      down vote

      favorite











      I want to capture all disks that do not have a filesystem ( all disks that mkfs not runs on them )



      I tried the below, but still gives the OS ( sda ).



      What is the best approach with lsblk or other command to capture all disks that are without filesystem?



       lsblk -f | egrep -v "xfs|ext3|ext4"
      NAME FSTYPE LABEL UUID
      MOUNTPOINT
      fd0
      sda
      └─sda2 LVM2_member v0593a-KiKU-9emb-STbx-ByMz-S95k-jChr0m
      ├─vg00-lv_swap swap 1beb675f-0b4c-4225-8455-e876cafc5756
      [SWAP]
      sdg
      sdh
      sdi
      sdj
      sdk
      sr0






      share|improve this question














      I want to capture all disks that do not have a filesystem ( all disks that mkfs not runs on them )



      I tried the below, but still gives the OS ( sda ).



      What is the best approach with lsblk or other command to capture all disks that are without filesystem?



       lsblk -f | egrep -v "xfs|ext3|ext4"
      NAME FSTYPE LABEL UUID
      MOUNTPOINT
      fd0
      sda
      └─sda2 LVM2_member v0593a-KiKU-9emb-STbx-ByMz-S95k-jChr0m
      ├─vg00-lv_swap swap 1beb675f-0b4c-4225-8455-e876cafc5756
      [SWAP]
      sdg
      sdh
      sdi
      sdj
      sdk
      sr0








      share|improve this question













      share|improve this question




      share|improve this question








      edited Dec 22 '17 at 12:41









      Jeff Schaller

      31.8k848109




      31.8k848109










      asked Dec 22 '17 at 11:23









      yael

      2,0091145




      2,0091145




















          4 Answers
          4






          active

          oldest

          votes

















          up vote
          3
          down vote



          accepted










          lsblk -o NAME,FSTYPE -dsn


          This will print a list of block devices that are not themselves holders for partitions (they do not have a partition table). The detected file system type is in the second column. If its blank there is no recognized file system.



          So to get the output you want in one command



          lsblk -o NAME,FSTYPE -dsn | awk '$2 == "" print $1'





          share|improve this answer






















          • This is good unless you've got ZFS pools with ZVOLs on them. e.g. on one of my systems, some of the block devices your lsblk ... | awk ... command lists are zd128p[123]. They're actually partitions 1-3 of /dev/zd128 (which happens to be /dev/zvol/volumes/freebsd, my freebsd VM's disk image). There are other ZVOL devices which it lists, too (including a few centos, debian, and ubuntu VMs). BTW file -s /dev/zd128p3 reports /dev/zd128p3: Unix Fast File system [v2] (little-endian) last mounted on [.....]. I'm not sure if this would happen with LVM volumes too - it's been a while.
            – cas
            Dec 23 '17 at 7:35










          • @cas the above command only recognizes containers in the case of block devices that are part of a partition table. As far as I know that concept doesn't extend to a fs volume. Also it would skip block devices without a partition table that are in containers. Maybe I shouldn't assume the op doesn't want that? but such devices are ambiguous whether you'd want a file system on them or a partition table.
            – jdwolf
            Dec 23 '17 at 8:05










          • my comment really wasn't about containers or VMs (i.e. the fact that my ZVOLs are mostly used for VMs isn't relevant). ZFS ZVOLs are block devices, just like any other - that's their entire purpose. The kernel recognises them as block devices, and they can be formatted with filesystems, as several of mine were - but your command still listed them as unformatted block devices. This is a problem with lsblk not recognising the filesystem on a formatted ZVOL block device...btw, blkid recognises them and detects the fs type.
            – cas
            Dec 23 '17 at 8:13










          • @cas NVM. lsblk handles LVM volumes just fine. Any PVs partitions or not are considered holders.
            – jdwolf
            Dec 23 '17 at 8:14










          • @cas the term "container" was misspoken. I meant holders which means block devices where there is a partitions or volumes on it. Or in other words where the kernel is using it to derive other block devices.
            – jdwolf
            Dec 23 '17 at 8:18


















          up vote
          0
          down vote













          In my opinion, the best option is FDISK.
          syntax:



          fdisk -l | grep -i ^disk





          share|improve this answer





























            up vote
            0
            down vote













            You can use parted utility for listing all disks,whether they have filesystems or not:



            sudo parted



            and then type "print free".



            It will print all partitioned as well as non-partitioned drives.



            enter image description here






            share|improve this answer



























              up vote
              0
              down vote













              The following one-liner seems to work. It prints all block device names except those which have a TYPE, PTTYPE, LABEL, or PARTLABEL. The last two on the grounds that something with a label is likely to be in use already.



              This seems to me to be a much better approach than using grep -v to exclude a list of filesystem types known at this moment in time.



              blkid | awk -F': ' '!/ ((PT)?TYPE|(PART)?LABEL)="[^"]+"/ print $1'


              Note: the list of block devices produced by this are NOT in any way guaranteed not to be in use, just that they don't have any of the commonly used markers that in-use block devices have. They're probably not in use, but without spending significantly more time researching the issue I'm extremely reluctant to even suggest that it is any kind of guaranteed list.



              On one of my ZFS On Linux boxes, it produces the following output:



              # blkid | awk -F': ' '!/ ((PT)?TYPE|(PART)?LABEL)="[^"]*"/ print $1'
              /dev/sdb9


              This is correct for that system. /dev/sdb9 IS an unformatted, unused partition. It's an 8MB partition at the end of a disk which is used in a single-disk ZFS pool (this is a home machine for testing stuff and I needed its mirror drive for something else and haven't got around to replacing it yet)




              BTW, blkid takes significantly longer to run than lsblk. It does a lot more work trying to identify what kind of block device it's looking at.



              This is probably only noticeable on servers with hundreds of drives/lvm members/zvols and other block devices.



              For example, on one of my medium-sized servers (with 362 block devices of various kinds), blkid takes about 2 minutes to run, while lsblk takes about 0.09 seconds. On another, much smaller, system with only 39 block devices (the home testing box mentioned above), blkid takes 0.16 seconds while lsblk takes 0.01 seconds.



              If you need to run this repeatedly and the run-time is too long, you can always cache blkdid's output in a tmpfile for a short time. e.g. if the cache either doesn't exist or is older than, say, 30 minutes then generate the cache file (blkid > /path/to/blkid.cache) and use that as the input to awk or whatever.






              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: false,
                showLowRepImageUploadWarning: true,
                reputationToPostImages: null,
                bindNavPrevention: true,
                postfix: "",
                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%2f412483%2fhow-to-capture-all-disks-that-don-t-have-a-file-system%23new-answer', 'question_page');

                );

                Post as a guest






























                4 Answers
                4






                active

                oldest

                votes








                4 Answers
                4






                active

                oldest

                votes









                active

                oldest

                votes






                active

                oldest

                votes








                up vote
                3
                down vote



                accepted










                lsblk -o NAME,FSTYPE -dsn


                This will print a list of block devices that are not themselves holders for partitions (they do not have a partition table). The detected file system type is in the second column. If its blank there is no recognized file system.



                So to get the output you want in one command



                lsblk -o NAME,FSTYPE -dsn | awk '$2 == "" print $1'





                share|improve this answer






















                • This is good unless you've got ZFS pools with ZVOLs on them. e.g. on one of my systems, some of the block devices your lsblk ... | awk ... command lists are zd128p[123]. They're actually partitions 1-3 of /dev/zd128 (which happens to be /dev/zvol/volumes/freebsd, my freebsd VM's disk image). There are other ZVOL devices which it lists, too (including a few centos, debian, and ubuntu VMs). BTW file -s /dev/zd128p3 reports /dev/zd128p3: Unix Fast File system [v2] (little-endian) last mounted on [.....]. I'm not sure if this would happen with LVM volumes too - it's been a while.
                  – cas
                  Dec 23 '17 at 7:35










                • @cas the above command only recognizes containers in the case of block devices that are part of a partition table. As far as I know that concept doesn't extend to a fs volume. Also it would skip block devices without a partition table that are in containers. Maybe I shouldn't assume the op doesn't want that? but such devices are ambiguous whether you'd want a file system on them or a partition table.
                  – jdwolf
                  Dec 23 '17 at 8:05










                • my comment really wasn't about containers or VMs (i.e. the fact that my ZVOLs are mostly used for VMs isn't relevant). ZFS ZVOLs are block devices, just like any other - that's their entire purpose. The kernel recognises them as block devices, and they can be formatted with filesystems, as several of mine were - but your command still listed them as unformatted block devices. This is a problem with lsblk not recognising the filesystem on a formatted ZVOL block device...btw, blkid recognises them and detects the fs type.
                  – cas
                  Dec 23 '17 at 8:13










                • @cas NVM. lsblk handles LVM volumes just fine. Any PVs partitions or not are considered holders.
                  – jdwolf
                  Dec 23 '17 at 8:14










                • @cas the term "container" was misspoken. I meant holders which means block devices where there is a partitions or volumes on it. Or in other words where the kernel is using it to derive other block devices.
                  – jdwolf
                  Dec 23 '17 at 8:18















                up vote
                3
                down vote



                accepted










                lsblk -o NAME,FSTYPE -dsn


                This will print a list of block devices that are not themselves holders for partitions (they do not have a partition table). The detected file system type is in the second column. If its blank there is no recognized file system.



                So to get the output you want in one command



                lsblk -o NAME,FSTYPE -dsn | awk '$2 == "" print $1'





                share|improve this answer






















                • This is good unless you've got ZFS pools with ZVOLs on them. e.g. on one of my systems, some of the block devices your lsblk ... | awk ... command lists are zd128p[123]. They're actually partitions 1-3 of /dev/zd128 (which happens to be /dev/zvol/volumes/freebsd, my freebsd VM's disk image). There are other ZVOL devices which it lists, too (including a few centos, debian, and ubuntu VMs). BTW file -s /dev/zd128p3 reports /dev/zd128p3: Unix Fast File system [v2] (little-endian) last mounted on [.....]. I'm not sure if this would happen with LVM volumes too - it's been a while.
                  – cas
                  Dec 23 '17 at 7:35










                • @cas the above command only recognizes containers in the case of block devices that are part of a partition table. As far as I know that concept doesn't extend to a fs volume. Also it would skip block devices without a partition table that are in containers. Maybe I shouldn't assume the op doesn't want that? but such devices are ambiguous whether you'd want a file system on them or a partition table.
                  – jdwolf
                  Dec 23 '17 at 8:05










                • my comment really wasn't about containers or VMs (i.e. the fact that my ZVOLs are mostly used for VMs isn't relevant). ZFS ZVOLs are block devices, just like any other - that's their entire purpose. The kernel recognises them as block devices, and they can be formatted with filesystems, as several of mine were - but your command still listed them as unformatted block devices. This is a problem with lsblk not recognising the filesystem on a formatted ZVOL block device...btw, blkid recognises them and detects the fs type.
                  – cas
                  Dec 23 '17 at 8:13










                • @cas NVM. lsblk handles LVM volumes just fine. Any PVs partitions or not are considered holders.
                  – jdwolf
                  Dec 23 '17 at 8:14










                • @cas the term "container" was misspoken. I meant holders which means block devices where there is a partitions or volumes on it. Or in other words where the kernel is using it to derive other block devices.
                  – jdwolf
                  Dec 23 '17 at 8:18













                up vote
                3
                down vote



                accepted







                up vote
                3
                down vote



                accepted






                lsblk -o NAME,FSTYPE -dsn


                This will print a list of block devices that are not themselves holders for partitions (they do not have a partition table). The detected file system type is in the second column. If its blank there is no recognized file system.



                So to get the output you want in one command



                lsblk -o NAME,FSTYPE -dsn | awk '$2 == "" print $1'





                share|improve this answer














                lsblk -o NAME,FSTYPE -dsn


                This will print a list of block devices that are not themselves holders for partitions (they do not have a partition table). The detected file system type is in the second column. If its blank there is no recognized file system.



                So to get the output you want in one command



                lsblk -o NAME,FSTYPE -dsn | awk '$2 == "" print $1'






                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Dec 22 '17 at 14:34

























                answered Dec 22 '17 at 14:20









                jdwolf

                2,392116




                2,392116











                • This is good unless you've got ZFS pools with ZVOLs on them. e.g. on one of my systems, some of the block devices your lsblk ... | awk ... command lists are zd128p[123]. They're actually partitions 1-3 of /dev/zd128 (which happens to be /dev/zvol/volumes/freebsd, my freebsd VM's disk image). There are other ZVOL devices which it lists, too (including a few centos, debian, and ubuntu VMs). BTW file -s /dev/zd128p3 reports /dev/zd128p3: Unix Fast File system [v2] (little-endian) last mounted on [.....]. I'm not sure if this would happen with LVM volumes too - it's been a while.
                  – cas
                  Dec 23 '17 at 7:35










                • @cas the above command only recognizes containers in the case of block devices that are part of a partition table. As far as I know that concept doesn't extend to a fs volume. Also it would skip block devices without a partition table that are in containers. Maybe I shouldn't assume the op doesn't want that? but such devices are ambiguous whether you'd want a file system on them or a partition table.
                  – jdwolf
                  Dec 23 '17 at 8:05










                • my comment really wasn't about containers or VMs (i.e. the fact that my ZVOLs are mostly used for VMs isn't relevant). ZFS ZVOLs are block devices, just like any other - that's their entire purpose. The kernel recognises them as block devices, and they can be formatted with filesystems, as several of mine were - but your command still listed them as unformatted block devices. This is a problem with lsblk not recognising the filesystem on a formatted ZVOL block device...btw, blkid recognises them and detects the fs type.
                  – cas
                  Dec 23 '17 at 8:13










                • @cas NVM. lsblk handles LVM volumes just fine. Any PVs partitions or not are considered holders.
                  – jdwolf
                  Dec 23 '17 at 8:14










                • @cas the term "container" was misspoken. I meant holders which means block devices where there is a partitions or volumes on it. Or in other words where the kernel is using it to derive other block devices.
                  – jdwolf
                  Dec 23 '17 at 8:18

















                • This is good unless you've got ZFS pools with ZVOLs on them. e.g. on one of my systems, some of the block devices your lsblk ... | awk ... command lists are zd128p[123]. They're actually partitions 1-3 of /dev/zd128 (which happens to be /dev/zvol/volumes/freebsd, my freebsd VM's disk image). There are other ZVOL devices which it lists, too (including a few centos, debian, and ubuntu VMs). BTW file -s /dev/zd128p3 reports /dev/zd128p3: Unix Fast File system [v2] (little-endian) last mounted on [.....]. I'm not sure if this would happen with LVM volumes too - it's been a while.
                  – cas
                  Dec 23 '17 at 7:35










                • @cas the above command only recognizes containers in the case of block devices that are part of a partition table. As far as I know that concept doesn't extend to a fs volume. Also it would skip block devices without a partition table that are in containers. Maybe I shouldn't assume the op doesn't want that? but such devices are ambiguous whether you'd want a file system on them or a partition table.
                  – jdwolf
                  Dec 23 '17 at 8:05










                • my comment really wasn't about containers or VMs (i.e. the fact that my ZVOLs are mostly used for VMs isn't relevant). ZFS ZVOLs are block devices, just like any other - that's their entire purpose. The kernel recognises them as block devices, and they can be formatted with filesystems, as several of mine were - but your command still listed them as unformatted block devices. This is a problem with lsblk not recognising the filesystem on a formatted ZVOL block device...btw, blkid recognises them and detects the fs type.
                  – cas
                  Dec 23 '17 at 8:13










                • @cas NVM. lsblk handles LVM volumes just fine. Any PVs partitions or not are considered holders.
                  – jdwolf
                  Dec 23 '17 at 8:14










                • @cas the term "container" was misspoken. I meant holders which means block devices where there is a partitions or volumes on it. Or in other words where the kernel is using it to derive other block devices.
                  – jdwolf
                  Dec 23 '17 at 8:18
















                This is good unless you've got ZFS pools with ZVOLs on them. e.g. on one of my systems, some of the block devices your lsblk ... | awk ... command lists are zd128p[123]. They're actually partitions 1-3 of /dev/zd128 (which happens to be /dev/zvol/volumes/freebsd, my freebsd VM's disk image). There are other ZVOL devices which it lists, too (including a few centos, debian, and ubuntu VMs). BTW file -s /dev/zd128p3 reports /dev/zd128p3: Unix Fast File system [v2] (little-endian) last mounted on [.....]. I'm not sure if this would happen with LVM volumes too - it's been a while.
                – cas
                Dec 23 '17 at 7:35




                This is good unless you've got ZFS pools with ZVOLs on them. e.g. on one of my systems, some of the block devices your lsblk ... | awk ... command lists are zd128p[123]. They're actually partitions 1-3 of /dev/zd128 (which happens to be /dev/zvol/volumes/freebsd, my freebsd VM's disk image). There are other ZVOL devices which it lists, too (including a few centos, debian, and ubuntu VMs). BTW file -s /dev/zd128p3 reports /dev/zd128p3: Unix Fast File system [v2] (little-endian) last mounted on [.....]. I'm not sure if this would happen with LVM volumes too - it's been a while.
                – cas
                Dec 23 '17 at 7:35












                @cas the above command only recognizes containers in the case of block devices that are part of a partition table. As far as I know that concept doesn't extend to a fs volume. Also it would skip block devices without a partition table that are in containers. Maybe I shouldn't assume the op doesn't want that? but such devices are ambiguous whether you'd want a file system on them or a partition table.
                – jdwolf
                Dec 23 '17 at 8:05




                @cas the above command only recognizes containers in the case of block devices that are part of a partition table. As far as I know that concept doesn't extend to a fs volume. Also it would skip block devices without a partition table that are in containers. Maybe I shouldn't assume the op doesn't want that? but such devices are ambiguous whether you'd want a file system on them or a partition table.
                – jdwolf
                Dec 23 '17 at 8:05












                my comment really wasn't about containers or VMs (i.e. the fact that my ZVOLs are mostly used for VMs isn't relevant). ZFS ZVOLs are block devices, just like any other - that's their entire purpose. The kernel recognises them as block devices, and they can be formatted with filesystems, as several of mine were - but your command still listed them as unformatted block devices. This is a problem with lsblk not recognising the filesystem on a formatted ZVOL block device...btw, blkid recognises them and detects the fs type.
                – cas
                Dec 23 '17 at 8:13




                my comment really wasn't about containers or VMs (i.e. the fact that my ZVOLs are mostly used for VMs isn't relevant). ZFS ZVOLs are block devices, just like any other - that's their entire purpose. The kernel recognises them as block devices, and they can be formatted with filesystems, as several of mine were - but your command still listed them as unformatted block devices. This is a problem with lsblk not recognising the filesystem on a formatted ZVOL block device...btw, blkid recognises them and detects the fs type.
                – cas
                Dec 23 '17 at 8:13












                @cas NVM. lsblk handles LVM volumes just fine. Any PVs partitions or not are considered holders.
                – jdwolf
                Dec 23 '17 at 8:14




                @cas NVM. lsblk handles LVM volumes just fine. Any PVs partitions or not are considered holders.
                – jdwolf
                Dec 23 '17 at 8:14












                @cas the term "container" was misspoken. I meant holders which means block devices where there is a partitions or volumes on it. Or in other words where the kernel is using it to derive other block devices.
                – jdwolf
                Dec 23 '17 at 8:18





                @cas the term "container" was misspoken. I meant holders which means block devices where there is a partitions or volumes on it. Or in other words where the kernel is using it to derive other block devices.
                – jdwolf
                Dec 23 '17 at 8:18













                up vote
                0
                down vote













                In my opinion, the best option is FDISK.
                syntax:



                fdisk -l | grep -i ^disk





                share|improve this answer


























                  up vote
                  0
                  down vote













                  In my opinion, the best option is FDISK.
                  syntax:



                  fdisk -l | grep -i ^disk





                  share|improve this answer
























                    up vote
                    0
                    down vote










                    up vote
                    0
                    down vote









                    In my opinion, the best option is FDISK.
                    syntax:



                    fdisk -l | grep -i ^disk





                    share|improve this answer














                    In my opinion, the best option is FDISK.
                    syntax:



                    fdisk -l | grep -i ^disk






                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Dec 22 '17 at 15:52

























                    answered Dec 22 '17 at 15:26









                    Alessandro Schneider

                    1012




                    1012




















                        up vote
                        0
                        down vote













                        You can use parted utility for listing all disks,whether they have filesystems or not:



                        sudo parted



                        and then type "print free".



                        It will print all partitioned as well as non-partitioned drives.



                        enter image description here






                        share|improve this answer
























                          up vote
                          0
                          down vote













                          You can use parted utility for listing all disks,whether they have filesystems or not:



                          sudo parted



                          and then type "print free".



                          It will print all partitioned as well as non-partitioned drives.



                          enter image description here






                          share|improve this answer






















                            up vote
                            0
                            down vote










                            up vote
                            0
                            down vote









                            You can use parted utility for listing all disks,whether they have filesystems or not:



                            sudo parted



                            and then type "print free".



                            It will print all partitioned as well as non-partitioned drives.



                            enter image description here






                            share|improve this answer












                            You can use parted utility for listing all disks,whether they have filesystems or not:



                            sudo parted



                            and then type "print free".



                            It will print all partitioned as well as non-partitioned drives.



                            enter image description here







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Dec 24 '17 at 14:39









                            AshishKumar

                            11




                            11




















                                up vote
                                0
                                down vote













                                The following one-liner seems to work. It prints all block device names except those which have a TYPE, PTTYPE, LABEL, or PARTLABEL. The last two on the grounds that something with a label is likely to be in use already.



                                This seems to me to be a much better approach than using grep -v to exclude a list of filesystem types known at this moment in time.



                                blkid | awk -F': ' '!/ ((PT)?TYPE|(PART)?LABEL)="[^"]+"/ print $1'


                                Note: the list of block devices produced by this are NOT in any way guaranteed not to be in use, just that they don't have any of the commonly used markers that in-use block devices have. They're probably not in use, but without spending significantly more time researching the issue I'm extremely reluctant to even suggest that it is any kind of guaranteed list.



                                On one of my ZFS On Linux boxes, it produces the following output:



                                # blkid | awk -F': ' '!/ ((PT)?TYPE|(PART)?LABEL)="[^"]*"/ print $1'
                                /dev/sdb9


                                This is correct for that system. /dev/sdb9 IS an unformatted, unused partition. It's an 8MB partition at the end of a disk which is used in a single-disk ZFS pool (this is a home machine for testing stuff and I needed its mirror drive for something else and haven't got around to replacing it yet)




                                BTW, blkid takes significantly longer to run than lsblk. It does a lot more work trying to identify what kind of block device it's looking at.



                                This is probably only noticeable on servers with hundreds of drives/lvm members/zvols and other block devices.



                                For example, on one of my medium-sized servers (with 362 block devices of various kinds), blkid takes about 2 minutes to run, while lsblk takes about 0.09 seconds. On another, much smaller, system with only 39 block devices (the home testing box mentioned above), blkid takes 0.16 seconds while lsblk takes 0.01 seconds.



                                If you need to run this repeatedly and the run-time is too long, you can always cache blkdid's output in a tmpfile for a short time. e.g. if the cache either doesn't exist or is older than, say, 30 minutes then generate the cache file (blkid > /path/to/blkid.cache) and use that as the input to awk or whatever.






                                share|improve this answer
























                                  up vote
                                  0
                                  down vote













                                  The following one-liner seems to work. It prints all block device names except those which have a TYPE, PTTYPE, LABEL, or PARTLABEL. The last two on the grounds that something with a label is likely to be in use already.



                                  This seems to me to be a much better approach than using grep -v to exclude a list of filesystem types known at this moment in time.



                                  blkid | awk -F': ' '!/ ((PT)?TYPE|(PART)?LABEL)="[^"]+"/ print $1'


                                  Note: the list of block devices produced by this are NOT in any way guaranteed not to be in use, just that they don't have any of the commonly used markers that in-use block devices have. They're probably not in use, but without spending significantly more time researching the issue I'm extremely reluctant to even suggest that it is any kind of guaranteed list.



                                  On one of my ZFS On Linux boxes, it produces the following output:



                                  # blkid | awk -F': ' '!/ ((PT)?TYPE|(PART)?LABEL)="[^"]*"/ print $1'
                                  /dev/sdb9


                                  This is correct for that system. /dev/sdb9 IS an unformatted, unused partition. It's an 8MB partition at the end of a disk which is used in a single-disk ZFS pool (this is a home machine for testing stuff and I needed its mirror drive for something else and haven't got around to replacing it yet)




                                  BTW, blkid takes significantly longer to run than lsblk. It does a lot more work trying to identify what kind of block device it's looking at.



                                  This is probably only noticeable on servers with hundreds of drives/lvm members/zvols and other block devices.



                                  For example, on one of my medium-sized servers (with 362 block devices of various kinds), blkid takes about 2 minutes to run, while lsblk takes about 0.09 seconds. On another, much smaller, system with only 39 block devices (the home testing box mentioned above), blkid takes 0.16 seconds while lsblk takes 0.01 seconds.



                                  If you need to run this repeatedly and the run-time is too long, you can always cache blkdid's output in a tmpfile for a short time. e.g. if the cache either doesn't exist or is older than, say, 30 minutes then generate the cache file (blkid > /path/to/blkid.cache) and use that as the input to awk or whatever.






                                  share|improve this answer






















                                    up vote
                                    0
                                    down vote










                                    up vote
                                    0
                                    down vote









                                    The following one-liner seems to work. It prints all block device names except those which have a TYPE, PTTYPE, LABEL, or PARTLABEL. The last two on the grounds that something with a label is likely to be in use already.



                                    This seems to me to be a much better approach than using grep -v to exclude a list of filesystem types known at this moment in time.



                                    blkid | awk -F': ' '!/ ((PT)?TYPE|(PART)?LABEL)="[^"]+"/ print $1'


                                    Note: the list of block devices produced by this are NOT in any way guaranteed not to be in use, just that they don't have any of the commonly used markers that in-use block devices have. They're probably not in use, but without spending significantly more time researching the issue I'm extremely reluctant to even suggest that it is any kind of guaranteed list.



                                    On one of my ZFS On Linux boxes, it produces the following output:



                                    # blkid | awk -F': ' '!/ ((PT)?TYPE|(PART)?LABEL)="[^"]*"/ print $1'
                                    /dev/sdb9


                                    This is correct for that system. /dev/sdb9 IS an unformatted, unused partition. It's an 8MB partition at the end of a disk which is used in a single-disk ZFS pool (this is a home machine for testing stuff and I needed its mirror drive for something else and haven't got around to replacing it yet)




                                    BTW, blkid takes significantly longer to run than lsblk. It does a lot more work trying to identify what kind of block device it's looking at.



                                    This is probably only noticeable on servers with hundreds of drives/lvm members/zvols and other block devices.



                                    For example, on one of my medium-sized servers (with 362 block devices of various kinds), blkid takes about 2 minutes to run, while lsblk takes about 0.09 seconds. On another, much smaller, system with only 39 block devices (the home testing box mentioned above), blkid takes 0.16 seconds while lsblk takes 0.01 seconds.



                                    If you need to run this repeatedly and the run-time is too long, you can always cache blkdid's output in a tmpfile for a short time. e.g. if the cache either doesn't exist or is older than, say, 30 minutes then generate the cache file (blkid > /path/to/blkid.cache) and use that as the input to awk or whatever.






                                    share|improve this answer












                                    The following one-liner seems to work. It prints all block device names except those which have a TYPE, PTTYPE, LABEL, or PARTLABEL. The last two on the grounds that something with a label is likely to be in use already.



                                    This seems to me to be a much better approach than using grep -v to exclude a list of filesystem types known at this moment in time.



                                    blkid | awk -F': ' '!/ ((PT)?TYPE|(PART)?LABEL)="[^"]+"/ print $1'


                                    Note: the list of block devices produced by this are NOT in any way guaranteed not to be in use, just that they don't have any of the commonly used markers that in-use block devices have. They're probably not in use, but without spending significantly more time researching the issue I'm extremely reluctant to even suggest that it is any kind of guaranteed list.



                                    On one of my ZFS On Linux boxes, it produces the following output:



                                    # blkid | awk -F': ' '!/ ((PT)?TYPE|(PART)?LABEL)="[^"]*"/ print $1'
                                    /dev/sdb9


                                    This is correct for that system. /dev/sdb9 IS an unformatted, unused partition. It's an 8MB partition at the end of a disk which is used in a single-disk ZFS pool (this is a home machine for testing stuff and I needed its mirror drive for something else and haven't got around to replacing it yet)




                                    BTW, blkid takes significantly longer to run than lsblk. It does a lot more work trying to identify what kind of block device it's looking at.



                                    This is probably only noticeable on servers with hundreds of drives/lvm members/zvols and other block devices.



                                    For example, on one of my medium-sized servers (with 362 block devices of various kinds), blkid takes about 2 minutes to run, while lsblk takes about 0.09 seconds. On another, much smaller, system with only 39 block devices (the home testing box mentioned above), blkid takes 0.16 seconds while lsblk takes 0.01 seconds.



                                    If you need to run this repeatedly and the run-time is too long, you can always cache blkdid's output in a tmpfile for a short time. e.g. if the cache either doesn't exist or is older than, say, 30 minutes then generate the cache file (blkid > /path/to/blkid.cache) and use that as the input to awk or whatever.







                                    share|improve this answer












                                    share|improve this answer



                                    share|improve this answer










                                    answered Dec 25 '17 at 12:44









                                    cas

                                    37.7k44394




                                    37.7k44394






















                                         

                                        draft saved


                                        draft discarded


























                                         


                                        draft saved


                                        draft discarded














                                        StackExchange.ready(
                                        function ()
                                        StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f412483%2fhow-to-capture-all-disks-that-don-t-have-a-file-system%23new-answer', 'question_page');

                                        );

                                        Post as a guest













































































                                        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?