5

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
Improve this question

3 Answers 3

Reset to default
7 
$ 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
...
Improve this answer
4
  • that'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
    – c4f4t0r
    Jun 13, 2014 at 13:17
  • @c4f4t0r, if you know your phy sector size, you only need to know FS sector size. What do you want to know actually?
    – akostadinov
    Jun 13, 2014 at 18:04
  • that'is, how can i know the FS sector size of ext3/ext4?
    – c4f4t0r
    Jun 14, 2014 at 8:48
  • @c4f4t0r, Block size: 1024
    – akostadinov
    Jun 16, 2014 at 8:20
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
Improve this answer
6
  • that'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
    – c4f4t0r
    Jun 14, 2014 at 8:50
  • 2
    Are 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.
    – Joshua Huber
    Jun 14, 2014 at 13:28
  • 1
    @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.
    – akostadinov
    Jun 16, 2014 at 8:24
  • 1
    @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 of xfs_info
    – Joshua Huber
    Jun 16, 2014 at 16:13
  • 1
    I have tune2fs v.1.42.8, and it gives me 43 pieces of information, but nothing called sector size in the output of tune2fs -l. I have block size and fragment 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 did mkfs. 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 like xfs_stat shows.
    – Joshua Huber
    Jun 16, 2014 at 21:25
1

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.)

Improve this answer
2
  • How 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?
    – Xen2050
    Apr 12, 2019 at 23:51
  • if that were the case, the OS wont see any difference either
    – sjas
    Apr 13, 2019 at 22:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .