On Nov 13, 2013, at 3:56 PM, Daniel Micay <danielmi...@gmail.com> wrote:
> On Wed, Nov 13, 2013 at 6: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
>
> Mechanical disks are already dead in mobile though, and will be dead
> elsewhere by the time Rust is widely used.
In consumer devices, perhaps. But in large data arrays, probably not so much.
Also, don’t forget that there’s more to a filesystem than just local drives.
What about network-mounted filesystems?
> It's normal for all of the metadata to remain in cache, but obviously not
> page cache. Either way,
> Linux doesn't expose non-blocking file primitives and (fast) AIO is
> only a dream at this point. The glibc implementation of POSIX AIO uses
> threads and blocking I/O.
Does “all of the metadata” mean everything that stat() returns, or are you
talking about a limited subset here? Because if it’s the former, then I’m
pretty sure all stat metadata for the filesystem does not necessarily reside in
cache at the same time. This should be obvious for anyone who’s used a VCS with
a gigantic project, and waited for it to stat() all the files to see if they
changed.
And this is doubly-true for network filesystems.
-Kevin
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
