On 12/22/23 09:23, Viacheslav Dubeyko wrote:
On Dec 21, 2023, at 11:33 PM, Bart Van Assche <bvanassche@xxxxxxx> wrote:
<skipped>
.
Hi Hannes,
I'm interested in this topic. But I'm wondering whether the disadvantages of
large blocks will be covered? Some NAND storage vendors are less than
enthusiast about increasing the logical block size beyond 4 KiB because it
increases the size of many writes to the device and hence increases write
amplification.
I am also interested in this discussion. Every SSD manufacturer carefully hides
the details of architecture and FTL’s behavior. I believe that switching on bigger
logical size (like 8KB, 16KB, etc) could be even better for SSD's internal mapping
scheme and erase blocks management. I assume that it could require significant
reworking the firmware and, potentially, ASIC logic. This could be the main pain
for SSD manufactures. Frankly speaking, I don’t see the direct relation between
increasing logical block size and increasing write amplification. If you have 16KB
logical block size on SSD side and file system will continue to use 4KB logical
block size, then, yes, I can see the problem. But if file system manages the space
in 16KB logical blocks and carefully issue the I/O requests of proper size, then
everything should be good. Again, FTL is simply trying to write logical blocks into
erase block. And we have, for example, 8MB erase block, then mapping and writing
16KB logical blocks looks like more beneficial operation compared with 4KB logical
block.
So, I see more troubles on file systems side to support bigger logical size. For example,
we discussed the 8KB folio size support recently. Matthew already shared the patch
for supporting 8KB folio size, but everything should be carefully tested. Also, I experienced
the issue with read ahead logic. For example, if I format my file system volume with 32KB
logical block, then read ahead logic returns to me 16KB folios that was slightly surprising
to me. So, I assume we can find a lot of potential issues on file systems side for bigger
logical size from the point of view of efficiency of metadata and user data operations.
Also, high-loaded systems could have fragmented memory that could make the memory
allocation more tricky operation. I mean here that it could be not easy to allocate one big
folio. Log-structured file systems can easily aligned write I/O requests for bigger logical
size. But in-place update file systems can increase write amplification for bigger logical
size because of necessity to flush bigger portion of data for small modification. However,
FTL can use delta-encoding and smart logic of compaction several logical blocks into
one NAND flash page. And, by the way, NAND flash page usually is bigger than 4KB.
And that is actually a very valid point; memory fragmentation will
become an issue with larger block sizes.
Theoretically it should be quite easily solved; just switch the memory
subsystem to use the largest block size in the system, and run every
smaller memory allocation via SLUB (or whatever the allocator-of-the-day
currently is :-). Then trivially the system will never be fragmented,
and I/O can always use large folios.
However, that means to do away with alloc_page(), which is still in
widespread use throughout the kernel. I would actually in favour of it,
but it might be that mm people have a different view.
Matthew, worth a new topic?
Handling memory fragmentation on large block I/O systems?
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Ivo Totev, Andrew McDonald,
Werner Knoblich
