Everywhere I read that internally SSDs are structured in 4K or larger "pages", which grouped in "blocks" of about 128-256 pages (1, 2). SSDs work with these pages and blocks, "they can only erase data at the block level" (thus the block of pages is called "[NAND] erase block"). And the 512B blocks for the partition are emulated (which is done for legacy reasons).

I'm trying to get educated on SSDs, since I have some weird lags/freezes during writes to my Sandisk U100 on Samsung 9 np900x3c laptop. And one useful thing would be to correctly find out what pages/blocks my SSD has?

Is there a utility or /sys/... file on Linux to determine the SSD page size?

Or "the drive and Googling the part numbers on the NAND chips may be needed", as in the comment?

Googling my Sandisk SSD I cannot find a proper datasheet/spec. But Sandisk and people do mention "4K random reads/writes". Does it mean the disk has 4K pages?

Also, fdisk shows me sector size (both physical and logical) and I/O 512 byte:

Disk /dev/sda: 128.0 GB, 128035676160 bytes
255 heads, 63 sectors/track, 15566 cylinders, total 250069680 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x4b914713

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048    50331647    25164800   83  Linux
/dev/sda2        50331648   239583231    94625792   83  Linux
/dev/sda4       239583232   250068991     5242880   82  Linux swap / Solaris

What is "physical" sector size here? It doesn't seem to be the parameter of the SSD drive itself, since everybody say SSD pages are 4K+. Is it the emulated parameter for the disk? And "logical" is the sector size for the partition? Also, what is I/O size?


This question is probably the same as this one for USB flash -- the answer is missing the point there, man fsstat says fsstat displays the details associated with a file system and the question is about the disk itself. My post has more details, maybe it would attract better responses?

3 Answers 3

  • The physical block size reported by fdisk is the physical block size reported by the disk when asked. It seldom has any relationship with SSD pages or erase blocks.

  • 4 KiB reads/writes are a common measure of I/O performance, representing "small" I/O operations.

  • There is no standard way for a SSD to report its page size or erase block size. Few if any manufacturers report them in the datasheets. (Because they may change during the lifetime of a SKU, for example because of changing suppliers.) There is a whitepaper from Intel which suggests that 4 KiB alignment is enough.

  • For practical use just align all your data structures (partitions, payload of LUKS containers, LVM logical volumes) to 1 or 2 MiB boundaries. It's an SSD after all--it is designed to cope with usual filesystems, such as NTFS (which uses 4 KiB allocation units). If Windows considers that aligning partitions to 1 MiB is enough you can bet that any SSD manufacturer will make sure that their products work well with such a configuration.

  • Best leave about 5% to 10% of unallocated space outside any partitions. Having overprovisioned space is of great help to SSDs in maintaining their performance in time.

  • "There is a whitepaper from Intel which suggests that 4 KiB alignment is enough." How do you get that from the linked paper? I looked over it, and it isn't at all obvious where the paper is claiming that.
    – Matthew
    Commented May 31, 2019 at 20:14
  • @Matthew: Page 7: "most new HDDs and Intel SSDs perform better with a 4096 Byte (4KB) alignment".
    – AlexP
    Commented May 31, 2019 at 20:34
  • 1
    +1 for sticking strictly to the KiB/MiB notation --- see man units for the sceptics Commented Mar 17, 2020 at 13:17
  • 1
    @XavierStuvw: There is no relationship between the linear array of blocks seen by the OS and the real physical blocks on the SSD. Remember that SSDs cannot overwrite blocks individually. When the OS updates a "logical" block, the microcontroller must find a new unused block, copy the updated data to that block, and move the old block in the "blocks to be erased and recycled" list. SSDs cannot even erase individual blocks, so at a certain point the microcontroller will have to allocate a new page, move some blocks and erase the old page. Having spare blocks known to be not used helps.
    – AlexP
    Commented Mar 17, 2020 at 13:30
  • 1
    @RJVB: The controller maps logical pages to physical pages. It keeps a list of free physical pages. It knows nothing of partitition tables, file systems and so on. It just knows what pages have been written to and what pages have not been written to. It doesn't know that a logical page will never be used in the future; but it does know that it has never been used in the past since the last clean up. This allows it to use the corresponding physical page when it needs a fresh logical page. (And it will clean up dirty pages which are no longer needed and place them on the free list.)
    – AlexP
    Commented Sep 24, 2023 at 18:43

I have tested misreporting SSDs by looking at SMART attribute 241 Total_LBAs_Written.

Warning: the following command will corrupt your data:
And then dd if=/dev/zero of=/dev/ssd_drive bs=1 count=1
(need to do it without filesystem overhead).

For a Samsung 850 EVO which reports 512 as sector size, the count increased by 8 with only one byte written.

So 8×512=4096 , and writing bs=4096 also increases by 8.

Meaning drive will always write to 4096-byte sectors internally.

  • That looks like a clever approach, but the Sandisk SSD I have at hand reports attr. 241 as "Host_Writes_32MiB" which suggests an unlikely high page size. There's also 245 "TLC_Writes_32MiB", btw.
    – RJVB
    Commented Sep 24, 2023 at 18:22
  • In fact, can't you use hdparm, to write 1 sector? That should write the physical sector size, with the advantage that you can control where the write takes places, e.g. in a non-allocated part if you don't want to lose any data.
    – RJVB
    Commented Sep 24, 2023 at 18:38

smartctl (available in smartmontools) should do it for you.

  • 7
    How would the OP use this tool to do so? Commented Jan 4, 2017 at 14:25
  • for now I'm getting the same 512B physical & logical sectors with smartctl -i /dev/sda, not sure how to read smartctl --all /dev/sda and smartctl --xall /dev/sda sent kernel into panic..
    – xealits
    Commented Jan 4, 2017 at 16:36
  • 5
    Having read up on SMART, I think it doesn't address such information as SSDs internal structure -- it monitors some parameters on errors/"health" of a disk, trying to catch possibility of disk failure
    – xealits
    Commented Jan 5, 2017 at 13:33

You must log in to answer this question.

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