ext3/ext4 physical block size view
Solution 1
$ sudo tune2fs -l /dev/vda1
tune2fs 1.42.8 (20-Jun-2013)
Filesystem volume name: <none>
...
Free inodes: 127696
First block: 1
Block size: 1024
Fragment size: 1024
Reserved GDT blocks: 256
Blocks per group: 8192
...
Solution 2
First, find the underlying dm
device:
ls -l /dev/mapper/vg01-srvvol
Example output:
lrwxrwxrwx 1 root root 7 Jan 28 14:32 /dev/mapper/vg01-srvvol -> ../dm-0
Take the dm-0
, dm-1
, etc and see here:
cat /sys/block/dm-0/queue/physical_block_size
Solution 3
The only reliable way to determine the real physical block size is by querying the disk directly with hdparm
:
hdparm -I /dev/sdX | grep Physical
All linux tools like parted
, tune2fs
, fdisk
, also the kernel (via the value provided in /proc) output 512 Bytes for disks I have which are denoted 4K by hdparm
. (5 HDDs tested, with two being 4K ones.)
Related videos on Youtube
c4f4t0r
I work as Linux system administrator for Ops area and sometime for area project, in my free time I love to play basketball, I love to improve my "(ruby|perl|python)" programming skills reading books and online topics.
Updated on September 18, 2022Comments
-
c4f4t0r over 1 year
I'm using a suse 11 server with xfs and using "xfs_info /srv" command i seen this.
xfs_info /srv/ meta-data=/dev/mapper/vg01-srvvol isize=256 agcount=38, agsize=1964032 blks = sectsz=512 attr=2 data = bsize=4096 blocks=73367552, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=3836, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0
So i think xfs knows the size of underline disk sectsz, but I'm using now a disk with sectsz of 512 bytes, but my question is, how can find this kind of information using ext3/ext4 filesystem?
Because i would like to try to use a new disk with sectsz of 4096 and be sure, ext3/ext4 uses the underline sectsz.
This is the output of xfs_info using one new ssd with physical block size 4096:
xfs_info /dev/mapper/vg00-logvol meta-data=/dev/mapper/vg00-logvol isize=256 agcount=16, agsize=7144576 blks = sectsz=4096 attr=2, projid32bit=0 data = bsize=4096 blocks=114313216, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=55817, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0
-
c4f4t0r almost 10 yearsthat's is filesystem block size, for example, if you have a filesystem block of 4096 and you physical sector size is 512 you will have something like this $((4096/512)) = 8, this isn't what i looking for
-
akostadinov almost 10 years@c4f4t0r, if you know your
phy
sector size, you only need to know FS sector size. What do you want to know actually? -
c4f4t0r almost 10 yearsthat'is, how can i know the FS sector size of ext3/ext4?
-
c4f4t0r almost 10 yearsthat's is related to the block device, i would like to know if ext3/ext4 has knowledge of the physical sector size of the underline block device
-
Joshua Huber almost 10 yearsAre you concerned because you are using one of the new larger disks (2 or 3 TB) that have 4kb physical, 512b logical sectors? I don't believe ext3/4 is yet aware of the underlying phy block size. I don't think ext3/4 needs to know the underlying block size. To make sure you are efficiently using the disk, your main concern should be alignment so that each 4kb fs block aligns onto 4kb phy blocks. You will almost certainly align correctly if you align your partitions at even 1MB increments. Maybe just test out your throughput. If getting 80 MB/sec+ uncached, you're probably aligned.
-
akostadinov almost 10 years@c4f4t0r,
Block size: 1024
-
akostadinov almost 10 years@JoshuaHuber, alignment issues are visible when you have lot's of smaller reads/writes. Sequential cannot usually show that. The file system tools are trying to align FS, LVM and md-raid automatically as long as the underlying storage device reports that information correctly. Manually aligning is rarely necessary. It is certainly recommended for the FS to have blocks matching or larger than the underlying storage. And ext3/4 are perfectly capable of that.
-
Joshua Huber almost 10 years@akostadinov, point taken about the sequential access, but to direct it back to the OP's question, if ext4 is aware of the underlying block 4k size, how do we verify that.
tune2fs
doesn't seem to provide that. Looking for something analogous to extsz as seen in output ofxfs_info
-
akostadinov almost 10 yearsYou see sector size with
tune2fs -l
. To know if partition is aligned, that's actually not something one would expecttune2fs
to know. You'd need to look atfdisk
or something. -
Joshua Huber almost 10 yearsI have
tune2fs
v.1.42.8, and it gives me 43 pieces of information, but nothing calledsector size
in the output oftune2fs -l
. I haveblock size
andfragment size
, but neither of those match the underlying physical block size. It appears again to be the FS block size, whatever you chose when you didmkfs
. Eg, I have a FS with 4kb ext4 blocks, but is on 512 byte physical disk. So the question is still open: how can I tell using e2fs tools what the underlying physical block size is? I want to see my 512. The OP wants to see his 4096 likexfs_stat
shows. -
Xen2050 about 5 yearsHow do you know hdparm is telling the truth, and the hard drives don't use some type of occasional firmware simulated 512-byte sector size?
-
sjas about 5 yearsif that were the case, the OS wont see any difference either