Linux

hideshow 2 child comments

parent

[–] non_burglar@lemmy.world 3 points 3 weeks ago (2 children)

Except for leaving things default, almost none of that comment is true.

4k is default for most disks today. Some transition-era ssds used 8k blocks.

Do not worry about emulated block size, because ssds only use that to report to the filesystem, no sectors exist on solid state media.

hideshow 4 child comments

parent

[–] akunohana@piefed.blahaj.zone [S] 3 points 3 weeks ago*

Although this post is about an HDD 🫣

Edit: but if I can leave things at default and not touch hdparm either REGARDLESS, I'm happy 🤣

parent

[–] SteveTech@aussie.zone 2 points 3 weeks ago (1 child)

Do not worry about emulated block size, because ssds only use that to report to the filesystem, no sectors exist on solid state media.

Well SSDs have flash pages, which are essentially sectors as they are the smallest unit you can read/write, and they're usually 4096 bytes on NAND flash. My understanding is to write to a flash page you have to erase the whole block of 32+ pages before writing, 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), then the controller has to do a read-erase-program across the whole block of pages (although wear leveling will probably read + copy the modified page to elsewhere instead), instead of just a single program operation on one page (assuming a properly trimmed SSD).

So IMO, 4Kn is more important on SSDs, yet every vendor sets 512e by default. Luckily quite a few NVMe SSDs (not Samsung), let you change the logical block size with an nvme format command.

But more related to the OP, HDDs are a lot slower and don't have to erase multiple sectors before a write, so it's not as important, however partition alignment is still important but usually handled automatically in every modern partitioning tool. Sometimes you can switch a HDD to 4Kn with hdparm, but this isn't common, and you've said your HDD is dead anyway, so it won't help.

Also, sorry about bringing you into this, I have strong opinions against 512e SSDs haha.

hideshow 2 child comments

parent

[–] non_burglar@lemmy.world 1 point 3 weeks ago (1 child)

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

hideshow 2 child comments

parent

[–] SteveTech@aussie.zone 1 point 3 weeks 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.