Something like everything, but nothing is really like anything... The development of anything comes from everything under Windows. It is dedicated to providing Linux users with a lightning-fast file name search function and offline search. It turns out that there is a similar rlocate program in Linux, but the program is a bit too old, and it is not difficult to rewrite a better one, so I rewrote one. On the processor, we hope that this tool can cover x86, Godson and Shenwei platforms. Of course, the more platforms, the better. See docs/end_user_tester.md for specific usage tests, docs/app_developer.md for application developers, docs/lib_developer.md for library developers, and docs/design_considerations.md for design considerations. Compile Enter the root directory, directly make can compile and generate the corresponding kernel module and user mode program. Compiling all programs requires installing make and gcc. Compiling kernel modules requires installing kernel header files. There is no additional dependency on compiling user-space programs. The compiled kernel module is named vfs_monitor.ko (using the -O3 parameter optimization), in the kernelmod directory. The compiled user-space shared library is located in the library/bin directory, which is divided into debug version (debug/libanything.so) and release version (release/libanything.so). The compiled user-mode command line test program is located in the cli/bin directory. It is divided into debug version (debug/anything_cli) and release version (release/anything_cli). The kernel module is located in the kernelmod directory, the user state shared library is located in the library directory, and the command line test program is located in the cli directory. Currently, user-mode programs support all platforms, and kernel modules only support x86 and Loongson platforms for the time being. Of course, you can also go to each directory to execute make to build the module, but because the test program in cli depends on the dynamic library in the library, you need to build the library first, then build the cli. In the runtime environment, the kernel module needs to rely on the kernel's CONFIG_KPROBES option, and the user-space program only depends on the glibc library. Compared To illustrate the characteristics of anything, let's start with a simple but still typical file search comparison test. First explain the test environment, the test environment physical machine is ThinkPad x230, 8G memory, mechanical hard disk. The virtual machine is Deepin 15.4 running in VirtualBox, the memory is 2G, and the processor is single core 2.9 GHz. After the file system of the virtual machine excludes /sys, /proc, /dev, and /run directories, there are about 387,000 directories, links, and files. A file system outside the virtual machine is mounted to facilitate file exchange. This file system type is vboxsf, with approximately 115,000 files and directories. The test method is as follows: Use sysctl -w vm.drop_caches=3 to clear the cache, then run find / -name "*hellfire*, which takes about 39.9 seconds Run the find / -name "*hellfire* again with the cache, which takes about 10.1 seconds. By running the free command and comparing the cache entries, the new file cache is about 260MB. Searching for hellfire using the basic index of anything takes about 6 milliseconds, the underlying index takes up about 7MB of memory, and the test program takes up about 14MB of memory. Searching for hellfire using the second-level index of anything takes 0 milliseconds, the secondary index takes up about 230MB of memory, and the test program takes up about 500MB of memory. In fact, the results of multiple tests show that using the underlying index is about 500 times faster or more than using a find search with a cache. If you use a full-memory secondary index, the search speed of the context is more than 20 times faster than the basic index search speed, but the memory usage will increase by 35 times. If the secondary index is stored on the disk, its memory usage will be reduced to near zero. In most cases, it can still achieve a good search speed, still faster than the basic index, but more in the original string. In this case, because it needs to read a larger amount of data from the index file, it will appear to be slower than the basic index search. This is a typical time space complexity interchange problem.