this post was submitted on 22 Jul 2026
25 points (100.0% liked)

Linux

66581 readers
96 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 7 years ago
MODERATORS
 

Edit: feedback
Thanks for all the advice! Here's some funny feedback: it was a faulty drive 🤣 give me back my feelings 😭 obviously I'm sending it back

dhWvundoMJKYgdc.jpg

I have just received my Seagate 18TB IronWolf Pro HDD and the specs say that the logical sector size is 512 emulated. Moreover, Seagate says that switching to 4096 sector size is as easy as doing a quick format (Windows terminology?). I suppose on Linux this simply means creating a filesystem with that block size? For instance mkfs.ext4 -b 4096 /dev/device or - in my specific case - cryptsetup luksFormat --sector-size=4096 and then creating a file system?

What confuses me is the Arch Wiki article on advanced format that has instructions on how to use hdparm to tell the firmware to use a certain sector size.

Do I need to do the hdparm thing, which seemingly conflicts with the Seagate instructions?

you are viewing a single comment's thread
view the rest of the comments
[–] non_burglar@lemmy.world 1 points 1 day ago (1 children)

I think we're talking past each other here: You are talking about blocks as physical delineations in an ssd, containing many pages with erase cycles. Op is talking about the filesystem view of blocks, which is different altogether. ZFS, for instance, should have its block size aligned with what a disk presents to the HAL, or you end up with lots of wasted space or terrible performance.

For SSDs (you're right, outside op's problem), the internal block size is usually much bigger than the emulated block size, often 128K. But we don't use filesystems with 128K block sizes, or we couldn't reasonable run databases or store small files.

There was a brief time in the wild west of SSDs being new where some shipped with 8k blocks, but this caused a bunch of problems for storage drivers because no one had yet decided if the translation of FS blocks to should be handled by filesystems or by disk firmware. We now let manufacturers decide how they should r/w to media, and trust the firmware's presented block size.

That block size is now 4k for most disks, spinning or ssd. We still see some weird layouts in high-performance or high-endurance disks, but they are exceptions.

so if a 512e SSD doesn’t receive the rest of the page in time (e.g. with IO scheduling, 512 byte fs sectors, unaligned partitions, or bad luck)

I'm not sure what this means, pages are a concept in an ssd's physical structure, they don't mean anything to a filesystem (except in volatile memory).

[–] SteveTech@aussie.zone 1 points 5 hours ago

You are talking about blocks as physical delineations in an ssd, containing many pages with erase cycles. Op is talking about the filesystem view of blocks, which is different altogether.

I'm pretty sure OP is confused themselves, but I read this as referring to the physical sector size.

I'm not sure what this means, pages are a concept in an ssd's physical structure, they don't mean anything to a filesystem (except in volatile memory).

Fair enough, I probably explained it poorly. The problem is that pages don't mean anything to the filesystem, but the way the filesystem is layed out means a lot to the pages. With 512e, the SSD has to buffer each write until it can make up the whole 4K page. It'll also buffer a read until the whole 4K page is read. So if those buffers never become full/read, such as when the filesystem isn't aligned to it's pages, or the read/writes aren't in the right sequence, then it destroys your performance.

This also happens with HDDs, but they're slow enough to be able to rearrange operations, though an unaligned filesystem will still cause unnecessary reads before writes.