On Thu, Jan 20, 2022 at 08:05:14AM -0700, Kevin Locke wrote: > It turns out this the failure was due to a network issue which > prevented contacting the host for the CIFS mount on /mnt. However, > this presents several issues that might be worth addressing: > > 1. The error message contains the parent directory, rather than the > directory which could not be read, which makes the error harder to > diagnose.
This is a real bug, and should be easy to fix. > 2. The error occurred on a CIFS filesystem, which is excluded by > PRUNEFS in /etc/updatedb.conf. Presumably it should be skipped > rather than causing an error. The problem is that updatedb doesn't really know for sure it entered a new filesystem until it's stat-ed the directory. This is logic that's inherited from mlocate, and I guess it would be possible to rewrite it in theory, but such changes tend to be at great peril :-) So what's happening is basically that it stats the directory, checks if is device number is different from the parent, and if so, checks the filesystem from /proc/mounts. You can't just scan it once at the start and be done with it, because someone could be mounting new paths while you're doing updatedb (remember, updatedb can take hours), so you'd need a way to deal with new mounts appearing. (I already have complaints it doesn't immediately skip out if someone _unmounts_ something it's in the process of scanning!) The bind mount code has some special checks for this, since it cannot rely on st_dev (there's a separate thread waiting for changes to mountinfo), but it's fundamentally racy. > 3. updatedb immediately aborts, rather than updating the database for > the rest of the filesystem. In this case, since the failing mount > was at the root, the entire tree is skipped. I don't honestly think this is a bug. If updatedb goes wrong for whatever reason, it's not good to just silently discard parts of the database. If nothing else, the next rescan could become very expensive. /* Steinar */ -- Homepage: https://www.sesse.net/
