Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

some comments on block/sector size ( ch 14 ) #7

Open
gf-mse opened this issue Mar 31, 2018 · 0 comments
Open

some comments on block/sector size ( ch 14 ) #7

gf-mse opened this issue Mar 31, 2018 · 0 comments

Comments

@gf-mse
Copy link

gf-mse commented Mar 31, 2018

to https://github.com/shichao-an/notes/blob/master/docs/lkd/ch14.md :
I'm not sure whether that fits as book comments, but since it was probably the best introduction in the matter that I could quickly find online, I want to share my two cents, that one may or may not find useful:


Suppose we need to find out what's the optimal buffer size for reading from a device. Or have special needs -- e.g. want to tune a ZFS filesystem recordsize for a custom on-disk database -- may be even with enabled deduplication, what will make our needs really special.

So we wonder how the system reads and writes data from/to the device. These i/o buffers would be directly related to sector or block sizes.


As for device block sizes -- they, of course, first come from the device itself ; look at

/sys/block/sda/queue :

    hw_sector_size
    logical_block_size
    physical_block_size

That would be the same as smartctl or hdparm would tell us:

smartctl -a /dev/sda    # grep -i block
hdparm -I /dev/sda     # grep -i block

"Physical" and "logical" here would differ e.g. for Advanced Format disks ( and we'll be more interested in physical_block_size, if it's different ).


Next, there's something reported by man 2 stat ( struct stat -> st_blksize ) :

stat /etc/passwd ... -> ... IO Block: 4096

This essentially comes from the filesystem. ( In short, fs/stat.c shows that st_blksize comes from the inode, the inode gets it from the superblock, and the superblock normally has it as a power of two capped at PAGE_SIZE, i.e. the memory page size. )

So basically this boils down to a memory page size. Good to know.


PS. This is for example how cat determines the optimal buffer size :

-- and it does not perform that bad at all:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant