Skip to main content
Unix & Linux

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

8
  • Transfers for data that is not block-aligned (let alone word-aligned) will have an overhead during transfers to deal with part-blocks. Also, media that are capable of DMA (Direct Memory Access, which bypasses CPU usage) are more likely to be 32-bit limited internally. Commented Apr 29 at 8:42
  • @Paul_Pedant but read() already needs to be able to read an arbitrary amount of bytes, at an arbitrary file position, so even if 0x7fffffff = 2147483647 is a prime, it shouldn't matter. Commented Apr 29 at 9:30
  • 5
    FWIW, it's down to a #define MAX_RW_COUNT (INT_MAX & PAGE_MASK) in the code (in include/linux/fs.h). git log/blame might allow you to get back to the rationale Commented Apr 29 at 12:30
  • 2
    See github.com/torvalds/linux/commit/…. "We want to protect lower layers from (the sadly all too common) overflow conditions, but prefer to do so by chopping the requests up, rather than just refusing them outright" Commented Apr 29 at 12:36
  • @ilkkachu Agree that read() can deal with any file-pos and length, but a block device is just that: any data that is not precisely block-aligned would have to be cached and trimmed somewhere. The first line of the man page says "attempts to read up to count bytes", so the existing limit is both conformant, and avoids those overheads. Commented Apr 29 at 20:02