-
-
Replying to @rygorous
@rygorous@Jonathan_Blow Actually the part I was talking about was the "we achieved 1 physical IO per image served".2 replies 0 retweets 0 likes -
Replying to @cmuratori
@cmuratori Well, depending on number of images, number of requests and their distribution, this could be either good or very bad. :)1 reply 0 retweets 0 likes -
Replying to @rygorous
@cmuratori Like for a static site that's really bad obviously, but for say some random image somebody linked on their Facebook feed, sure!1 reply 0 retweets 0 likes -
Replying to @rygorous
@cmuratori In that case, baked PAKs + metadata in RAM is better than a real FS filename lookup (which is likely to trigger its own IO).1 reply 0 retweets 0 likes -
Replying to @rygorous
@rygorous I'm just saying he's talking about optimizing physical IO, _but then they didn't do that_. Eg., https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Beaver.pdf …2 replies 0 retweets 0 likes -
Replying to @cmuratori
@cmuratori Erm, that's exactly what I just described though. PAK-file style layout (just name+offs+size, linear) with metadata cached in RAM2 replies 0 retweets 0 likes -
Replying to @rygorous
@cmuratori So now the kernel, instead of having to cache (large) dirents and inodes for tons of small files, just needs to cache...1 reply 0 retweets 0 likes -
Replying to @rygorous
@cmuratori inodes for one file, and the metadata is more compact and stays in RAM.1 reply 0 retweets 0 likes
@cmuratori @rygorous (or perhaps I should say, "contiguous file")
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.