Yes, that. And what about network file systems or removable drives, which were just plugged in? Can't expect all that stuff to be cached.
But even for local storage, I doubt that metadata for the entire volume is cached in RAM at all times. On Wed, Nov 13, 2013 at 3:21 PM, David Rajchenbach-Teller < dtel...@mozilla.com> wrote: > On Thu Nov 14 00:10:27 2013, Daniel Micay wrote: > >> The only problem is that Linux doesn't really support asynchronously > >> resolving file paths to inodes (aka opening files), but that can be > done on > >> a dedicated thread pool, with the advantage that the threads don't do > >> anything, so they don't have zombie stacks. > > > > The file metadata cache is small enough that there's no point in > > considering it blocking. You might as well considering memory accesses > > blocking at that extreme, because they might require fetching memory > > to the CPU cache. > > Are you sure about that? If my memory serves, you still need to fetch it > from disk in most cases. On platforms in which devices have a mechanical > component, even trivial accesses can end up very expensive in case of > disk thrashing and/or sleeping disk. > > Cheers, > David > > -- > David Rajchenbach-Teller, PhD > Performance Team, Mozilla > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
