Szybko znajdź plik (i) należący do określonego numeru i-węzła

Znam to polecenie:

find /path/to/mountpoint -inum <inode number>

ale jest to bardzo powolne wyszukiwanie, wydaje mi się, że musi istnieć szybszy sposób, aby to zrobić. Czy ktoś zna szybszą metodę?

files search inode

— Alex
źródło

Po raz pierwszy widzę wyszukiwanie za pomocą i-węzła. Kiedy trzeba szukać według i-węzła?

— Coren

@Coren - jest powszechnie używany, jeśli masz plik z, powiedzmy, „-” z przodu. Możesz zrobić ls -li, aby znaleźć i-węzeł, a następnie: find. -inum <węzeł> -exec rm -i {} \; Jest to podejście typu pas-and-bracers zapewniające, że możesz usunąć plik. Oczywiście możesz również użyć polecenia „rm - -filename” lub rm ./-filename lub rm „-filename”.

— szwajcarski

@Coren z selinux, komunikaty dziennika zawierają i-węzeł, ale nie pełną ścieżkę. Musisz więc wyszukać i-węzeł, aby znaleźć plik, do którego następuje odwołanie. (i tak to mój przypadek użycia)

— Patrick

@Coren Na przykład, gdy plik ma wiele dowiązań twardych, zauważyłeś, że zawartość jest przestarzała i chcesz usunąć plik, ale znalazłeś tylko jedną z nazw pliku i chcesz usunąć pozostałe.

— Gilles „SO- przestań być zły”

Po prostu użyj find / -inum <inode>. Jest o wiele bardziej przenośny niż, debugfsa także działa o wiele bardziej niezawodnie (może znajdować ścieżki, które nie należą do plików na dysku twardym, na przykład urządzenia).

— 7heo.tk

Odpowiedzi:

W przypadku systemu plików ext4 można użyć debugfsjak w poniższym przykładzie:

$ sudo debugfs -R 'ncheck 393094' /dev/sda2 2>/dev/null
Inode   Pathname
393094  /home/enzotib/examples.desktop

Odpowiedź nie jest natychmiastowa, ale wydaje się lepsza niż find.
Uzyskane dane wyjściowe można łatwo przeanalizować w celu uzyskania nazwy pliku.

— enzotib
źródło

Prawdopodobnie powinienem był określić typ systemu plików. Nie przyszło mi do głowy, że metoda wykonywania tych czynności będzie różna dla różnych systemów plików. Używam XFS, więc chociaż jestem pewien, że twoja odpowiedź jest prawidłowa, nie pomoże mi to konkretnie.

— Alex

btrfs

man btrfs-inspect-internal mówi:

   inode-resolve [-v] <ino> <path>
       (needs root privileges)

       resolve paths to all files with given inode number ino in a given
       subvolume at path, ie. all hardlinks

       Options

       -v
           verbose mode, print count of returned paths and ioctl()
           return value

Przykład:

sudo btrfs inspect-internal inode-resolve 15380 /home

— Tom Hale
źródło

Jestem pewien, że możesz spojrzeć na komendę fsdb, znalezioną na większości Uniksów i dostępną gdzieś w Linuksie. Jest to potężne polecenie umożliwiające dostęp do wewnętrznej struktury i-węzłów plików, więc bądź ostrożny. Składnia jest również bardzo zwięzła.

fsdb dla AIX

Plik fsdb ponownie łączy w systemie Solaris

Choć FSDB nie będzie faktycznie pozwalają odkryć nazwa pliku z węzła, to nie pozwala na bezpośredni dostęp do iwęzeł gdy podasz go w istocie „przeniesieniem” do samego (lub przynajmniej jest to blok danych pointers) pliku, tak to jest szybciej pod tym względem niż znalezisko ;-).
Twoje pytanie nie określa, co chcesz zrobić z plikiem. Czy na pewno dekodujesz uchwyty plików NFS?

sc.

— ser szwajcarski
źródło

Cóż, nie sądziłem, że to, co zrobię z informacjami, jest istotne dla mojego pytania, więc je pominąłem. W moim przypadku było to jedynie pytanie o ciekawość; moja defragmentacja xfs_fsr wypluwa, które i-węzły defragmentuje, a jedna była bardzo rozdrobniona (ponad 5000 zakresów) i byłem po prostu ciekawy, który to plik. finddziała, jest tak powolny.

— Alex

Próbuję naprawić problem polegający na tym, że mój rhel vm wykonuje pełny (20 minut!) Fsck przy każdym rozruchu, a wszystko, co muszę kontynuować, to numer i-węzła zgłoszony w / var / opt / messages jako wadliwy. (Powiedziawszy to, znajdź -inum tak naprawdę go nie znalazło)