znajdź vs. zlokalizuj

30

Istnieją polecenia findi locatedo wyszukiwania plików na dysku.

Wiem, że findrekurencyjnie przetwarza wszystkie potrzebne podkatalogi do wyszukiwania plików i dlatego jest powolny, ale aktualny, podczas gdy locatekorzysta z bazy danych, która jest aktualizowana co jakiś czas (kiedy dokładnie?), Aby szybko wyświetlać wyniki, które mogą być nieaktualne.

Czy są jakieś inne różnice? W jakich sytuacjach jeden wolałby jedno lub drugie? A kiedy locatebaza danych jest zwykle aktualizowana?

Bajt Dowódca
źródło
1
manpages.ubuntu.com/manpages/trusty/man8/updatedb.8.html „aktualizacjab jest zwykle uruchamiana codziennie przez cron (8) w celu aktualizacji domyślnej bazy danych”.
Rinzwind
@Rinzwind Połączona odpowiedź U&L jest niesamowita, szkoda, że ​​nie możemy tworzyć duplikatów między witrynami. Ale czy wiesz więcej o koleżeństwie, kiedy dokładnie będzie działać? Po uruchomieniu? Tylko w określonym czasie (myślę, że przeczytałem 1-2 rano lub coś w tym rodzaju)? Co się stanie, jeśli zostanie zamknięty w tym czasie? Czy zaczyna się, gdy komputer jest bezczynny? Jak mogę sprawdzić wiek bazy danych?
Bajt Dowódca
2
@ByteCommander - Po to anacronjest. Nie wiem, czy jest domyślnie instalowany na komputerach / serwerach, ale na notebookach. Działa podczas rozruchu i sprawdza, czy jakieś zadania crona powinny były zostać uruchomione, gdy system był wyłączony, i uruchamia je. Jest to bardzo pomocne, ale może powodować pewne problemy, jeśli zadania są zaplanowane z dala od północy. Może to spowodować uruchomienie zadania przy rozruchu, a następnie ponownie, gdy nadejdzie czas - być może znacznie mniej niż 24 godziny później (w przypadku codziennej pracy).
Joe
@Joe Czy będzie on działał podczas rozruchu i spowalniał, czy będzie działał jakiś czas po rozruchu, czy też zwykle działa z tak niskim priorytetem, że działa po prostu, gdy system jest prawie bezczynny?
Bajt Dowódca

Odpowiedzi:

27

locatejest naprawdę dobry tylko do wyszukiwania plików i wyświetlania ich ludziom. Możesz zrobić z nim kilka rzeczy, ale nie ufałbym temu na tyle, aby parsować i - jak mówisz - nie można zagwarantować stanu wewnętrznej bazy danych, tym bardziej, że jest uruchamiana tylko /etc/cron.daily/mlocateraz dziennie!

findjest na żywo. Filtruje, wyklucza, wykonuje. Nadaje się do parsowania. Może generować ścieżki względne. Może generować pełne ścieżki. Może robić rzeczy na podstawie atrybutów, a nie tylko nazw.

locatez pewnością ma miejsce w moim zestawie narzędzi, ale zwykle jest na samym dole jako ostatnia próba znalezienia czegoś. To łatwiejsze niż findteż.

Oli
źródło
2
Uważam, że jestem locateznacznie szybszy, jeśli chcę przeszukać cały system plików. Możesz ręcznie zaktualizować bazę danych, używając jej updatedbprzed użyciem.
hytromo
Wiesz, jak dokładnie skonfigurowana jest ta cronjob? Czy działa w określonym czasie lub gdy system jest w stanie bezczynności lub n minut po uruchomieniu? Ponieważ myślę, że przeczytałem gdzieś, że jest zaplanowane na 1-2 rano, kiedy moja maszyna jest zwykle wyłączona. Czy nigdy nie zostanie zaktualizowany, z wyjątkiem ręcznego ( sudo updatedb)? Czy jest szansa, aby zobaczyć, ile lat ma baza danych?
Bajt Dowódca
grep run-parts /etc/crontabZobaczysz, że są one zarządzane przez anacron(które zobaczysz, man anacronjest bardziej odporny na systemy, które nie są włączone przez cały czas). Z tego, co widzę, powinno uruchomić się przy rozruchu, jeśli przegapisz oryginalny czas crona.
Oli
2
Uważam, że locate nie indeksuje moich wymiennych / odmontowanych partycji, więc jeśli chcę coś na nich znaleźć, muszę użyć find. Oczywiście locate nie ma wszystkich niesamowitych opcji, które ma find - na przykład -exec command {} \;uruchomienie polecenia na każdym znalezionym pliku. Lubię używać, locate -bktóre ogranicza lokalizowanie do wyszukiwania plików pasujących do końcowego komponentu nazwy - bez reszty ścieżki. Często próbuję tego pierwszego, ponieważ jest tak szybki. Ponadto można uruchomić w sudo updatedbdowolnym momencie, aby odświeżyć zlokalizowaną bazę danych.
Joe
jeśli potrzebujesz nieco prostszego wyszukiwania w czasie rzeczywistym, możesz użyć czegoś takiegols -R | grep 'file_name.txt'
jena
8

