Linux file write patterns: So you want to write to a file fast
1–10 of 53 posts
Re: Linux file write patterns: So you want to write to a file fast
#2A bit surprising (considering he started off talking about coredumps) that he doesn't mention sparse files. Core dumps can be very sparse, and you might save time and definitely will save space by not writing out the all-zeroes parts.
Re: Linux file write patterns: So you want to write to a file fast
#3The first hit for "SSD write speeds" says ~500Mb/s (I hope I got the right b). I didn't bother clicking the links that just the blurb under it. He's dumping 128Mb in ~200 ms. I'm not sure there is much room for improvement.
Re: Linux file write patterns: So you want to write to a file fast
#4I would assume the encryption is such a big overhead that most optimizations in the upper levels will be useless.
Re: Linux file write patterns: So you want to write to a file fast
#5Am I correct in noting that none of his benchmarks actually timed how long it took for the data to be durably committed to disk, to the limit that the OS can report that?
I would never do XFS benchmarks because in my experience if XFS is writing during powerdown, it trashses the FS (maybe this was fixed in the past 6 years, but after it happened 3 times I haven't touched the OS again).
Re: Linux file write patterns: So you want to write to a file fast
#6Assuming all I/O failures are EINTR is really, really odd, as if to say disks never fill up or fail and sockets never disconnect.
He does say:
> in a real program you’d have to do real error handling instead of assertions, of course
But somebody somewhere is reading this and thinking this is a "semantically correct pattern" (as it is introduced) and may just copy-paste it into their program. Especially when contrasting it with a "wrong way" I think it wouldn't hurt to include real error handling. And that means something that doesn't fall into an infinite loop when the disk fills up.
Re: Linux file write patterns: So you want to write to a file fast
#7Am I correct in noting that none of his benchmarks actually timed how long it took for the data to be durably committed to disk, to the limit that the OS can report that? I would never do XFS benchmarks because in my experience if XFS is writing during powerdown, it trashses the FS (maybe this was fixed in the past 6 years, but after it happened 3 times I haven't touched the OS again).
One of the most catastrophical failure modes of XFS was fixed in 2007 [0]. Or at least that's what is said. I never dared touch XFS again after losing a fs to it, so I can't really confirm what it looks like today.
[0] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
Re: Linux file write patterns: So you want to write to a file fast
#8I would assume the encryption is such a big overhead that most optimizations in the upper levels will be useless.
The Intel AES instructions help a lot. According to Wikipedia we use 3.5 cycles/byte. That gives us 128*3.5/3 = 149 ms. If the write speed is around 500mb/a as another potter stated, then the disk encryption is probably not a bottleneck. Still, it is better to actually measure the performance without encryption to see if there is any effect.
Re: Linux file write patterns: So you want to write to a file fast
#9actually since none of its tests ask to sync the data onto the disk, he might just be measuring each method efficiency in creating dirty pages.
of course that depends on the amount of RAM the system has, and how the kernel VM parameters are tuned (sysctl vm.dirty_*)
just add a fdatasync() call and you will take into account the time it takes to flush all dirty pages into the disk.
Re: Linux file write patterns: So you want to write to a file fast
#10A bit surprising (considering he started off talking about coredumps) that he doesn't mention sparse files. Core dumps can be very sparse, and you might save time and definitely will save space by not writing out the all-zeroes parts.
to do that, wouldn't you have to look at every byte just to detect the runs of 0s, that would mean that you have to pull the whole file through the memory hierarchy of your system (rather than just passing chunks from syscall to syscall) wouldn't that alone slow you down significantly?