@cmuratori Erm, that's exactly what I just described though. PAK-file style layout (just name+offs+size, linear) with metadata cached in RAM
-
-
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 -
Replying to @cmuratori
@cmuratori@rygorous In fact it may actually be impossible if you can't cap the image size, etc.1 reply 0 retweets 0 likes
@cmuratori @rygorous But certainly you _could_ get close to that by _actually writing a filesystem_.
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.