[Bug stdio/4099] Overly agressive caching by stream i/o functions.

["green at linuxhacker dot ru" <sourceware-bugzilla@sourceware.org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=4099

--- Comment #8 from Oleg Drokin <green at linuxhacker dot ru> ---
(In reply to Rich Felker from comment #7)

> This only makes sense if write() actually writes something to disk. It
> doesn't. It (conceptually) memcpy's from a userspace buffer to the kernel's
> cache buffers. So there's no reason to think the optimal write() size has
> anything to do with the filesystem's block size.

Even if there is no immediate write, there might be other considerations:
networking filesytems (like Lustre) might need to do extra locking gymnastics
per every syscall (overall syscalls are somewhat expensive, we already touched
on that), if there are conflicting accesses to the file that force lock
revocations, doing writes in large chunks means that cache writeout happens in
larger chunks which helps RPC sizes and disk backend loads.

"Legacy" filesystems that don't have delayed block allocation might use write
size as a gauge of how big of a block of free space to find on disk so that the
file is less fragmented (and to reduce block allocator overhead and metadata
updates overhead) - we certainly did this back in reiserfs days.

-- 
You are receiving this mail because:
You are on the CC list for the bug.