Tak bardzo, jak lubię Oli (co jest dużo!) Nie zgadzam się z nim na findpolecenie. Nie podoba mi się to

find polecenie trwa ponad trzy minuty

Weźmy na przykład to proste polecenie:

$ time find / -type f -name "mail-transport-agent.target"
find: ‘/lost+found’: Permission denied
find: ‘/etc/ssmtp’: Permission denied
find: ‘/etc/ssl/private’: Permission denied
    (... SNIP ...)
find: ‘/run/user/997’: Permission denied
find: ‘/run/sudo’: Permission denied
find: ‘/run/systemd/inaccessible’: Permission denied

real    3m40.589s
user    0m4.156s
sys     0m8.874s

To trwa ponad trzy minuty dla findszukać wszystko począwszy od /. Domyślnie pojawiają się ryzę komunikatów o błędach i musisz je przeszukać, aby znaleźć to, czego szukasz. Nadal jest lepsze niż grepprzeszukiwanie całego dysku w poszukiwaniu ciągu, który zajmuje 53 godziny : `grep`ing wszystkich plików w ciągu ciągu zajmuje dużo czasu

Wiem, że mogę manipulować parametrami polecenia find, aby działało to lepiej, ale chodzi tutaj o czas potrzebny do uruchomienia.

locate polecenie zajmuje mniej niż sekundę

Teraz użyjmy locate:

$ time locate mail-transport-agent.target
/lib/systemd/system/mail-transport-agent.target

real    0m0.816s
user    0m0.792s
sys     0m0.024s

Polecenie lokalizacji zajmuje mniej niż sekundę!

updatedb domyślnie uruchamiany tylko raz dziennie

Prawdą jest, że updatedbpolecenie aktualizujące lokalizację bazy danych jest domyślnie uruchamiane tylko raz dziennie. Możesz uruchomić go ręcznie przed wyszukaniem właśnie dodanych plików, używając:

$ time sudo updatedb

real    0m3.460s
user    0m0.503s
sys     0m1.167s

Chociaż zajmie to 3 sekundy, jest to małe w porównaniu do find3+ minut polecenia.

Zaktualizowałem mój, sudo crontab -eaby zawierał wiersz u dołu:

# m h  dom mon dow   command
  0 0  1   *   *     /bin/journalctl --vacuum-size=200M
*/5 *  *   *   *     /usr/bin/updatedb

Teraz co pięć minut updatedbjest uruchamiana, a locatebaza danych poleceń jest prawie zawsze aktualna.

Ale nie ma atrybutów?

Możesz locateprzesyłać dane wyjściowe do innych poleceń. Jeśli na przykład chcesz atrybuty pliku, możesz użyć:

$ locate mail-transport-agent.target | xargs stat
  File: '/lib/systemd/system/mail-transport-agent.target'
  Size: 473         Blocks: 8          IO Block: 4096   regular file
Device: 10305h/66309d   Inode: 667460      Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2018-03-31 18:11:55.091173104 -0600
Modify: 2017-10-27 04:11:45.000000000 -0600
Change: 2017-10-28 07:18:24.860065653 -0600
 Birth: -

Podsumowanie

Opublikowałem tę odpowiedź, aby pokazać szybkość i łatwość użycia locate. Próbowałem poradzić sobie z niektórymi niedociągnięciami w dowodzeniu wskazanymi przez innych.

findKomenda musi przemierzyć całą strukturę katalogów, aby znaleźć pliki. locateKomenda ma własną bazę danych, która daje mu błyskawicznie w porównaniu.

WinEunuuchs2Unix
źródło
@EliahKagan Ale polecenie find przewijało i wyświetlało listę wszystkich katalogów i plików na wszystkich dyskach jako partycje. Wyglądało na to, że działa i spodziewałem się wydruku na końcu ... W każdym razie nie chodziło o „naprawienie” wyszukiwania polecenia find, chodziło o znalezienie czasu. Uruchomienie locate / display-auto-brightnesszajmuje 17 sekund, a także wyświetla każdy katalog i plik na wszystkich dyskach.
WinEunuuchs2Unix
@EliahKagan Rozumiem. --regexbyło konieczne, ponieważ z moim ciągiem wyszukiwania zwróciło się zbyt wiele wyników. Znajdę dwa nowe przykłady znajdowania, lokalizowania i aktualizowania mojej odpowiedzi za kilka minut.
WinEunuuchs2Unix
1
Aby wyjaśnić punkt Eliasza, to findpolecenie oznacza „wydrukuj nazwy wszystkich plików w katalogach /i display-auto-brightness”. Myślę, że chciałeś użyć find / -name display-auto-brightness, ale nawet to drukuje wiele niepotrzebnych błędów „Odmowa zezwolenia”.
wjandrea
@wjandrea Tak, jak powiedziałem, nie chodzi o to, aby znaleźć plik, chodziło o czas polecenia find. Ponownie uruchamiam testy z poprawnymi parametrami po opróżnieniu pamięci podręcznej. Potem zaktualizuję odpowiedź.
WinEunuuchs2Unix
1
@Win Nie, twój przykład jest nadal aktualny i nie sądzę, aby czas przetwarzania zmienił się znacznie, niezależnie od tego, czy plik został znaleziony, czy nie.
wjandrea,