3 ms·
> preferably sort its stat()s and open/read/close() by inode A better approach would be to use information about location of data extents. Luckily there's alre
by vthriller 5y ago
> preferably sort its stat()s and open/read/close() by inode
A better approach would be to use information about location of data extents. Luckily there's already a crate that can help with that: https://github.com/the8472/platter-walk https://github.com/the8472/platter-walk
- formerly_proven 5y agoThat's better for reading the data, but doesn't work for ordering stat()s because looking up extent information requires reading the inode, but that's what we're trying to make linear-ish at that point.
- the8472 5y agoyou can optimize for both. obtain directory entries, sort by inode, do a batch stat (ideally via io_uring) and fiemap and then sort again by extent order. And if you only need the `d_type` instead of the full stat struct, then you get that for free from getdents(2) on some filesystems, this is what platter_walk does.