Score:0

RHEL + what could be the reason that FSTYPE not defined from lablk , in spite filesystem was created on disk in the past

gb flag

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
jp flag
https://unix.stackexchange.com/questions/642598/lsblk-file-system-type-not-appears-from-lsblk
paladin avatar
id flag
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.)
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.