@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 …
-
-
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 @cmuratori
@cmuratori Trusting on underlying FS to not fragment data unduly, especially with an append-only use case, does not seem very dubious?2 replies 0 retweets 0 likes -
Replying to @cmuratori
@cmuratori The only thing that traverses is the inode + allocation blocks/extent tree though.1 reply 0 retweets 0 likes -
Replying to @rygorous
@cmuratori For separate files you have a lot of wasted space in the kernel memory cache there, for PAK files you don't.1 reply 0 retweets 0 likes -
Replying to @rygorous
@cmuratori That's not exactly controversial; "FS caching of 1000s of small files doesn't work great" is one of the reasons games use PAKs!1 reply 0 retweets 0 likes -
Replying to @cmuratori
@cmuratori@rygorous I'm just talking about the fact that if you want to ensure "1 physical IO per image", then that's very hard to do.2 replies 0 retweets 0 likes
@cmuratori @rygorous In fact it may actually be impossible if you can't cap the image size, etc.
-
-
Replying to @cmuratori
@cmuratori@rygorous But certainly you _could_ get close to that by _actually writing a filesystem_.0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.