Slow in directory mounted to container after working from 1 side, then the other

[Steve Jorgensen (Dark Orb)]

I have a directory that is mounted in a container. If I do any work in the directory in the container, the next time I run ack outside the container, it is slow. The reverse is also true.

I assume what's happening is that ack has some kind of cache that gets busted somehow when changes are made from another system?

Does anyone know why this happens and if there is some way to improve the situation?

Whatever this is, I know it's not exclusive to ack because I have the same issue with git status -- if that helps.

[Bill Ricker]

The caching is all at the OS Filesystem level, same as the mounting into the container.

Within either the host or a container OS image, repeat use of the same files is fast. But uncached files will take longer.

Whether the container virtualization adds an extra penalty for locking ... e.g., requiring that buffered writes by other images sharing the same filesystem be completed before use on the other side ... i don't know but is certainly plausible.

[Steve Jorgensen (Dark Orb)]

In the case of Git, it seems to be that git copies cached metadata into its index, and if that metadata changes, and when that data changes, it assumes every file has been modified. I assume that index is stored in the .git/ subdirectory of the project, so simply looking at it from one side after it has been written on the other, it will look like all files have changed. I still suspect something similar with ack, based on the behavior I see. I guess I'll have to dig inti the ack source code to find out for sure (unless you already know for certain that I'm wrong).

Part of the answer I got from AI regarding that situation in for Git:

When you run git status, Git optimizes performance by reading cached file metadata (like inode numbers, device IDs, modifications times mtime, and change times ctime) stored in its index. It compares these cached values against the real file system to see if anything changed.

However, your host and container see different information for the exact same file:
* node & Device ID Mismatch: The virtual layer (e.g., Docker Desktop, gRPC-FUSE, VirtioFS, or WSL2 gvfs) generates entirely different file system IDs inside the container compared to the host.
* Timestamp Shifts: Slight shifts or unsupported precision formats in ctime (inode change time) frequently occur across the mount boundaries.

Every time you switch contexts, Git realizes the metadata doesn't match the index. It assumes every single file has been modified. It forcedly reads and parses every single file content on disk to verify changes, tanking your performance. Running git status a second consecutive time fixes it temporarily because that side re-writes the index with its own metadata format. 

[Bill Ricker]

On Mon, Jul 13, 2026 at 10:05 PM Steve Jorgensen (Dark Orb) <stev...@gmail.com> wrote:

On Monday, July 13, 2026 at 3:43:11 PM UTC-7 bill....@gmail.com wrote:

In the case of Git, it seems to be that git copies cached metadata into its index, and if that metadata changes, and when that data changes, it assumes every file has been modified. I assume that index is stored in the .git/ subdirectory of the project, so simply looking at it from one side after it has been written on the other, it will look like all files have changed.

Git does caching, but it doesn't fully trust metadata, it works on hashes of the files, which means reprocessing them whenever they might have changed.

I still suspect something similar with ack, based on the behavior I see.

Nope. Very different under the hood.

I guess I'll have to dig inti the ack source code to find out for sure (unless you already know for certain that I'm wrong).

I am quite familiar with the Ack source code. (I've been bug-fixing lately.)

It uses OS Filesystem caching only, and doesn't care about timestamps. At all.

No secret meta-data cache.

(Andy and I contemplated the tradeoffs of hypothetically having a pre-scan mode to collect meta-data and keywords ala CTAGS for performance. This present discussion is a demonstration why that would cause more obscure problems than it solves.)

If you are seeing caching favoring host over container and vice versa alternating, this suggests your host is releasing it's FS Cache when the container gets busy and vice versa. Which paradoxically may be beneficial.

 OS FS caching is generally well understood. Some small but significant % of RAM is used for filesystem block shadowing, on the assumption that recent files read or written may get read or written again soon. These are discarded on the LRU algorithm, to be re-used either for a different file block from the next read/write, or because some process requests more RAM.  A happy POSIX system has most of its free memory full of quite a history of read (& written) file blocks [including inode etc. but data too] and very little in fully "free" state [ready to be assigned in interrupt level].

Starting a Container likely burns through much of the cached block space in the process of reserving RAM for the container and reading/populating the container image. Whether the Container's FS cache is shared with the Host FS cache depends on how heavy or light weight a Container implementation is, I would guess. For lightweight, one might expect the Container FS to be a thin alias layer over the host OS FS, so that cache would be shared. For heavyweight, they may have to flush each other's caches in order to avoid inconsistencies.

Ack is not performance optimized; it provides a pure-Perl file-type-aware-DWIM interactive enhancement for programmers doing maintenance/reverse-engineering; and guarantees that the Perl RegEx syntax is exactly what your current running Perl has, an advantage for those of us living on the bleading edge (and changeable by 'perlbrew switch').  With a reasonable size code tree on a solid-state drive or with FS caching already primed, Ack doesn't need more caching than OS filesystem caching for acceptable human interactive performance.

  [If you didn't upgrade to NVME 'disks' before the AI bubble sent prices through the roof, I'm so sorry. It is possible to configure a small NVME as cache for a larger spinning rust drive ... which is even built into some modern rust drives.]

   [I have some subtrees that try my patience with Ack, but they're absurd, and that's on me! But finger-memory is strong, so I don't switch to a faster equivalent tool; when I need something else, I have a retrieval index (swish-e swish-search) that does intensive indexing. But that's offlabel uses of both tools.]

 
For performance critical uses, good old GNUutils grep (with -P 'PerlRE' nowadays) is hard to beat, and to be preferred if the Container is an automation.

[AFAIK *BSD (incl.Mac) grep doesn't have -P, they keep it in a separate pcregrep command; and likely BusyBox doesn't at all.
Canonical's uutils Rust reimplementation has -P already :wow: .]

There are several other projects inspired by Ack (on the More Tools [https://beyondgrep.com/more-tools/] and Comparison [https://beyondgrep.com/feature-comparison/] tabs of the website) that are quite fast and nearly as Perl compatible in their PCRE RegExes as Ack, if speed is what you need. Imitation is the sincerest form of flattery, we consider them friends and are happy to recommend them when Ack's lack of performance becomes a factor for someone.

Part of the answer I got from AI

:eyeroll:   if you must use the AI-augmented search, do click through to the original documents identified, to see if they actually say the thing AI thinks they said, and if they say anything else.

(And distrust anything from conversational agentic fabricators.)

* Timestamp Shifts: Slight shifts or unsupported precision formats in ctime (inode change time) frequently occur across the mount boundaries.

This latter applies more broadly than GIT and mount-boundaries, even to between syncronized filesystems supposedly with replication of ctime.

Certain files rsync needlessly for me until they get a new ctime, when the laptop, desktop, archive volume(s) have different OS, FS versions.

[which is much of the time, as I don't upgrade all devices at once! and certain of those files don't update often ... ]

[Steve Jorgensen (Dark Orb)]

Thank you very much for that detailed explanation. I appreciate it.