2020-10-16 00:36:20 +02:00
|
|
|
#include "access_rx_cache.h"
|
2020-11-22 21:28:57 +01:00
|
|
|
#include "complete_pread.h"
|
2020-10-09 10:06:00 +02:00
|
|
|
#include "db.h"
|
2020-10-11 19:09:18 +02:00
|
|
|
#include "dprintf.h"
|
2020-10-09 10:06:00 +02:00
|
|
|
#include "io_uring_engine.h"
|
2020-10-16 00:42:25 +02:00
|
|
|
#include "needle.h"
|
2020-10-10 11:36:17 +02:00
|
|
|
#include "parse_trigrams.h"
|
2020-10-16 00:22:59 +02:00
|
|
|
#include "serializer.h"
|
2020-10-10 21:26:30 +02:00
|
|
|
#include "turbopfor.h"
|
2020-10-10 10:35:41 +02:00
|
|
|
#include "unique_sort.h"
|
2020-10-09 10:06:00 +02:00
|
|
|
|
2020-10-09 00:09:33 +02:00
|
|
|
#include <algorithm>
|
2020-10-10 11:36:17 +02:00
|
|
|
#include <assert.h>
|
2020-10-16 00:22:59 +02:00
|
|
|
#include <atomic>
|
2020-10-09 00:09:33 +02:00
|
|
|
#include <chrono>
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
#include <condition_variable>
|
2020-10-16 00:22:59 +02:00
|
|
|
#include <deque>
|
2020-10-09 10:06:00 +02:00
|
|
|
#include <fcntl.h>
|
2020-10-09 00:09:33 +02:00
|
|
|
#include <functional>
|
2020-10-09 10:06:00 +02:00
|
|
|
#include <getopt.h>
|
2020-10-11 19:57:20 +02:00
|
|
|
#include <inttypes.h>
|
2020-10-09 00:09:33 +02:00
|
|
|
#include <iterator>
|
|
|
|
#include <limits>
|
2020-10-16 00:22:59 +02:00
|
|
|
#include <locale.h>
|
2020-10-09 10:06:00 +02:00
|
|
|
#include <memory>
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
#include <mutex>
|
2020-10-10 11:36:17 +02:00
|
|
|
#include <regex.h>
|
2020-10-16 00:23:11 +02:00
|
|
|
#include <stdint.h>
|
2020-10-09 10:06:00 +02:00
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <string.h>
|
|
|
|
#include <string>
|
2020-10-09 00:09:33 +02:00
|
|
|
#include <string_view>
|
2021-08-23 10:07:01 +02:00
|
|
|
#include <sys/stat.h>
|
2021-03-28 00:19:49 +01:00
|
|
|
#include <sys/types.h>
|
|
|
|
#include <sys/wait.h>
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
#include <thread>
|
2020-10-16 00:22:59 +02:00
|
|
|
#include <tuple>
|
2020-10-09 10:06:00 +02:00
|
|
|
#include <unistd.h>
|
|
|
|
#include <unordered_map>
|
2020-10-10 11:36:17 +02:00
|
|
|
#include <unordered_set>
|
2020-10-09 00:09:33 +02:00
|
|
|
#include <utility>
|
2020-10-09 10:06:00 +02:00
|
|
|
#include <vector>
|
|
|
|
#include <zstd.h>
|
2020-09-27 22:53:35 +02:00
|
|
|
|
|
|
|
using namespace std;
|
|
|
|
using namespace std::chrono;
|
|
|
|
|
2020-10-10 11:36:17 +02:00
|
|
|
bool ignore_case = false;
|
2020-10-08 20:05:41 +02:00
|
|
|
bool only_count = false;
|
2020-09-30 23:59:14 +02:00
|
|
|
bool print_nul = false;
|
2020-10-10 19:30:13 +02:00
|
|
|
bool use_debug = false;
|
2020-10-16 00:48:23 +02:00
|
|
|
bool flush_cache = false;
|
2020-10-10 21:43:20 +02:00
|
|
|
bool patterns_are_regex = false;
|
|
|
|
bool use_extended_regex = false;
|
2020-10-17 09:46:55 +02:00
|
|
|
bool match_basename = false;
|
2021-07-27 16:19:01 +02:00
|
|
|
bool check_existence = false;
|
2023-12-31 11:29:43 +01:00
|
|
|
bool ignore_visibility = false;
|
2020-10-08 22:35:28 +02:00
|
|
|
int64_t limit_matches = numeric_limits<int64_t>::max();
|
Do the access checking asynchronously if possible.
There are many issues involved:
- There's no access() support in io_uring (yet?), so we fake it
by doing statx() on the directory first, which primes the
dentry cache so that synchronous access() becomes very fast.
It is a bit tricky, since multiple access checks could be
going on at the same time, which the need to all wait
for the same statx() call.
- Not even all kernels support statx() in io_uring (support starts
from 5.6+).
- Serialization now becomes two-level, and more involved.
We don't have an obvious single counter anymore, so we need
to be able to start a docid without knowing how many candidates
there are (and thus, be able to tell Serializer that we are
at the end).
- Limit becomes more tricky, since there can be more calls on
the way back. We solve this by moving limit into Serializer,
and hard-exiting when we hit the limit.
- We need to prioritize statx() calls ahead of read(), so that
we don't end up with very delayed output when the new read()
calls generate even more statx() calls and we get a huge
backlog of calls. (We can't prioritize in the kernel, but we
can on the overflow queue we're managing ourselves.) This is
especially important with --limit.
2020-10-11 19:59:11 +02:00
|
|
|
int64_t limit_left = numeric_limits<int64_t>::max();
|
2020-10-29 23:42:01 +01:00
|
|
|
bool stdout_is_tty = false;
|
2021-10-05 23:02:09 +02:00
|
|
|
bool literal_printing = false;
|
2021-03-28 00:19:49 +01:00
|
|
|
static bool in_forked_child = false;
|
Do the access checking asynchronously if possible.
There are many issues involved:
- There's no access() support in io_uring (yet?), so we fake it
by doing statx() on the directory first, which primes the
dentry cache so that synchronous access() becomes very fast.
It is a bit tricky, since multiple access checks could be
going on at the same time, which the need to all wait
for the same statx() call.
- Not even all kernels support statx() in io_uring (support starts
from 5.6+).
- Serialization now becomes two-level, and more involved.
We don't have an obvious single counter anymore, so we need
to be able to start a docid without knowing how many candidates
there are (and thus, be able to tell Serializer that we are
at the end).
- Limit becomes more tricky, since there can be more calls on
the way back. We solve this by moving limit into Serializer,
and hard-exiting when we hit the limit.
- We need to prioritize statx() calls ahead of read(), so that
we don't end up with very delayed output when the new read()
calls generate even more statx() calls and we get a huge
backlog of calls. (We can't prioritize in the kernel, but we
can on the overflow queue we're managing ourselves.) This is
especially important with --limit.
2020-10-11 19:59:11 +02:00
|
|
|
|
|
|
|
steady_clock::time_point start;
|
Use zstd dictionaries.
Since we have small strings, they can benefit from some shared context,
and zstd supports this. plocate-build now reads the mlocate database
twice; the first pass samples 1000 random blocks, which it uses to train
a 1 kB dictionary. (zstd recommends much larger dictionaries, but practical
testing seems to indicate this doesn't help us much, and might actually
be harmful.)
We get ~20% slower builds and ~7% smaller .db files -- but more
interestingly, linear search speed is up ~20% (which indicates that
decompression in itself benefits more). We need to read the 1 kB
dictionary, but it's practically free since it's stored next to the
header and so small.
This is a version bump (to version 1), so we're not forward-compatible,
but we're backward-compatible (plocate still reads version 0 files
just fine). Since we're adding more fields to the header anyway,
we can add a new “max_version” field that allows for marking
backwards-compatible changes in the future, ie., if plocate-build
adds more information that plocate would like to use but that older
plocate versions can simply ignore.
2020-10-13 17:46:20 +02:00
|
|
|
ZSTD_DDict *ddict = nullptr;
|
Do the access checking asynchronously if possible.
There are many issues involved:
- There's no access() support in io_uring (yet?), so we fake it
by doing statx() on the directory first, which primes the
dentry cache so that synchronous access() becomes very fast.
It is a bit tricky, since multiple access checks could be
going on at the same time, which the need to all wait
for the same statx() call.
- Not even all kernels support statx() in io_uring (support starts
from 5.6+).
- Serialization now becomes two-level, and more involved.
We don't have an obvious single counter anymore, so we need
to be able to start a docid without knowing how many candidates
there are (and thus, be able to tell Serializer that we are
at the end).
- Limit becomes more tricky, since there can be more calls on
the way back. We solve this by moving limit into Serializer,
and hard-exiting when we hit the limit.
- We need to prioritize statx() calls ahead of read(), so that
we don't end up with very delayed output when the new read()
calls generate even more statx() calls and we get a huge
backlog of calls. (We can't prioritize in the kernel, but we
can on the overflow queue we're managing ourselves.) This is
especially important with --limit.
2020-10-11 19:59:11 +02:00
|
|
|
|
2020-09-29 00:10:02 +02:00
|
|
|
class Corpus {
|
|
|
|
public:
|
2021-10-18 09:42:00 +02:00
|
|
|
Corpus(int fd, const char *filename_for_errors, IOUringEngine *engine);
|
2020-09-29 00:10:02 +02:00
|
|
|
~Corpus();
|
2020-09-30 10:20:10 +02:00
|
|
|
void find_trigram(uint32_t trgm, function<void(const Trigram *trgmptr, size_t len)> cb);
|
2020-10-08 22:41:41 +02:00
|
|
|
void get_compressed_filename_block(uint32_t docid, function<void(string_view)> cb) const;
|
2020-09-29 00:27:06 +02:00
|
|
|
size_t get_num_filename_blocks() const;
|
2020-09-30 21:52:16 +02:00
|
|
|
off_t offset_for_block(uint32_t docid) const
|
|
|
|
{
|
2020-09-30 19:44:28 +02:00
|
|
|
return hdr.filename_index_offset_bytes + docid * sizeof(uint64_t);
|
2020-09-30 10:20:10 +02:00
|
|
|
}
|
Use zstd dictionaries.
Since we have small strings, they can benefit from some shared context,
and zstd supports this. plocate-build now reads the mlocate database
twice; the first pass samples 1000 random blocks, which it uses to train
a 1 kB dictionary. (zstd recommends much larger dictionaries, but practical
testing seems to indicate this doesn't help us much, and might actually
be harmful.)
We get ~20% slower builds and ~7% smaller .db files -- but more
interestingly, linear search speed is up ~20% (which indicates that
decompression in itself benefits more). We need to read the 1 kB
dictionary, but it's practically free since it's stored next to the
header and so small.
This is a version bump (to version 1), so we're not forward-compatible,
but we're backward-compatible (plocate still reads version 0 files
just fine). Since we're adding more fields to the header anyway,
we can add a new “max_version” field that allows for marking
backwards-compatible changes in the future, ie., if plocate-build
adds more information that plocate would like to use but that older
plocate versions can simply ignore.
2020-10-13 17:46:20 +02:00
|
|
|
const Header &get_hdr() const { return hdr; }
|
2020-09-29 00:10:02 +02:00
|
|
|
|
2020-09-30 10:20:10 +02:00
|
|
|
public:
|
2020-09-29 00:10:02 +02:00
|
|
|
const int fd;
|
2020-09-30 10:20:10 +02:00
|
|
|
IOUringEngine *const engine;
|
|
|
|
|
2020-09-30 19:44:28 +02:00
|
|
|
Header hdr;
|
2020-09-29 00:10:02 +02:00
|
|
|
};
|
|
|
|
|
2021-10-18 09:42:00 +02:00
|
|
|
Corpus::Corpus(int fd, const char *filename_for_errors, IOUringEngine *engine)
|
2020-09-30 10:20:10 +02:00
|
|
|
: fd(fd), engine(engine)
|
2020-09-29 00:10:02 +02:00
|
|
|
{
|
2020-10-16 00:48:23 +02:00
|
|
|
if (flush_cache) {
|
2020-09-30 19:44:28 +02:00
|
|
|
off_t len = lseek(fd, 0, SEEK_END);
|
|
|
|
if (len == -1) {
|
|
|
|
perror("lseek");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
posix_fadvise(fd, 0, len, POSIX_FADV_DONTNEED);
|
2020-09-29 00:10:02 +02:00
|
|
|
}
|
|
|
|
|
2020-09-30 19:44:28 +02:00
|
|
|
complete_pread(fd, &hdr, sizeof(hdr), /*offset=*/0);
|
|
|
|
if (memcmp(hdr.magic, "\0plocate", 8) != 0) {
|
2021-10-18 09:42:00 +02:00
|
|
|
fprintf(stderr, "%s: database is corrupt or not a plocate database; please rebuild it.\n", filename_for_errors);
|
2020-09-30 19:44:28 +02:00
|
|
|
exit(1);
|
|
|
|
}
|
Use zstd dictionaries.
Since we have small strings, they can benefit from some shared context,
and zstd supports this. plocate-build now reads the mlocate database
twice; the first pass samples 1000 random blocks, which it uses to train
a 1 kB dictionary. (zstd recommends much larger dictionaries, but practical
testing seems to indicate this doesn't help us much, and might actually
be harmful.)
We get ~20% slower builds and ~7% smaller .db files -- but more
interestingly, linear search speed is up ~20% (which indicates that
decompression in itself benefits more). We need to read the 1 kB
dictionary, but it's practically free since it's stored next to the
header and so small.
This is a version bump (to version 1), so we're not forward-compatible,
but we're backward-compatible (plocate still reads version 0 files
just fine). Since we're adding more fields to the header anyway,
we can add a new “max_version” field that allows for marking
backwards-compatible changes in the future, ie., if plocate-build
adds more information that plocate would like to use but that older
plocate versions can simply ignore.
2020-10-13 17:46:20 +02:00
|
|
|
if (hdr.version != 0 && hdr.version != 1) {
|
2021-10-18 09:42:00 +02:00
|
|
|
fprintf(stderr, "%s: has version %u, expected 0 or 1; please rebuild it.\n", filename_for_errors, hdr.version);
|
2020-09-30 19:44:28 +02:00
|
|
|
exit(1);
|
|
|
|
}
|
Use zstd dictionaries.
Since we have small strings, they can benefit from some shared context,
and zstd supports this. plocate-build now reads the mlocate database
twice; the first pass samples 1000 random blocks, which it uses to train
a 1 kB dictionary. (zstd recommends much larger dictionaries, but practical
testing seems to indicate this doesn't help us much, and might actually
be harmful.)
We get ~20% slower builds and ~7% smaller .db files -- but more
interestingly, linear search speed is up ~20% (which indicates that
decompression in itself benefits more). We need to read the 1 kB
dictionary, but it's practically free since it's stored next to the
header and so small.
This is a version bump (to version 1), so we're not forward-compatible,
but we're backward-compatible (plocate still reads version 0 files
just fine). Since we're adding more fields to the header anyway,
we can add a new “max_version” field that allows for marking
backwards-compatible changes in the future, ie., if plocate-build
adds more information that plocate would like to use but that older
plocate versions can simply ignore.
2020-10-13 17:46:20 +02:00
|
|
|
if (hdr.version == 0) {
|
|
|
|
// These will be junk data.
|
|
|
|
hdr.zstd_dictionary_offset_bytes = 0;
|
|
|
|
hdr.zstd_dictionary_length_bytes = 0;
|
|
|
|
}
|
2020-11-28 18:17:23 +01:00
|
|
|
if (hdr.max_version < 2) {
|
|
|
|
// This too. (We ignore the other max_version 2 fields.)
|
2020-12-05 10:49:55 +01:00
|
|
|
hdr.check_visibility = true;
|
2020-11-28 18:17:23 +01:00
|
|
|
}
|
2023-12-31 11:29:43 +01:00
|
|
|
if (ignore_visibility) {
|
|
|
|
hdr.check_visibility = false;
|
|
|
|
}
|
2020-09-29 00:10:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
Corpus::~Corpus()
|
|
|
|
{
|
|
|
|
close(fd);
|
|
|
|
}
|
|
|
|
|
2020-09-30 10:20:10 +02:00
|
|
|
void Corpus::find_trigram(uint32_t trgm, function<void(const Trigram *trgmptr, size_t len)> cb)
|
2020-09-29 00:10:02 +02:00
|
|
|
{
|
2020-09-30 19:44:28 +02:00
|
|
|
uint32_t bucket = hash_trigram(trgm, hdr.hashtable_size);
|
2020-10-08 22:41:41 +02:00
|
|
|
engine->submit_read(fd, sizeof(Trigram) * (hdr.extra_ht_slots + 2), hdr.hash_table_offset_bytes + sizeof(Trigram) * bucket, [this, trgm, cb{ move(cb) }](string_view s) {
|
2020-09-30 10:20:10 +02:00
|
|
|
const Trigram *trgmptr = reinterpret_cast<const Trigram *>(s.data());
|
2020-09-30 19:44:28 +02:00
|
|
|
for (unsigned i = 0; i < hdr.extra_ht_slots + 1; ++i) {
|
|
|
|
if (trgmptr[i].trgm == trgm) {
|
|
|
|
cb(trgmptr + i, trgmptr[i + 1].offset - trgmptr[i].offset);
|
|
|
|
return;
|
|
|
|
}
|
2020-09-30 10:20:10 +02:00
|
|
|
}
|
2020-09-30 19:44:28 +02:00
|
|
|
|
|
|
|
// Not found.
|
|
|
|
cb(nullptr, 0);
|
2020-09-30 10:20:10 +02:00
|
|
|
});
|
2020-09-29 00:10:02 +02:00
|
|
|
}
|
|
|
|
|
2020-10-08 22:41:41 +02:00
|
|
|
void Corpus::get_compressed_filename_block(uint32_t docid, function<void(string_view)> cb) const
|
2020-09-28 23:52:46 +02:00
|
|
|
{
|
2020-09-30 10:20:10 +02:00
|
|
|
// Read the file offset from this docid and the next one.
|
|
|
|
// This is always allowed, since we have a sentinel block at the end.
|
2020-10-08 22:41:41 +02:00
|
|
|
engine->submit_read(fd, sizeof(uint64_t) * 2, offset_for_block(docid), [this, cb{ move(cb) }](string_view s) {
|
2020-09-30 10:20:10 +02:00
|
|
|
const uint64_t *ptr = reinterpret_cast<const uint64_t *>(s.data());
|
|
|
|
off_t offset = ptr[0];
|
|
|
|
size_t len = ptr[1] - ptr[0];
|
|
|
|
engine->submit_read(fd, len, offset, cb);
|
|
|
|
});
|
2020-09-29 00:10:02 +02:00
|
|
|
}
|
|
|
|
|
2020-09-29 00:27:06 +02:00
|
|
|
size_t Corpus::get_num_filename_blocks() const
|
|
|
|
{
|
2020-10-03 10:49:10 +02:00
|
|
|
return hdr.num_docids;
|
2020-09-29 00:27:06 +02:00
|
|
|
}
|
|
|
|
|
2021-07-27 16:19:01 +02:00
|
|
|
template<class T>
|
|
|
|
void stat_if_needed(const char *filename, bool access_ok, IOUringEngine *engine, T cb)
|
|
|
|
{
|
|
|
|
if (!access_ok || !check_existence) {
|
|
|
|
// Doesn't have access or doesn't care about existence, so no need to stat.
|
|
|
|
cb(access_ok);
|
|
|
|
} else if (engine == nullptr || !engine->get_supports_stat()) {
|
|
|
|
// Do a synchronous stat.
|
|
|
|
struct stat buf;
|
|
|
|
bool ok = lstat(filename, &buf) == 0;
|
|
|
|
cb(ok);
|
|
|
|
} else {
|
|
|
|
engine->submit_stat(filename, cb);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Do the access checking asynchronously if possible.
There are many issues involved:
- There's no access() support in io_uring (yet?), so we fake it
by doing statx() on the directory first, which primes the
dentry cache so that synchronous access() becomes very fast.
It is a bit tricky, since multiple access checks could be
going on at the same time, which the need to all wait
for the same statx() call.
- Not even all kernels support statx() in io_uring (support starts
from 5.6+).
- Serialization now becomes two-level, and more involved.
We don't have an obvious single counter anymore, so we need
to be able to start a docid without knowing how many candidates
there are (and thus, be able to tell Serializer that we are
at the end).
- Limit becomes more tricky, since there can be more calls on
the way back. We solve this by moving limit into Serializer,
and hard-exiting when we hit the limit.
- We need to prioritize statx() calls ahead of read(), so that
we don't end up with very delayed output when the new read()
calls generate even more statx() calls and we get a huge
backlog of calls. (We can't prioritize in the kernel, but we
can on the overflow queue we're managing ourselves.) This is
especially important with --limit.
2020-10-11 19:59:11 +02:00
|
|
|
void scan_file_block(const vector<Needle> &needles, string_view compressed,
|
2021-07-27 16:19:01 +02:00
|
|
|
IOUringEngine *engine, AccessRXCache *access_rx_cache, uint64_t seq, ResultReceiver *serializer,
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
atomic<uint64_t> *matched)
|
2020-09-29 00:10:02 +02:00
|
|
|
{
|
2020-09-30 19:30:34 +02:00
|
|
|
unsigned long long uncompressed_len = ZSTD_getFrameContentSize(compressed.data(), compressed.size());
|
|
|
|
if (uncompressed_len == ZSTD_CONTENTSIZE_UNKNOWN || uncompressed_len == ZSTD_CONTENTSIZE_ERROR) {
|
|
|
|
fprintf(stderr, "ZSTD_getFrameContentSize() failed\n");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2020-09-28 23:52:46 +02:00
|
|
|
string block;
|
2020-09-30 19:30:34 +02:00
|
|
|
block.resize(uncompressed_len + 1);
|
2020-09-28 23:52:46 +02:00
|
|
|
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
static thread_local ZSTD_DCtx *ctx = ZSTD_createDCtx(); // Reused across calls.
|
Use zstd dictionaries.
Since we have small strings, they can benefit from some shared context,
and zstd supports this. plocate-build now reads the mlocate database
twice; the first pass samples 1000 random blocks, which it uses to train
a 1 kB dictionary. (zstd recommends much larger dictionaries, but practical
testing seems to indicate this doesn't help us much, and might actually
be harmful.)
We get ~20% slower builds and ~7% smaller .db files -- but more
interestingly, linear search speed is up ~20% (which indicates that
decompression in itself benefits more). We need to read the 1 kB
dictionary, but it's practically free since it's stored next to the
header and so small.
This is a version bump (to version 1), so we're not forward-compatible,
but we're backward-compatible (plocate still reads version 0 files
just fine). Since we're adding more fields to the header anyway,
we can add a new “max_version” field that allows for marking
backwards-compatible changes in the future, ie., if plocate-build
adds more information that plocate would like to use but that older
plocate versions can simply ignore.
2020-10-13 17:46:20 +02:00
|
|
|
size_t err;
|
|
|
|
|
|
|
|
if (ddict != nullptr) {
|
|
|
|
err = ZSTD_decompress_usingDDict(ctx, &block[0], block.size(), compressed.data(),
|
|
|
|
compressed.size(), ddict);
|
|
|
|
} else {
|
|
|
|
err = ZSTD_decompressDCtx(ctx, &block[0], block.size(), compressed.data(),
|
|
|
|
compressed.size());
|
|
|
|
}
|
2020-09-30 19:30:34 +02:00
|
|
|
if (ZSTD_isError(err)) {
|
|
|
|
fprintf(stderr, "ZSTD_decompress(): %s\n", ZSTD_getErrorName(err));
|
|
|
|
exit(1);
|
|
|
|
}
|
2020-09-28 23:52:46 +02:00
|
|
|
block[block.size() - 1] = '\0';
|
|
|
|
|
Do the access checking asynchronously if possible.
There are many issues involved:
- There's no access() support in io_uring (yet?), so we fake it
by doing statx() on the directory first, which primes the
dentry cache so that synchronous access() becomes very fast.
It is a bit tricky, since multiple access checks could be
going on at the same time, which the need to all wait
for the same statx() call.
- Not even all kernels support statx() in io_uring (support starts
from 5.6+).
- Serialization now becomes two-level, and more involved.
We don't have an obvious single counter anymore, so we need
to be able to start a docid without knowing how many candidates
there are (and thus, be able to tell Serializer that we are
at the end).
- Limit becomes more tricky, since there can be more calls on
the way back. We solve this by moving limit into Serializer,
and hard-exiting when we hit the limit.
- We need to prioritize statx() calls ahead of read(), so that
we don't end up with very delayed output when the new read()
calls generate even more statx() calls and we get a huge
backlog of calls. (We can't prioritize in the kernel, but we
can on the overflow queue we're managing ourselves.) This is
especially important with --limit.
2020-10-11 19:59:11 +02:00
|
|
|
auto test_candidate = [&](const char *filename, uint64_t local_seq, uint64_t next_seq) {
|
2021-07-27 16:19:01 +02:00
|
|
|
access_rx_cache->check_access(filename, /*allow_async=*/true, [matched, engine, serializer, local_seq, next_seq, filename{ strdup(filename) }](bool ok) {
|
|
|
|
stat_if_needed(filename, ok, engine, [matched, serializer, local_seq, next_seq, filename](bool ok) {
|
|
|
|
if (ok) {
|
|
|
|
++*matched;
|
|
|
|
serializer->print(local_seq, next_seq - local_seq, filename);
|
|
|
|
} else {
|
|
|
|
serializer->print(local_seq, next_seq - local_seq, "");
|
|
|
|
}
|
|
|
|
free(filename);
|
|
|
|
});
|
Do the access checking asynchronously if possible.
There are many issues involved:
- There's no access() support in io_uring (yet?), so we fake it
by doing statx() on the directory first, which primes the
dentry cache so that synchronous access() becomes very fast.
It is a bit tricky, since multiple access checks could be
going on at the same time, which the need to all wait
for the same statx() call.
- Not even all kernels support statx() in io_uring (support starts
from 5.6+).
- Serialization now becomes two-level, and more involved.
We don't have an obvious single counter anymore, so we need
to be able to start a docid without knowing how many candidates
there are (and thus, be able to tell Serializer that we are
at the end).
- Limit becomes more tricky, since there can be more calls on
the way back. We solve this by moving limit into Serializer,
and hard-exiting when we hit the limit.
- We need to prioritize statx() calls ahead of read(), so that
we don't end up with very delayed output when the new read()
calls generate even more statx() calls and we get a huge
backlog of calls. (We can't prioritize in the kernel, but we
can on the overflow queue we're managing ourselves.) This is
especially important with --limit.
2020-10-11 19:59:11 +02:00
|
|
|
});
|
|
|
|
};
|
|
|
|
|
|
|
|
// We need to know the next sequence number before inserting into Serializer,
|
|
|
|
// so always buffer one candidate.
|
|
|
|
const char *pending_candidate = nullptr;
|
2020-10-01 10:16:31 +02:00
|
|
|
|
Do the access checking asynchronously if possible.
There are many issues involved:
- There's no access() support in io_uring (yet?), so we fake it
by doing statx() on the directory first, which primes the
dentry cache so that synchronous access() becomes very fast.
It is a bit tricky, since multiple access checks could be
going on at the same time, which the need to all wait
for the same statx() call.
- Not even all kernels support statx() in io_uring (support starts
from 5.6+).
- Serialization now becomes two-level, and more involved.
We don't have an obvious single counter anymore, so we need
to be able to start a docid without knowing how many candidates
there are (and thus, be able to tell Serializer that we are
at the end).
- Limit becomes more tricky, since there can be more calls on
the way back. We solve this by moving limit into Serializer,
and hard-exiting when we hit the limit.
- We need to prioritize statx() calls ahead of read(), so that
we don't end up with very delayed output when the new read()
calls generate even more statx() calls and we get a huge
backlog of calls. (We can't prioritize in the kernel, but we
can on the overflow queue we're managing ourselves.) This is
especially important with --limit.
2020-10-11 19:59:11 +02:00
|
|
|
uint64_t local_seq = seq << 32;
|
2020-09-28 23:52:46 +02:00
|
|
|
for (const char *filename = block.data();
|
2020-09-29 00:13:18 +02:00
|
|
|
filename != block.data() + block.size();
|
|
|
|
filename += strlen(filename) + 1) {
|
2020-10-17 09:46:55 +02:00
|
|
|
const char *haystack = filename;
|
|
|
|
if (match_basename) {
|
|
|
|
haystack = strrchr(filename, '/');
|
|
|
|
if (haystack == nullptr) {
|
|
|
|
haystack = filename;
|
|
|
|
} else {
|
|
|
|
++haystack;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-09-30 23:57:02 +02:00
|
|
|
bool found = true;
|
2020-10-10 11:36:17 +02:00
|
|
|
for (const Needle &needle : needles) {
|
2020-10-17 09:46:55 +02:00
|
|
|
if (!matches(needle, haystack)) {
|
2020-09-30 23:57:02 +02:00
|
|
|
found = false;
|
|
|
|
break;
|
|
|
|
}
|
2020-09-28 23:52:46 +02:00
|
|
|
}
|
Do the access checking asynchronously if possible.
There are many issues involved:
- There's no access() support in io_uring (yet?), so we fake it
by doing statx() on the directory first, which primes the
dentry cache so that synchronous access() becomes very fast.
It is a bit tricky, since multiple access checks could be
going on at the same time, which the need to all wait
for the same statx() call.
- Not even all kernels support statx() in io_uring (support starts
from 5.6+).
- Serialization now becomes two-level, and more involved.
We don't have an obvious single counter anymore, so we need
to be able to start a docid without knowing how many candidates
there are (and thus, be able to tell Serializer that we are
at the end).
- Limit becomes more tricky, since there can be more calls on
the way back. We solve this by moving limit into Serializer,
and hard-exiting when we hit the limit.
- We need to prioritize statx() calls ahead of read(), so that
we don't end up with very delayed output when the new read()
calls generate even more statx() calls and we get a huge
backlog of calls. (We can't prioritize in the kernel, but we
can on the overflow queue we're managing ourselves.) This is
especially important with --limit.
2020-10-11 19:59:11 +02:00
|
|
|
if (found) {
|
|
|
|
if (pending_candidate != nullptr) {
|
|
|
|
test_candidate(pending_candidate, local_seq, local_seq + 1);
|
|
|
|
++local_seq;
|
2020-09-30 23:59:14 +02:00
|
|
|
}
|
Do the access checking asynchronously if possible.
There are many issues involved:
- There's no access() support in io_uring (yet?), so we fake it
by doing statx() on the directory first, which primes the
dentry cache so that synchronous access() becomes very fast.
It is a bit tricky, since multiple access checks could be
going on at the same time, which the need to all wait
for the same statx() call.
- Not even all kernels support statx() in io_uring (support starts
from 5.6+).
- Serialization now becomes two-level, and more involved.
We don't have an obvious single counter anymore, so we need
to be able to start a docid without knowing how many candidates
there are (and thus, be able to tell Serializer that we are
at the end).
- Limit becomes more tricky, since there can be more calls on
the way back. We solve this by moving limit into Serializer,
and hard-exiting when we hit the limit.
- We need to prioritize statx() calls ahead of read(), so that
we don't end up with very delayed output when the new read()
calls generate even more statx() calls and we get a huge
backlog of calls. (We can't prioritize in the kernel, but we
can on the overflow queue we're managing ourselves.) This is
especially important with --limit.
2020-10-11 19:59:11 +02:00
|
|
|
pending_candidate = filename;
|
2020-09-28 23:52:46 +02:00
|
|
|
}
|
|
|
|
}
|
Do the access checking asynchronously if possible.
There are many issues involved:
- There's no access() support in io_uring (yet?), so we fake it
by doing statx() on the directory first, which primes the
dentry cache so that synchronous access() becomes very fast.
It is a bit tricky, since multiple access checks could be
going on at the same time, which the need to all wait
for the same statx() call.
- Not even all kernels support statx() in io_uring (support starts
from 5.6+).
- Serialization now becomes two-level, and more involved.
We don't have an obvious single counter anymore, so we need
to be able to start a docid without knowing how many candidates
there are (and thus, be able to tell Serializer that we are
at the end).
- Limit becomes more tricky, since there can be more calls on
the way back. We solve this by moving limit into Serializer,
and hard-exiting when we hit the limit.
- We need to prioritize statx() calls ahead of read(), so that
we don't end up with very delayed output when the new read()
calls generate even more statx() calls and we get a huge
backlog of calls. (We can't prioritize in the kernel, but we
can on the overflow queue we're managing ourselves.) This is
especially important with --limit.
2020-10-11 19:59:11 +02:00
|
|
|
if (pending_candidate == nullptr) {
|
|
|
|
serializer->print(seq << 32, 1ULL << 32, "");
|
|
|
|
} else {
|
|
|
|
test_candidate(pending_candidate, local_seq, (seq + 1) << 32);
|
2020-10-01 10:16:31 +02:00
|
|
|
}
|
2020-09-28 23:52:46 +02:00
|
|
|
}
|
|
|
|
|
2020-10-10 11:36:17 +02:00
|
|
|
size_t scan_docids(const vector<Needle> &needles, const vector<uint32_t> &docids, const Corpus &corpus, IOUringEngine *engine)
|
2020-09-30 10:20:10 +02:00
|
|
|
{
|
|
|
|
Serializer docids_in_order;
|
2020-12-05 10:49:55 +01:00
|
|
|
AccessRXCache access_rx_cache(engine, corpus.get_hdr().check_visibility);
|
2020-10-16 00:22:59 +02:00
|
|
|
atomic<uint64_t> matched{ 0 };
|
2020-09-30 10:20:10 +02:00
|
|
|
for (size_t i = 0; i < docids.size(); ++i) {
|
|
|
|
uint32_t docid = docids[i];
|
2021-07-27 16:19:01 +02:00
|
|
|
corpus.get_compressed_filename_block(docid, [i, &matched, &needles, &access_rx_cache, engine, &docids_in_order](string_view compressed) {
|
|
|
|
scan_file_block(needles, compressed, engine, &access_rx_cache, i, &docids_in_order, &matched);
|
2020-09-30 10:20:10 +02:00
|
|
|
});
|
|
|
|
}
|
|
|
|
engine->finish();
|
|
|
|
return matched;
|
|
|
|
}
|
|
|
|
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
struct WorkerThread {
|
|
|
|
thread t;
|
|
|
|
|
|
|
|
// We use a result queue instead of synchronizing Serializer,
|
|
|
|
// since a lock on it becomes a huge choke point if there are
|
|
|
|
// lots of threads.
|
|
|
|
mutex result_mu;
|
2020-10-15 23:40:42 +02:00
|
|
|
struct Result {
|
|
|
|
uint64_t seq;
|
|
|
|
uint64_t skip;
|
|
|
|
string msg;
|
|
|
|
};
|
|
|
|
vector<Result> results;
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
class WorkerThreadReceiver : public ResultReceiver {
|
|
|
|
public:
|
2020-10-16 00:22:59 +02:00
|
|
|
WorkerThreadReceiver(WorkerThread *wt)
|
|
|
|
: wt(wt) {}
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
|
|
|
|
void print(uint64_t seq, uint64_t skip, const string msg) override
|
|
|
|
{
|
|
|
|
lock_guard<mutex> lock(wt->result_mu);
|
2020-10-15 23:41:16 +02:00
|
|
|
if (msg.empty() && !wt->results.empty() && wt->results.back().seq + wt->results.back().skip == seq) {
|
|
|
|
wt->results.back().skip += skip;
|
|
|
|
} else {
|
|
|
|
wt->results.emplace_back(WorkerThread::Result{ seq, skip, move(msg) });
|
|
|
|
}
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
WorkerThread *wt;
|
|
|
|
};
|
|
|
|
|
|
|
|
void deliver_results(WorkerThread *wt, Serializer *serializer)
|
|
|
|
{
|
2020-10-15 23:40:42 +02:00
|
|
|
vector<WorkerThread::Result> results;
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
{
|
|
|
|
lock_guard<mutex> lock(wt->result_mu);
|
|
|
|
results = move(wt->results);
|
|
|
|
}
|
2020-10-15 23:40:42 +02:00
|
|
|
for (const WorkerThread::Result &result : results) {
|
|
|
|
serializer->print(result.seq, result.skip, move(result.msg));
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-09-30 10:20:10 +02:00
|
|
|
// We do this sequentially, as it's faster than scattering
|
|
|
|
// a lot of I/O through io_uring and hoping the kernel will
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
// coalesce it plus readahead for us. Since we assume that
|
|
|
|
// we will primarily be CPU-bound, we'll be firing up one
|
|
|
|
// worker thread for each spare core (the last one will
|
|
|
|
// only be doing I/O). access() is still synchronous.
|
2020-10-11 23:58:41 +02:00
|
|
|
uint64_t scan_all_docids(const vector<Needle> &needles, int fd, const Corpus &corpus)
|
2020-09-30 10:20:10 +02:00
|
|
|
{
|
Use zstd dictionaries.
Since we have small strings, they can benefit from some shared context,
and zstd supports this. plocate-build now reads the mlocate database
twice; the first pass samples 1000 random blocks, which it uses to train
a 1 kB dictionary. (zstd recommends much larger dictionaries, but practical
testing seems to indicate this doesn't help us much, and might actually
be harmful.)
We get ~20% slower builds and ~7% smaller .db files -- but more
interestingly, linear search speed is up ~20% (which indicates that
decompression in itself benefits more). We need to read the 1 kB
dictionary, but it's practically free since it's stored next to the
header and so small.
This is a version bump (to version 1), so we're not forward-compatible,
but we're backward-compatible (plocate still reads version 0 files
just fine). Since we're adding more fields to the header anyway,
we can add a new “max_version” field that allows for marking
backwards-compatible changes in the future, ie., if plocate-build
adds more information that plocate would like to use but that older
plocate versions can simply ignore.
2020-10-13 17:46:20 +02:00
|
|
|
{
|
|
|
|
const Header &hdr = corpus.get_hdr();
|
|
|
|
if (hdr.zstd_dictionary_length_bytes > 0) {
|
|
|
|
string dictionary;
|
|
|
|
dictionary.resize(hdr.zstd_dictionary_length_bytes);
|
|
|
|
complete_pread(fd, &dictionary[0], hdr.zstd_dictionary_length_bytes, hdr.zstd_dictionary_offset_bytes);
|
|
|
|
ddict = ZSTD_createDDict(dictionary.data(), dictionary.size());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-12-05 10:49:55 +01:00
|
|
|
AccessRXCache access_rx_cache(nullptr, corpus.get_hdr().check_visibility);
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
Serializer serializer;
|
2020-09-30 10:20:10 +02:00
|
|
|
uint32_t num_blocks = corpus.get_num_filename_blocks();
|
|
|
|
unique_ptr<uint64_t[]> offsets(new uint64_t[num_blocks + 1]);
|
|
|
|
complete_pread(fd, offsets.get(), (num_blocks + 1) * sizeof(uint64_t), corpus.offset_for_block(0));
|
2020-10-16 00:23:11 +02:00
|
|
|
atomic<uint64_t> matched{ 0 };
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
|
|
|
|
mutex mu;
|
|
|
|
condition_variable queue_added, queue_removed;
|
|
|
|
deque<tuple<int, int, string>> work_queue; // Under mu.
|
|
|
|
bool done = false; // Under mu.
|
|
|
|
|
|
|
|
unsigned num_threads = max<int>(sysconf(_SC_NPROCESSORS_ONLN) - 1, 1);
|
|
|
|
dprintf("Using %u worker threads for linear scan.\n", num_threads);
|
|
|
|
unique_ptr<WorkerThread[]> threads(new WorkerThread[num_threads]);
|
|
|
|
for (unsigned i = 0; i < num_threads; ++i) {
|
2021-09-05 00:47:14 +02:00
|
|
|
threads[i].t = thread([&threads, &mu, &queue_added, &queue_removed, &work_queue, &done, &offsets, &needles, &access_rx_cache, &matched, i] {
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
// regcomp() takes a lock on the regex, so each thread will need its own.
|
|
|
|
const vector<Needle> *use_needles = &needles;
|
|
|
|
vector<Needle> recompiled_needles;
|
|
|
|
if (i != 0 && patterns_are_regex) {
|
|
|
|
recompiled_needles = needles;
|
|
|
|
for (Needle &needle : recompiled_needles) {
|
|
|
|
needle.re = compile_regex(needle.str);
|
|
|
|
}
|
|
|
|
use_needles = &recompiled_needles;
|
|
|
|
}
|
|
|
|
|
|
|
|
WorkerThreadReceiver receiver(&threads[i]);
|
|
|
|
for (;;) {
|
|
|
|
uint32_t io_docid, last_docid;
|
|
|
|
string compressed;
|
|
|
|
|
|
|
|
{
|
2022-10-15 15:44:47 +02:00
|
|
|
unique_lock lock(mu);
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
queue_added.wait(lock, [&work_queue, &done] { return !work_queue.empty() || done; });
|
|
|
|
if (done && work_queue.empty()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
tie(io_docid, last_docid, compressed) = move(work_queue.front());
|
|
|
|
work_queue.pop_front();
|
|
|
|
queue_removed.notify_all();
|
|
|
|
}
|
|
|
|
|
|
|
|
for (uint32_t docid = io_docid; docid < last_docid; ++docid) {
|
|
|
|
size_t relative_offset = offsets[docid] - offsets[io_docid];
|
|
|
|
size_t len = offsets[docid + 1] - offsets[docid];
|
2021-09-05 00:47:14 +02:00
|
|
|
// IOUringEngine isn't thread-safe, so we do any needed stat()s synchronously (nullptr engine).
|
|
|
|
scan_file_block(*use_needles, { &compressed[relative_offset], len }, /*engine=*/nullptr, &access_rx_cache, docid, &receiver, &matched);
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2020-09-30 10:20:10 +02:00
|
|
|
string compressed;
|
|
|
|
for (uint32_t io_docid = 0; io_docid < num_blocks; io_docid += 32) {
|
|
|
|
uint32_t last_docid = std::min(io_docid + 32, num_blocks);
|
|
|
|
size_t io_len = offsets[last_docid] - offsets[io_docid];
|
|
|
|
if (compressed.size() < io_len) {
|
|
|
|
compressed.resize(io_len);
|
|
|
|
}
|
|
|
|
complete_pread(fd, &compressed[0], io_len, offsets[io_docid]);
|
|
|
|
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
{
|
2022-10-15 15:44:47 +02:00
|
|
|
unique_lock lock(mu);
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
queue_removed.wait(lock, [&work_queue] { return work_queue.size() < 256; }); // Allow ~2MB of data queued up.
|
|
|
|
work_queue.emplace_back(io_docid, last_docid, move(compressed));
|
|
|
|
queue_added.notify_one(); // Avoid the thundering herd.
|
2020-09-30 10:20:10 +02:00
|
|
|
}
|
Multithread linear scans.
When we have a scan that we cannot accelerate with trigrams
(very short patterns, or regexes), we need to go through all of
the file names like mlocate does. This is usually CPU-bound,
so fire up threads. We leave one core/hyperthread for the I/O
and add a thread for each of the rest (this is probably bad
on dualcore, but it's a simple thing that will do for now,
and should be fairly safe).
The bottleneck now is Serializer. I first tried just putting a
mutex on it, which worked fine on eight hyperthreads
(ie., four real cores, my laptop), but caused huge contention with 40
(20 cores, my old dual-socket Haswell). Sending data back through
per-thread queues seems to work a lot better, but we're still
spending a lot of time in Serializer; witness that --count is
much faster for such a search.
2020-10-15 22:41:42 +02:00
|
|
|
|
|
|
|
// Pick up some results, so that we are sure that we won't just overload.
|
|
|
|
// (Seemingly, going through all of these causes slowness with many threads,
|
|
|
|
// but taking only one is OK.)
|
|
|
|
unsigned i = io_docid / 32;
|
|
|
|
deliver_results(&threads[i % num_threads], &serializer);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
lock_guard<mutex> lock(mu);
|
|
|
|
done = true;
|
|
|
|
queue_added.notify_all();
|
|
|
|
}
|
|
|
|
for (unsigned i = 0; i < num_threads; ++i) {
|
|
|
|
threads[i].t.join();
|
|
|
|
deliver_results(&threads[i], &serializer);
|
2020-09-30 10:20:10 +02:00
|
|
|
}
|
2020-10-08 20:05:41 +02:00
|
|
|
return matched;
|
2020-09-30 10:20:10 +02:00
|
|
|
}
|
|
|
|
|
2020-10-10 11:36:17 +02:00
|
|
|
// Takes the given posting list, unions it into the parts of the trigram disjunction
|
|
|
|
// already read; if the list is complete, intersects with “cur_candidates”.
|
|
|
|
//
|
|
|
|
// Returns true if the search should be aborted (we are done).
|
|
|
|
bool new_posting_list_read(TrigramDisjunction *td, vector<uint32_t> decoded, vector<uint32_t> *cur_candidates, vector<uint32_t> *tmp)
|
2020-10-10 00:52:26 +02:00
|
|
|
{
|
2020-10-10 11:36:17 +02:00
|
|
|
if (td->docids.empty()) {
|
|
|
|
td->docids = move(decoded);
|
|
|
|
} else {
|
|
|
|
tmp->clear();
|
|
|
|
set_union(decoded.begin(), decoded.end(), td->docids.begin(), td->docids.end(), back_inserter(*tmp));
|
|
|
|
swap(*tmp, td->docids);
|
|
|
|
}
|
|
|
|
if (--td->remaining_trigrams_to_read > 0) {
|
|
|
|
// Need to wait for more.
|
|
|
|
if (ignore_case) {
|
|
|
|
dprintf(" ... %u reads left in OR group %u (%zu docids in list)\n",
|
2020-10-10 19:09:36 +02:00
|
|
|
td->remaining_trigrams_to_read, td->index, td->docids.size());
|
2020-10-10 11:36:17 +02:00
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (cur_candidates->empty()) {
|
|
|
|
if (ignore_case) {
|
|
|
|
dprintf(" ... all reads done for OR group %u (%zu docids)\n",
|
2020-10-10 19:09:36 +02:00
|
|
|
td->index, td->docids.size());
|
2020-10-10 11:36:17 +02:00
|
|
|
}
|
|
|
|
*cur_candidates = move(td->docids);
|
|
|
|
} else {
|
|
|
|
tmp->clear();
|
|
|
|
set_intersection(cur_candidates->begin(), cur_candidates->end(),
|
|
|
|
td->docids.begin(), td->docids.end(),
|
|
|
|
back_inserter(*tmp));
|
|
|
|
swap(*cur_candidates, *tmp);
|
|
|
|
if (ignore_case) {
|
|
|
|
if (cur_candidates->empty()) {
|
|
|
|
dprintf(" ... all reads done for OR group %u (%zu docids), intersected (none left, search is done)\n",
|
2020-10-10 19:09:36 +02:00
|
|
|
td->index, td->docids.size());
|
2020-10-10 11:36:17 +02:00
|
|
|
return true;
|
2020-10-10 00:52:26 +02:00
|
|
|
} else {
|
2020-10-10 11:36:17 +02:00
|
|
|
dprintf(" ... all reads done for OR group %u (%zu docids), intersected (%zu left)\n",
|
2020-10-10 19:09:36 +02:00
|
|
|
td->index, td->docids.size(), cur_candidates->size());
|
2020-10-10 00:52:26 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2020-10-10 11:36:17 +02:00
|
|
|
return false;
|
2020-10-10 00:52:26 +02:00
|
|
|
}
|
|
|
|
|
2021-03-28 00:19:49 +01:00
|
|
|
uint64_t do_search_file(const vector<Needle> &needles, const std::string &filename)
|
2020-09-27 22:53:35 +02:00
|
|
|
{
|
2021-03-28 00:19:49 +01:00
|
|
|
int fd = open(filename.c_str(), O_RDONLY);
|
2020-09-27 22:53:35 +02:00
|
|
|
if (fd == -1) {
|
2021-03-28 00:19:49 +01:00
|
|
|
perror(filename.c_str());
|
2020-09-27 22:53:35 +02:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Drop privileges.
|
|
|
|
if (setgid(getgid()) != 0) {
|
|
|
|
perror("setgid");
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
|
Do the access checking asynchronously if possible.
There are many issues involved:
- There's no access() support in io_uring (yet?), so we fake it
by doing statx() on the directory first, which primes the
dentry cache so that synchronous access() becomes very fast.
It is a bit tricky, since multiple access checks could be
going on at the same time, which the need to all wait
for the same statx() call.
- Not even all kernels support statx() in io_uring (support starts
from 5.6+).
- Serialization now becomes two-level, and more involved.
We don't have an obvious single counter anymore, so we need
to be able to start a docid without knowing how many candidates
there are (and thus, be able to tell Serializer that we are
at the end).
- Limit becomes more tricky, since there can be more calls on
the way back. We solve this by moving limit into Serializer,
and hard-exiting when we hit the limit.
- We need to prioritize statx() calls ahead of read(), so that
we don't end up with very delayed output when the new read()
calls generate even more statx() calls and we get a huge
backlog of calls. (We can't prioritize in the kernel, but we
can on the overflow queue we're managing ourselves.) This is
especially important with --limit.
2020-10-11 19:59:11 +02:00
|
|
|
start = steady_clock::now();
|
2020-09-27 22:53:35 +02:00
|
|
|
if (access("/", R_OK | X_OK)) {
|
|
|
|
// We can't find anything, no need to bother...
|
2024-08-28 15:36:24 +02:00
|
|
|
close(fd);
|
2021-03-28 00:19:49 +01:00
|
|
|
return 0;
|
2020-09-27 22:53:35 +02:00
|
|
|
}
|
|
|
|
|
2020-10-08 22:41:41 +02:00
|
|
|
IOUringEngine engine(/*slop_bytes=*/16); // 16 slop bytes as described in turbopfor.h.
|
2021-10-18 09:42:00 +02:00
|
|
|
Corpus corpus(fd, filename.c_str(), &engine);
|
2020-09-30 19:44:28 +02:00
|
|
|
dprintf("Corpus init done after %.1f ms.\n", 1e3 * duration<float>(steady_clock::now() - start).count());
|
2020-09-27 22:53:35 +02:00
|
|
|
|
2020-10-10 11:36:17 +02:00
|
|
|
vector<TrigramDisjunction> trigram_groups;
|
2020-10-10 21:43:20 +02:00
|
|
|
if (patterns_are_regex) {
|
|
|
|
// We could parse the regex to find trigrams that have to be there
|
|
|
|
// (there are actually known algorithms to deal with disjunctions
|
|
|
|
// and such, too), but for now, we just go brute force.
|
|
|
|
// Using locate with regexes is pretty niche.
|
|
|
|
} else {
|
|
|
|
for (const Needle &needle : needles) {
|
|
|
|
parse_trigrams(needle.str, ignore_case, &trigram_groups);
|
|
|
|
}
|
2020-10-10 11:36:17 +02:00
|
|
|
}
|
2020-10-10 21:43:20 +02:00
|
|
|
|
2020-10-10 11:36:17 +02:00
|
|
|
unique_sort(
|
|
|
|
&trigram_groups,
|
|
|
|
[](const TrigramDisjunction &a, const TrigramDisjunction &b) { return a.trigram_alternatives < b.trigram_alternatives; },
|
|
|
|
[](const TrigramDisjunction &a, const TrigramDisjunction &b) { return a.trigram_alternatives == b.trigram_alternatives; });
|
|
|
|
|
|
|
|
// Give them names for debugging.
|
|
|
|
unsigned td_index = 0;
|
|
|
|
for (TrigramDisjunction &td : trigram_groups) {
|
|
|
|
td.index = td_index++;
|
2020-09-30 23:57:02 +02:00
|
|
|
}
|
|
|
|
|
2020-10-10 11:36:17 +02:00
|
|
|
// Collect which trigrams we need to look up in the hash table.
|
|
|
|
unordered_map<uint32_t, vector<TrigramDisjunction *>> trigrams_to_lookup;
|
|
|
|
for (TrigramDisjunction &td : trigram_groups) {
|
|
|
|
for (uint32_t trgm : td.trigram_alternatives) {
|
|
|
|
trigrams_to_lookup[trgm].push_back(&td);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (trigrams_to_lookup.empty()) {
|
2020-09-29 00:27:06 +02:00
|
|
|
// Too short for trigram matching. Apply brute force.
|
|
|
|
// (We could have searched through all trigrams that matched
|
|
|
|
// the pattern and done a union of them, but that's a lot of
|
|
|
|
// work for fairly unclear gain.)
|
2020-10-11 23:58:41 +02:00
|
|
|
uint64_t matched = scan_all_docids(needles, fd, corpus);
|
2020-10-17 09:55:18 +02:00
|
|
|
dprintf("Done in %.1f ms, found %" PRId64 " matches.\n",
|
2020-10-17 09:55:45 +02:00
|
|
|
1e3 * duration<float>(steady_clock::now() - start).count(), matched);
|
2024-08-28 15:36:24 +02:00
|
|
|
close(fd);
|
2021-03-28 00:19:49 +01:00
|
|
|
return matched;
|
2020-09-29 00:27:06 +02:00
|
|
|
}
|
2020-10-10 11:36:17 +02:00
|
|
|
|
Use zstd dictionaries.
Since we have small strings, they can benefit from some shared context,
and zstd supports this. plocate-build now reads the mlocate database
twice; the first pass samples 1000 random blocks, which it uses to train
a 1 kB dictionary. (zstd recommends much larger dictionaries, but practical
testing seems to indicate this doesn't help us much, and might actually
be harmful.)
We get ~20% slower builds and ~7% smaller .db files -- but more
interestingly, linear search speed is up ~20% (which indicates that
decompression in itself benefits more). We need to read the 1 kB
dictionary, but it's practically free since it's stored next to the
header and so small.
This is a version bump (to version 1), so we're not forward-compatible,
but we're backward-compatible (plocate still reads version 0 files
just fine). Since we're adding more fields to the header anyway,
we can add a new “max_version” field that allows for marking
backwards-compatible changes in the future, ie., if plocate-build
adds more information that plocate would like to use but that older
plocate versions can simply ignore.
2020-10-13 17:46:20 +02:00
|
|
|
// Sneak in fetching the dictionary, if present. It's not necessarily clear
|
|
|
|
// exactly where it would be cheapest to get it, but it needs to be present
|
|
|
|
// before we can decode any of the posting lists. Most likely, it's
|
|
|
|
// in the same filesystem block as the header anyway, so it should be
|
|
|
|
// present in the cache.
|
|
|
|
{
|
|
|
|
const Header &hdr = corpus.get_hdr();
|
|
|
|
if (hdr.zstd_dictionary_length_bytes > 0) {
|
|
|
|
engine.submit_read(fd, hdr.zstd_dictionary_length_bytes, hdr.zstd_dictionary_offset_bytes, [](string_view s) {
|
|
|
|
ddict = ZSTD_createDDict(s.data(), s.size());
|
|
|
|
dprintf("Dictionary initialized after %.1f ms.\n", 1e3 * duration<float>(steady_clock::now() - start).count());
|
|
|
|
});
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-10 11:36:17 +02:00
|
|
|
// Look them all up on disk.
|
2021-03-28 00:19:49 +01:00
|
|
|
bool should_early_exit = false;
|
2020-10-10 11:36:17 +02:00
|
|
|
for (auto &[trgm, trigram_groups] : trigrams_to_lookup) {
|
2021-03-28 00:19:49 +01:00
|
|
|
corpus.find_trigram(trgm, [trgm{ trgm }, trigram_groups{ &trigram_groups }, &should_early_exit](const Trigram *trgmptr, size_t len) {
|
2020-10-10 11:36:17 +02:00
|
|
|
if (trgmptr == nullptr) {
|
|
|
|
dprintf("trigram %s isn't found\n", print_trigram(trgm).c_str());
|
|
|
|
for (TrigramDisjunction *td : *trigram_groups) {
|
|
|
|
--td->remaining_trigrams_to_read;
|
2021-03-28 00:19:49 +01:00
|
|
|
|
|
|
|
// If we now know this trigram group doesn't match anything at all,
|
|
|
|
// we can do early exit; however, if we're in a forked child,
|
|
|
|
// that would confuse the parent process (since we don't write
|
|
|
|
// our count to the pipe), so we wait until we're back in to the
|
|
|
|
// regular (non-async) context. This is a fairly rare case anyway,
|
|
|
|
// and the gains from dropping the remaining trigram reads are limited.
|
2020-10-10 11:36:17 +02:00
|
|
|
if (td->remaining_trigrams_to_read == 0 && td->read_trigrams.empty()) {
|
2021-03-28 00:19:49 +01:00
|
|
|
if (in_forked_child) {
|
|
|
|
should_early_exit = true;
|
|
|
|
} else {
|
|
|
|
dprintf("zero matches in %s, so we are done\n", print_td(*td).c_str());
|
|
|
|
if (only_count) {
|
|
|
|
printf("0\n");
|
|
|
|
}
|
2022-11-06 12:09:53 -08:00
|
|
|
exit(1);
|
2020-10-10 11:36:17 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
for (TrigramDisjunction *td : *trigram_groups) {
|
|
|
|
--td->remaining_trigrams_to_read;
|
|
|
|
td->max_num_docids += trgmptr->num_docids;
|
|
|
|
td->read_trigrams.emplace_back(*trgmptr, len);
|
|
|
|
}
|
|
|
|
});
|
|
|
|
}
|
|
|
|
engine.finish();
|
|
|
|
dprintf("Hashtable lookups done after %.1f ms.\n", 1e3 * duration<float>(steady_clock::now() - start).count());
|
|
|
|
|
2021-03-28 00:19:49 +01:00
|
|
|
if (should_early_exit) {
|
2024-08-28 15:36:24 +02:00
|
|
|
close(fd);
|
2021-03-28 00:19:49 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-10-10 11:36:17 +02:00
|
|
|
for (TrigramDisjunction &td : trigram_groups) {
|
|
|
|
// Reset for reads.
|
|
|
|
td.remaining_trigrams_to_read = td.read_trigrams.size();
|
|
|
|
|
|
|
|
if (ignore_case) { // If case-sensitive, they'll all be pretty obvious single-entry groups.
|
|
|
|
dprintf("OR group %u (max_num_docids=%u): %s\n", td.index, td.max_num_docids, print_td(td).c_str());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// TODO: For case-insensitive (ie. more than one alternative in each),
|
|
|
|
// prioritize the ones with fewer seeks?
|
|
|
|
sort(trigram_groups.begin(), trigram_groups.end(),
|
|
|
|
[&](const TrigramDisjunction &a, const TrigramDisjunction &b) {
|
|
|
|
return a.max_num_docids < b.max_num_docids;
|
2020-09-29 00:13:18 +02:00
|
|
|
});
|
2020-09-27 22:53:35 +02:00
|
|
|
|
2020-10-10 11:36:17 +02:00
|
|
|
unordered_map<uint32_t, vector<TrigramDisjunction *>> uses_trigram;
|
|
|
|
for (TrigramDisjunction &td : trigram_groups) {
|
|
|
|
for (uint32_t trgm : td.trigram_alternatives) {
|
|
|
|
uses_trigram[trgm].push_back(&td);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
unordered_set<uint32_t> trigrams_submitted_read;
|
|
|
|
vector<uint32_t> cur_candidates, tmp, decoded;
|
2020-09-30 10:20:10 +02:00
|
|
|
bool done = false;
|
2020-10-10 11:36:17 +02:00
|
|
|
for (TrigramDisjunction &td : trigram_groups) {
|
|
|
|
if (!cur_candidates.empty() && td.max_num_docids > cur_candidates.size() * 100) {
|
|
|
|
dprintf("%s has up to %u entries, ignoring the rest (will "
|
2020-09-30 10:20:10 +02:00
|
|
|
"weed out false positives later)\n",
|
2020-10-10 11:36:17 +02:00
|
|
|
print_td(td).c_str(), td.max_num_docids);
|
2020-09-30 10:20:10 +02:00
|
|
|
break;
|
|
|
|
}
|
2020-09-27 22:53:35 +02:00
|
|
|
|
2020-10-10 11:36:17 +02:00
|
|
|
for (auto &[trgmptr, len] : td.read_trigrams) {
|
|
|
|
if (trigrams_submitted_read.count(trgmptr.trgm) != 0) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
trigrams_submitted_read.insert(trgmptr.trgm);
|
|
|
|
// Only stay a certain amount ahead, so that we don't spend I/O
|
|
|
|
// on reading the latter, large posting lists. We are unlikely
|
|
|
|
// to need them anyway, even if they should come in first.
|
|
|
|
if (engine.get_waiting_reads() >= 5) {
|
|
|
|
engine.finish();
|
|
|
|
if (done)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
engine.submit_read(fd, len, trgmptr.offset, [trgmptr{ trgmptr }, len{ len }, &done, &cur_candidates, &tmp, &decoded, &uses_trigram](string_view s) {
|
|
|
|
if (done)
|
|
|
|
return;
|
|
|
|
|
2020-10-17 14:37:25 +02:00
|
|
|
uint32_t trgm = trgmptr.trgm;
|
2020-10-10 11:36:17 +02:00
|
|
|
const unsigned char *pldata = reinterpret_cast<const unsigned char *>(s.data());
|
|
|
|
size_t num = trgmptr.num_docids;
|
|
|
|
decoded.resize(num);
|
|
|
|
decode_pfor_delta1_128(pldata, num, /*interleaved=*/true, &decoded[0]);
|
|
|
|
|
|
|
|
assert(uses_trigram.count(trgm) != 0);
|
|
|
|
bool was_empty = cur_candidates.empty();
|
|
|
|
if (ignore_case) {
|
|
|
|
dprintf("trigram %s (%zu bytes) decoded to %zu entries\n", print_trigram(trgm).c_str(), len, num);
|
2020-09-30 10:20:10 +02:00
|
|
|
}
|
2020-10-10 11:36:17 +02:00
|
|
|
|
|
|
|
for (TrigramDisjunction *td : uses_trigram[trgm]) {
|
|
|
|
done |= new_posting_list_read(td, decoded, &cur_candidates, &tmp);
|
|
|
|
if (done)
|
|
|
|
break;
|
2020-09-30 10:20:10 +02:00
|
|
|
}
|
2020-10-10 11:36:17 +02:00
|
|
|
if (!ignore_case) {
|
|
|
|
if (was_empty) {
|
|
|
|
dprintf("trigram %s (%zu bytes) decoded to %zu entries\n", print_trigram(trgm).c_str(), len, num);
|
|
|
|
} else if (cur_candidates.empty()) {
|
|
|
|
dprintf("trigram %s (%zu bytes) decoded to %zu entries (none left, search is done)\n", print_trigram(trgm).c_str(), len, num);
|
|
|
|
} else {
|
|
|
|
dprintf("trigram %s (%zu bytes) decoded to %zu entries (%zu left)\n", print_trigram(trgm).c_str(), len, num, cur_candidates.size());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
});
|
|
|
|
}
|
2020-09-27 22:53:35 +02:00
|
|
|
}
|
2020-09-30 10:20:10 +02:00
|
|
|
engine.finish();
|
2020-09-30 20:03:54 +02:00
|
|
|
if (done) {
|
2024-08-28 15:36:24 +02:00
|
|
|
close(fd);
|
2021-03-28 00:19:49 +01:00
|
|
|
return 0;
|
2020-09-30 20:03:54 +02:00
|
|
|
}
|
2020-09-30 19:44:28 +02:00
|
|
|
dprintf("Intersection done after %.1f ms. Doing final verification and printing:\n",
|
2020-09-30 10:20:10 +02:00
|
|
|
1e3 * duration<float>(steady_clock::now() - start).count());
|
2020-09-27 22:53:35 +02:00
|
|
|
|
2020-10-10 11:36:17 +02:00
|
|
|
uint64_t matched = scan_docids(needles, cur_candidates, corpus, &engine);
|
2020-10-11 19:57:20 +02:00
|
|
|
dprintf("Done in %.1f ms, found %" PRId64 " matches.\n",
|
2020-09-30 10:20:10 +02:00
|
|
|
1e3 * duration<float>(steady_clock::now() - start).count(), matched);
|
2024-08-28 15:36:24 +02:00
|
|
|
close(fd);
|
2021-03-28 00:19:49 +01:00
|
|
|
return matched;
|
|
|
|
}
|
2020-10-08 20:05:41 +02:00
|
|
|
|
2021-03-28 00:19:49 +01:00
|
|
|
// Run do_search_file() in a child process.
|
|
|
|
//
|
|
|
|
// The reason for this is that we're not robust against malicious input, so we need
|
|
|
|
// to drop privileges after opening the file. (Otherwise, we could fall prey to an attack
|
|
|
|
// where a user does locate -d badfile.db:/var/lib/plocate/plocate.db, badfile.db contains
|
|
|
|
// a buffer overflow that takes over the process, and then uses the elevated privileges
|
|
|
|
// to print out otherwise inaccessible paths.) We solve this by forking and treating the
|
|
|
|
// child process as untrusted after it has dropped its privileges (which it does before
|
|
|
|
// reading any data from the file); it returns a single 64-bit number over a pipe,
|
|
|
|
// and that's it. The parent keeps its privileges, and can then fork out new children
|
|
|
|
// without fear of being taken over. (The child keeps stdout for outputting results.)
|
|
|
|
//
|
|
|
|
// The count is returned over the pipe, because it's needed both for --limit and --count.
|
|
|
|
uint64_t do_search_file_in_child(const vector<Needle> &needles, const std::string &filename)
|
|
|
|
{
|
|
|
|
int pipefd[2];
|
|
|
|
if (pipe(pipefd) == -1) {
|
|
|
|
perror("pipe");
|
|
|
|
exit(EXIT_FAILURE);
|
2020-10-08 20:05:41 +02:00
|
|
|
}
|
2021-03-28 00:19:49 +01:00
|
|
|
|
|
|
|
pid_t child_pid = fork();
|
|
|
|
switch (child_pid) {
|
|
|
|
case 0: {
|
|
|
|
// Child.
|
|
|
|
close(pipefd[0]);
|
|
|
|
in_forked_child = true;
|
|
|
|
uint64_t matched = do_search_file(needles, filename);
|
|
|
|
int ret;
|
|
|
|
do {
|
|
|
|
ret = write(pipefd[1], &matched, sizeof(matched));
|
|
|
|
} while (ret == -1 && errno == EINTR);
|
|
|
|
if (ret != sizeof(matched)) {
|
|
|
|
perror("write");
|
|
|
|
_exit(EXIT_FAILURE);
|
|
|
|
}
|
2021-06-05 19:31:12 +02:00
|
|
|
fflush(stdout);
|
2021-03-28 00:19:49 +01:00
|
|
|
_exit(EXIT_SUCCESS);
|
|
|
|
}
|
|
|
|
case -1:
|
|
|
|
// Error.
|
|
|
|
perror("fork");
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
default:
|
|
|
|
// Parent.
|
|
|
|
close(pipefd[1]);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Wait for the child to finish.
|
|
|
|
int wstatus;
|
|
|
|
pid_t err;
|
|
|
|
do {
|
|
|
|
err = waitpid(child_pid, &wstatus, 0);
|
|
|
|
} while (err == -1 && errno == EINTR);
|
|
|
|
if (err == -1) {
|
|
|
|
perror("waitpid");
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
if (WIFEXITED(wstatus)) {
|
|
|
|
if (WEXITSTATUS(wstatus) != 0) {
|
|
|
|
// The child has probably already printed out its error, so just propagate the exit status.
|
|
|
|
exit(WEXITSTATUS(wstatus));
|
|
|
|
}
|
|
|
|
// Success!
|
|
|
|
} else if (!WIFEXITED(wstatus)) {
|
|
|
|
fprintf(stderr, "FATAL: Child died unexpectedly while processing %s\n", filename.c_str());
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Now get the number of matches from the child.
|
|
|
|
uint64_t matched;
|
|
|
|
int ret;
|
|
|
|
do {
|
|
|
|
ret = read(pipefd[0], &matched, sizeof(matched));
|
|
|
|
} while (ret == -1 && errno == EINTR);
|
|
|
|
if (ret == -1) {
|
|
|
|
perror("read");
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
} else if (ret != sizeof(matched)) {
|
|
|
|
fprintf(stderr, "FATAL: Short read through pipe (got %d bytes)\n", ret);
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
close(pipefd[0]);
|
|
|
|
return matched;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Parses a colon-separated list of strings and appends them onto the given vector.
|
|
|
|
// Backslash escapes whatever comes after it.
|
|
|
|
void parse_dbpaths(const char *ptr, vector<string> *output)
|
|
|
|
{
|
|
|
|
string str;
|
|
|
|
while (*ptr != '\0') {
|
|
|
|
if (*ptr == '\\') {
|
|
|
|
if (ptr[1] == '\0') {
|
|
|
|
fprintf(stderr, "ERROR: Escape character at the end of string\n");
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
// Escape.
|
|
|
|
str.push_back(ptr[1]);
|
|
|
|
ptr += 2;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (*ptr == ':') {
|
|
|
|
// Separator.
|
|
|
|
output->push_back(move(str));
|
2024-08-28 16:01:26 +02:00
|
|
|
str.clear();
|
2021-03-28 00:19:49 +01:00
|
|
|
++ptr;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
str.push_back(*ptr++);
|
|
|
|
}
|
|
|
|
output->push_back(move(str));
|
2020-09-27 22:53:35 +02:00
|
|
|
}
|
|
|
|
|
2020-09-30 23:50:47 +02:00
|
|
|
void usage()
|
|
|
|
{
|
2020-10-10 21:26:30 +02:00
|
|
|
printf(
|
|
|
|
"Usage: plocate [OPTION]... PATTERN...\n"
|
|
|
|
"\n"
|
2020-10-17 09:46:55 +02:00
|
|
|
" -b, --basename search only the file name portion of path names\n"
|
2020-10-10 21:26:30 +02:00
|
|
|
" -c, --count print number of matches instead of the matches\n"
|
|
|
|
" -d, --database DBPATH search for files in DBPATH\n"
|
Add a native updatedb.
This incorporates some code from mlocate's updatedb, and thus is compatible
with /etc/updatedb.conf, and supports all the pruning options from it.
All the code has been heavily modified, e.g. the gnulib dependency has been
removed and replaced with STL code (kicking 10k+ lines of code), the bind
mount code has been fixed (it was all broken since the switch from /etc/mtab
to /proc/self/mountinfo) and everything has been reformatted. Like with mlocate,
plocate's updatedb is merging, ie., it can skip readdir() on unchanged
directories. (The logic here is also copied pretty verbatim from mlocate.)
updatedb reads plocate's native format; there's a new max_version 2 that
contains directory timestamps (without it, updatedb will fall back to a full
scan). The timestamps increase the database size by only about 1%, which is a
good tradeoff when we're getting rid of the entire mlocate database.
We liberally use modern features to simplify the implementation; in particular,
openat() to avoid race conditions, instead of mlocate's complicated chdir() dance.
Unfortunately, the combination of the slightly strange storage order from mlocate,
and openat(), means we can need to keep up a bunch of file descriptors open,
but they are not an expensive resource these days, and we try to bump the
limit ourselves if we are allowed to. We also use O_TMPFILE, to make sure we
never leave a half-finished file lying around (mlocate's updatedb tries to
catch signals instead). All of this may hinder portability, so we might ease up
on the requirements later. We don't use io_uring for updatedb at this point.
plocate-build does not write the needed timestamps, so the first upgrade from
mlocate to native plocate requires a full rescan.
NOTE: The format is _not_ frozen yet, and won't be until actual release.
2020-11-21 18:23:20 +01:00
|
|
|
" (default is " DBFILE ")\n"
|
2020-10-10 21:26:30 +02:00
|
|
|
" -i, --ignore-case search case-insensitively\n"
|
|
|
|
" -l, --limit LIMIT stop after LIMIT matches\n"
|
|
|
|
" -0, --null delimit matches by NUL instead of newline\n"
|
2021-10-05 23:02:09 +02:00
|
|
|
" -N, --literal do not quote filenames, even if printing to a tty\n"
|
2020-10-10 21:43:20 +02:00
|
|
|
" -r, --regexp interpret patterns as basic regexps (slow)\n"
|
|
|
|
" --regex interpret patterns as extended regexps (slow)\n"
|
2020-10-17 09:46:55 +02:00
|
|
|
" -w, --wholename search the entire path name (default; see -b)\n"
|
2020-10-10 21:26:30 +02:00
|
|
|
" --help print this help\n"
|
|
|
|
" --version print version information\n");
|
2020-10-10 20:39:44 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void version()
|
|
|
|
{
|
Add a native updatedb.
This incorporates some code from mlocate's updatedb, and thus is compatible
with /etc/updatedb.conf, and supports all the pruning options from it.
All the code has been heavily modified, e.g. the gnulib dependency has been
removed and replaced with STL code (kicking 10k+ lines of code), the bind
mount code has been fixed (it was all broken since the switch from /etc/mtab
to /proc/self/mountinfo) and everything has been reformatted. Like with mlocate,
plocate's updatedb is merging, ie., it can skip readdir() on unchanged
directories. (The logic here is also copied pretty verbatim from mlocate.)
updatedb reads plocate's native format; there's a new max_version 2 that
contains directory timestamps (without it, updatedb will fall back to a full
scan). The timestamps increase the database size by only about 1%, which is a
good tradeoff when we're getting rid of the entire mlocate database.
We liberally use modern features to simplify the implementation; in particular,
openat() to avoid race conditions, instead of mlocate's complicated chdir() dance.
Unfortunately, the combination of the slightly strange storage order from mlocate,
and openat(), means we can need to keep up a bunch of file descriptors open,
but they are not an expensive resource these days, and we try to bump the
limit ourselves if we are allowed to. We also use O_TMPFILE, to make sure we
never leave a half-finished file lying around (mlocate's updatedb tries to
catch signals instead). All of this may hinder portability, so we might ease up
on the requirements later. We don't use io_uring for updatedb at this point.
plocate-build does not write the needed timestamps, so the first upgrade from
mlocate to native plocate requires a full rescan.
NOTE: The format is _not_ frozen yet, and won't be until actual release.
2020-11-21 18:23:20 +01:00
|
|
|
printf("%s %s\n", PACKAGE_NAME, PACKAGE_VERSION);
|
2020-10-10 20:39:44 +02:00
|
|
|
printf("Copyright 2020 Steinar H. Gunderson\n");
|
|
|
|
printf("License GPLv2+: GNU GPL version 2 or later <https://gnu.org/licenses/gpl.html>.\n");
|
|
|
|
printf("This is free software: you are free to change and redistribute it.\n");
|
|
|
|
printf("There is NO WARRANTY, to the extent permitted by law.\n");
|
|
|
|
exit(0);
|
2020-09-30 23:50:47 +02:00
|
|
|
}
|
|
|
|
|
2020-09-27 22:53:35 +02:00
|
|
|
int main(int argc, char **argv)
|
|
|
|
{
|
2021-03-28 00:19:49 +01:00
|
|
|
vector<string> dbpaths;
|
|
|
|
|
2020-10-10 21:43:20 +02:00
|
|
|
constexpr int EXTENDED_REGEX = 1000;
|
2020-10-16 00:48:23 +02:00
|
|
|
constexpr int FLUSH_CACHE = 1001;
|
2023-12-31 11:29:43 +01:00
|
|
|
constexpr int IGNORE_VISIBILITY = 1002;
|
2020-09-30 23:50:47 +02:00
|
|
|
static const struct option long_options[] = {
|
|
|
|
{ "help", no_argument, 0, 'h' },
|
2020-10-08 20:05:41 +02:00
|
|
|
{ "count", no_argument, 0, 'c' },
|
2021-11-12 20:14:00 +01:00
|
|
|
{ "all", no_argument, 0, 'A' },
|
2020-10-17 09:46:55 +02:00
|
|
|
{ "basename", no_argument, 0, 'b' },
|
2020-09-30 23:50:47 +02:00
|
|
|
{ "database", required_argument, 0, 'd' },
|
2021-07-27 16:19:01 +02:00
|
|
|
{ "existing", no_argument, 0, 'e' },
|
2020-10-10 11:36:17 +02:00
|
|
|
{ "ignore-case", no_argument, 0, 'i' },
|
2020-10-08 20:49:30 +02:00
|
|
|
{ "limit", required_argument, 0, 'l' },
|
2021-10-05 23:02:09 +02:00
|
|
|
{ "literal", no_argument, 0, 'N' },
|
2020-09-30 23:59:14 +02:00
|
|
|
{ "null", no_argument, 0, '0' },
|
2020-10-10 20:39:44 +02:00
|
|
|
{ "version", no_argument, 0, 'V' },
|
2020-10-10 21:43:20 +02:00
|
|
|
{ "regexp", no_argument, 0, 'r' },
|
|
|
|
{ "regex", no_argument, 0, EXTENDED_REGEX },
|
2020-10-17 09:46:55 +02:00
|
|
|
{ "wholename", no_argument, 0, 'w' },
|
2020-10-10 19:30:13 +02:00
|
|
|
{ "debug", no_argument, 0, 'D' }, // Not documented.
|
2020-10-16 00:48:23 +02:00
|
|
|
// Enable to test cold-cache behavior (except for access()). Not documented.
|
|
|
|
{ "flush-cache", no_argument, 0, FLUSH_CACHE },
|
2023-12-31 11:29:43 +01:00
|
|
|
// Mostly useful to dump out the entire database, even if the given directories
|
|
|
|
// are gone. Disables sgid due to security. Not documented.
|
|
|
|
{ "ignore-visibility", no_argument, 0, IGNORE_VISIBILITY },
|
2020-09-30 23:50:47 +02:00
|
|
|
{ 0, 0, 0, 0 }
|
|
|
|
};
|
|
|
|
|
2020-10-10 00:52:26 +02:00
|
|
|
setlocale(LC_ALL, "");
|
2020-09-30 23:50:47 +02:00
|
|
|
for (;;) {
|
|
|
|
int option_index = 0;
|
2021-11-12 20:14:00 +01:00
|
|
|
int c = getopt_long(argc, argv, "Abcd:ehil:n:N0rwVD", long_options, &option_index);
|
2020-09-30 23:50:47 +02:00
|
|
|
if (c == -1) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
switch (c) {
|
2021-11-12 20:14:00 +01:00
|
|
|
case 'A':
|
|
|
|
// Ignored.
|
|
|
|
break;
|
2020-10-17 09:46:55 +02:00
|
|
|
case 'b':
|
|
|
|
match_basename = true;
|
|
|
|
break;
|
2020-10-08 20:05:41 +02:00
|
|
|
case 'c':
|
|
|
|
only_count = true;
|
|
|
|
break;
|
2020-09-30 23:50:47 +02:00
|
|
|
case 'd':
|
2021-03-28 00:19:49 +01:00
|
|
|
parse_dbpaths(optarg, &dbpaths);
|
2020-09-30 23:50:47 +02:00
|
|
|
break;
|
2021-07-27 16:19:01 +02:00
|
|
|
case 'e':
|
|
|
|
check_existence = true;
|
|
|
|
break;
|
2020-09-30 23:50:47 +02:00
|
|
|
case 'h':
|
|
|
|
usage();
|
|
|
|
exit(0);
|
2020-10-10 11:36:17 +02:00
|
|
|
case 'i':
|
|
|
|
ignore_case = true;
|
|
|
|
break;
|
2020-10-08 20:49:30 +02:00
|
|
|
case 'l':
|
|
|
|
case 'n':
|
Do the access checking asynchronously if possible.
There are many issues involved:
- There's no access() support in io_uring (yet?), so we fake it
by doing statx() on the directory first, which primes the
dentry cache so that synchronous access() becomes very fast.
It is a bit tricky, since multiple access checks could be
going on at the same time, which the need to all wait
for the same statx() call.
- Not even all kernels support statx() in io_uring (support starts
from 5.6+).
- Serialization now becomes two-level, and more involved.
We don't have an obvious single counter anymore, so we need
to be able to start a docid without knowing how many candidates
there are (and thus, be able to tell Serializer that we are
at the end).
- Limit becomes more tricky, since there can be more calls on
the way back. We solve this by moving limit into Serializer,
and hard-exiting when we hit the limit.
- We need to prioritize statx() calls ahead of read(), so that
we don't end up with very delayed output when the new read()
calls generate even more statx() calls and we get a huge
backlog of calls. (We can't prioritize in the kernel, but we
can on the overflow queue we're managing ourselves.) This is
especially important with --limit.
2020-10-11 19:59:11 +02:00
|
|
|
limit_matches = limit_left = atoll(optarg);
|
2020-10-11 11:48:43 +02:00
|
|
|
if (limit_matches <= 0) {
|
|
|
|
fprintf(stderr, "Error: limit must be a strictly positive number.\n");
|
|
|
|
exit(1);
|
|
|
|
}
|
2020-10-08 20:49:30 +02:00
|
|
|
break;
|
2021-10-05 23:02:09 +02:00
|
|
|
case 'N':
|
|
|
|
literal_printing = true;
|
|
|
|
break;
|
2020-09-30 23:59:14 +02:00
|
|
|
case '0':
|
|
|
|
print_nul = true;
|
|
|
|
break;
|
2020-10-10 21:43:20 +02:00
|
|
|
case 'r':
|
|
|
|
patterns_are_regex = true;
|
|
|
|
break;
|
|
|
|
case EXTENDED_REGEX:
|
|
|
|
patterns_are_regex = true;
|
|
|
|
use_extended_regex = true;
|
|
|
|
break;
|
2020-10-17 09:46:55 +02:00
|
|
|
case 'w':
|
|
|
|
match_basename = false; // No-op unless -b is given first.
|
|
|
|
break;
|
2020-10-10 19:30:13 +02:00
|
|
|
case 'D':
|
|
|
|
use_debug = true;
|
|
|
|
break;
|
2020-10-16 00:48:23 +02:00
|
|
|
case FLUSH_CACHE:
|
|
|
|
flush_cache = true;
|
|
|
|
break;
|
2020-10-10 20:39:44 +02:00
|
|
|
case 'V':
|
|
|
|
version();
|
|
|
|
break;
|
2023-12-31 11:29:43 +01:00
|
|
|
case IGNORE_VISIBILITY:
|
|
|
|
ignore_visibility = true;
|
|
|
|
break;
|
2020-10-01 00:00:29 +02:00
|
|
|
default:
|
|
|
|
exit(1);
|
2020-09-30 23:50:47 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-12-31 11:29:43 +01:00
|
|
|
if (use_debug || flush_cache || ignore_visibility) {
|
2020-10-10 19:30:13 +02:00
|
|
|
// Debug information would leak information about which files exist,
|
|
|
|
// so drop setgid before we open the file; one would either need to run
|
2020-10-16 00:48:23 +02:00
|
|
|
// as root, or use a locally-built file. Doing the same thing for
|
|
|
|
// flush_cache is mostly paranoia, in an attempt to prevent random users
|
|
|
|
// from making plocate slow for everyone else.
|
2023-12-31 11:29:43 +01:00
|
|
|
// --ignore-visibility is obvious; if we allowed to keep sgid with
|
|
|
|
// that flag on, it would subvert the entire security model.
|
2020-10-10 19:30:13 +02:00
|
|
|
if (setgid(getgid()) != 0) {
|
|
|
|
perror("setgid");
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-29 23:42:01 +01:00
|
|
|
if (!print_nul) {
|
|
|
|
stdout_is_tty = isatty(1);
|
|
|
|
}
|
|
|
|
|
2020-10-10 11:36:17 +02:00
|
|
|
vector<Needle> needles;
|
2020-09-30 23:57:02 +02:00
|
|
|
for (int i = optind; i < argc; ++i) {
|
2020-10-10 11:36:17 +02:00
|
|
|
Needle needle;
|
|
|
|
needle.str = argv[i];
|
2020-10-10 19:18:52 +02:00
|
|
|
|
|
|
|
// See if there are any wildcard characters, which indicates we should treat it
|
|
|
|
// as an (anchored) glob.
|
|
|
|
bool any_wildcard = false;
|
|
|
|
for (size_t i = 0; i < needle.str.size(); i += read_unigram(needle.str, i).second) {
|
|
|
|
if (read_unigram(needle.str, i).first == WILDCARD_UNIGRAM) {
|
|
|
|
any_wildcard = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-10 21:43:20 +02:00
|
|
|
if (patterns_are_regex) {
|
|
|
|
needle.type = Needle::REGEX;
|
|
|
|
needle.re = compile_regex(needle.str);
|
|
|
|
} else if (any_wildcard) {
|
2020-10-10 19:18:52 +02:00
|
|
|
needle.type = Needle::GLOB;
|
|
|
|
} else if (ignore_case) {
|
2020-10-10 11:36:17 +02:00
|
|
|
// strcasestr() doesn't handle locales correctly (even though LSB
|
2020-10-10 19:18:52 +02:00
|
|
|
// claims it should), but somehow, fnmatch() does, and it's about
|
|
|
|
// the same speed as using a regex.
|
|
|
|
needle.type = Needle::GLOB;
|
|
|
|
needle.str = "*" + needle.str + "*";
|
2020-10-10 11:36:17 +02:00
|
|
|
} else {
|
|
|
|
needle.type = Needle::STRSTR;
|
2020-10-10 19:18:52 +02:00
|
|
|
needle.str = unescape_glob_to_plain_string(needle.str);
|
2020-10-10 11:36:17 +02:00
|
|
|
}
|
|
|
|
needles.push_back(move(needle));
|
2020-09-30 23:57:02 +02:00
|
|
|
}
|
|
|
|
if (needles.empty()) {
|
2020-10-01 00:00:04 +02:00
|
|
|
fprintf(stderr, "plocate: no pattern to search for specified\n");
|
2022-11-06 12:09:53 -08:00
|
|
|
exit(1);
|
2020-09-30 23:50:47 +02:00
|
|
|
}
|
2021-03-28 00:19:49 +01:00
|
|
|
|
|
|
|
if (dbpaths.empty()) {
|
|
|
|
// No -d given, so use our default. Note that this happens
|
|
|
|
// even if LOCATE_PATH exists, to match mlocate behavior.
|
|
|
|
dbpaths.push_back(DBFILE);
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *locate_path = getenv("LOCATE_PATH");
|
|
|
|
if (locate_path != nullptr) {
|
|
|
|
parse_dbpaths(locate_path, &dbpaths);
|
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t matched = 0;
|
|
|
|
for (size_t i = 0; i < dbpaths.size(); ++i) {
|
|
|
|
uint64_t this_matched;
|
|
|
|
if (i != dbpaths.size() - 1) {
|
|
|
|
this_matched = do_search_file_in_child(needles, dbpaths[i]);
|
|
|
|
} else {
|
|
|
|
this_matched = do_search_file(needles, dbpaths[i]);
|
|
|
|
}
|
|
|
|
matched += this_matched;
|
|
|
|
limit_left -= this_matched;
|
|
|
|
}
|
|
|
|
if (only_count) {
|
|
|
|
printf("%" PRId64 "\n", matched);
|
|
|
|
}
|
2022-11-06 12:09:53 -08:00
|
|
|
|
|
|
|
return matched == 0;
|
2020-09-27 22:53:35 +02:00
|
|
|
}
|