0

I want to share the following very strange behavior , that for me it's not make sense but its a a fact on our production RHEL 7.2 server

disks are VMDK

from df -h we can see the following:

sdb         /DB_STORAGE_1

and its also defined in /etc/fstab file

/dev/sdb /DB_STORAGE_1                      ext4 defaults,noatime 0 0

but when I run lsblk -f , we can see that FSTYPE not exist on sdb disk , ( and also not the UUID ) ,

but FSTYPE exist on others disks as sdc / sdd

lsblk -f

sdb                                                                         /DB_STORAGE_1
sdc                ext4              d77598ec-9f19-48dc-b364-bb60b0396019   /DB_STORAGE_2
sdd                ext4              bf48c193-d58c-4ef3-b717-ea681ec1684a   /DB_STORAGE_3

for sure I can tell everyone that filesystem ext4 was created in the past for all disks sdb / sdc /sdd

so we do not understand how it can be that ext4 filesystem not displayed by lsblk -f

second - under /DB_STORAGE_1 , we can see the relevant data and folers/files

as all know in principle, we can't mount disk to folder without filesystem that created by mkfs command

so how it can be? , what could be the reason/s that ext4 not exist from lsblk -f ?

we also see that from mount command.

/dev/sdb on /DB_STORAGE_1 type ext4 (rw,noatime,data=ordered)

when I run blkid I get

/dev/sdb: UUID="74d50923-817d-423c-9736-743863ebe5d2" TYPE="ext4"

so how it can be??

from dmesg I get that

dmesg -T | grep sdb
[Tue Mar  7 13:27:31 2023] sd 0:0:2:0: [sdb] 41943040 512-byte logical blocks: (21.4 GB/20.0 GiB)
[Tue Mar  7 13:27:31 2023] sd 0:0:2:0: [sdb] Write Protect is off
[Tue Mar  7 13:27:31 2023] sd 0:0:2:0: [sdb] Mode Sense: 3b 00 00 00
[Tue Mar  7 13:27:31 2023] sd 0:0:2:0: [sdb] Write cache: disabled, read cache: disabled, doesn't support DPO or FUA
[Tue Mar  7 13:27:31 2023]  sdb: unknown partition table
[Tue Mar  7 13:27:31 2023] sd 0:0:2:0: [sdb] Attached SCSI disk
[Tue Mar  7 14:47:27 2023] EXT4-fs (sdb): mounted filesystem with ordered data mode. Opts: (null)

 uptime
 22:25:08 up 7 days,  8:57,  2 users,  load average: 3.75, 3.41, 3.52

smartctl -a /dev/sdb
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.10.0-327.el7.x86_64] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               VMware
Product:              Virtual disk
Revision:             2.0
User Capacity:        21,474,836,480 bytes [21.4 GB]
Logical block size:   512 bytes
LU is thin provisioned, LBPRZ=1
Rotation Rate:        15000 rpm
Device type:          disk
Local Time is:        Tue Mar 14 22:30:09 2023 UTC
SMART support is:     Unavailable - device lacks SMART capability.

=== START OF READ SMART DATA SECTION ===

Error Counter logging not supported
King David
  • 549
  • 6
  • 20
  • https://unix.stackexchange.com/questions/642598/lsblk-file-system-type-not-appears-from-lsblk – AlexD Mar 15 '23 at 06:35
  • 1
    It's probably an error. To my experience, I've noted that some versions GNU/Linux disk tools have problems with recognizing filesystems which are directly applied onto a device, rather than a partition/volume. If you really want to fix this "error", either use a partition table/LVM on all devices, or update your disk tools. You also might report a bug to RedHat. (In my opinion RedHat uses really outdated software.) – paladin Mar 15 '23 at 07:56

0 Answers0