Nathan Grennan napsal(a): > I would say as expected the focus is too much in the gritty > programming details, and not the big picture which tends to be a common > problem. Sometimes it turns out the great "big picture" is unimplementable because of a "gritty programing detail" :) > It sounds like someone still needs to write a inotify version of > locate. I have no problem with a light weight daemon that would just > reindex the locate database based on information feed to it by the > kernel via inotify. I'm not an inotify expert, nevertheless I think there are two "gritty programming details" to solve. First, inotify doesn't work over network filesystems, so it isn't possible to guarantee instantaneous update in general, and a periodic scan is necessary anyway. Second, inodes of all watched directories have to be kept in memory; on my laptop that would be roughly 16000 inodes, which is about 10 MB of memory wasted for locate; consider a file server with a few terabytes of storage. (To prevent this pinning of kernel memory, inotify has a configurable limit on the number of watches, which is 8192 by default.) > It would be an almost instantaneous replacement for > both find and locate. No, find(1) is specified by SUSv3, which explicitly states "The find utility shall recursively descend the directory hierarchy...". Because other programs can detect whether find(1) was traversing the subtree, we can't optimize it out. > where as most of the time you just need > to find the file by name, especially as root. In my experience the file is not moving in these cases, but that's of course not a statistically relevant sample. Mirek -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
