umount po `mount --bind`: device is busy

[ultr]

Witam.


Binduję katalog poleceniem:
# mount --bind /home/ultr /jakis/katalog

Potem odpalam jakiś program uzywajacy /jakis/katalog

Gdy chcę odmontować:
# umount /jakis/katalog
oczywiście pojawia się błąd, że system plików jest w użyciu.

I tu pojawia się problem.
Chciałbym zabić procesy używające /jakis/katalog, żeby móc go odmontować.
Niestety polecenie:
# fuser -k /jakis/katalog
zabija wprawdzie program używający /jakis/katalog, ale niestety również inne używające oryginalnego /home/ultr, czyli m.in. cały desktop :/

Ma ktoś pomysł, jak zabić tylko te programy używające podbindowanego katalogu? Albo jak inaczej zmusić system do odmontowania go?


Dzięki i pozdrawiam.

[arctgx]

Czy jest w ogóle możliwe, bez zabicia programów, przeniesienie systemu plików pod nową ścieżkę, kiedy działające programy (lsof $HOME) korzystają ze starych ścieżek?

Menedżer okien (też korzysta z $HOME) w mojej sesji zastępuje proces ~/.Xsession i jeśli go zabiję (a też korzysta ze starej ścieżki), zabijam całą sesję X. Dlatego wydaje mi się naturalne wspomniane zabicie programów fuserem (przenosiny np. w konsoli) i sam nie mam pomysłu na inne wyjście.

[ultr]

No tak. Tylko ja nie przenoszę systemu plików, tylko kopiuję drzewo w inne miejsce.

I chcę zabić procesy blokujące odmontowanie go, czyli używające nowego drzewa. Stare procesy używające oryginalnego $HOME mają zostać.

[micu]

arctgx: teoretycznie sytuacja powinna być zbliżona do tej gdy usunięto/przesunięto otwarte pliki (czyli można - na pewno dane pliku czyli "urządzenie + i-node" się nie zmieniają). I jest jeszcze coś takiego jak "mount --move" (nie próbowałem).

ultr: ciekawy problem poruszyłeś :-) Zgodnie z dokumentacją "bindowanie" jest załatwiane przez VFS (czyli nie zależy od rzeczywistego typu systemu plików). Z tego względu podejrzewam że jesteśmy skazani na 'fuser -k' które zabija wszystko (niezależnie od ścieżki to są te same i-węzły na jednym urządzeniu). Rozwiązanie które przychodzi mi do głowy to np. skryptowe "ściganie" procesów po ścieżkach do otwartych plików (można wykorzystać /proc/PID/cwd i /proc/PID/fd/*).

Pozdrawiam
Micu

[ultr]

Mam coś takiego. Wygląda, że działa:

Kod: [Zaznacz]

SCIEZKA="/jakis/katalog"
while read pid; do
  [ "`lsof -Fn -p ${pid} | grep -e "^n/${SCIEZKA}.*$" -c`" -gt 0 ] && kill -9 ${pid}
done < <( lsof -t "$SCIEZKA" )

[arctgx]

Przyznaję się do działania z pamięci zamiast zajrzenia do (angielskiego czyli aktualniejszego) podręcznika mount na potrzeby odpowiedzi. Bind to rzeczywiście udostępnienie tych samych i-węzłów systemu plików pod nową ścieżką przy zachowaniu przypisań do nich za pomocą starej ścieżki (przenosiny robimy przez "move").

No ale program chyba odwołuje się nie wprost do i-węzła, a do pewnej ścieżki do niego przypisanej. Stąd moja intuicja. Czy programowi (lub jakiejś warstwie niżej, z której on korzysta by dobierać się do plików) można powiedzieć, że okupowany przez niego i-węzeł zmienił w tym momencie ścieżkę?

[micu]

No ale program chyba odwołuje się nie wprost do i-węzła, a do pewnej ścieżki do niego przypisanej. Stąd moja intuicja. Czy programowi (lub jakiejś warstwie niżej, z której on korzysta by dobierać się do plików) można powiedzieć, że okupowany przez niego i-węzeł zmienił w tym momencie ścieżkę?

Przy otwieraniu (open()) podajesz scieżkę, ale później operujesz już na deskryptorze który zawiera m.in. numer i-węzła. Na pliku można zrobić "rm" lub "mv" a mimo to jest on dostępny dla operacji typu read(), write(), seek() itp (to różni UNIXy od np. Windows). Natomiast Twoje pytanie jest dużo ogólniejsze i zaawansowane niż opisana wyżej sytuacja (bo operacje typu "mv" czy "ln" nie dotykają ścieżek zapisanych w strukturach procesu opisujących już otwarte pliki).
Pozostaje zagłębienie się w "Linux kernel internals", nagłówki, VFS, task_struct itp . Tak "z głowy" to wymiękam :-P

Pozdrawiam
Micu

[arctgx]

Pozostaje mi nic innego jak któregoś dnia zobaczyć kod i opisy funkcji open i podobnych działań na plikach, a potem wykonać proste, ale solidne ćwiczenie weryfikujące mój chłopski rozum (napisać prosty programik otwierający plik, po czym zrobić "bind" albo nawet rm). W każdym razie dzięki za próbę rozjaśnienia - zawsze to daje namiary, gdzie szukać.

Teraz zostawiam tylko małe streszczenie sytuacji, którą opisuje ultr:

Kod: [Zaznacz]

  arctgx # mount | grep -E '/q/z|/q/s'
/dev/sdb1 on /q/z type vfat (rw,noexec,nosuid,nodev,umask=0,iocharset=iso8859-2,codepage=852,quiet)
  arctgx # mount --bind /q/z /q/s
  arctgx # mount | grep -E '/q/z|/q/s'
/dev/sdb1 on /q/z type vfat (rw,noexec,nosuid,nodev,umask=0,iocharset=iso8859-2,codepage=852,quiet)
/q/z on /q/s type none (rw,bind)
  arctgx # cd /q/z
  z # umount /q/z/
umount: /q/z: device is busy
umount: /q/z: device is busy
  z # cd /q/s
  s # umount /q/z/
  s # mount | grep -E '/q/z|/q/s'
/q/z on /q/s type none (rw,bind)
  s # cd; umount /q/s/

...ale zrobiłem ciekawe doświadczenie z move:

Kod: [Zaznacz]

  ~ # mount | grep -E '/q/z|/q/s'
/dev/sdb1 on /q/z type vfat (rw,noexec,nosuid,nodev,umask=0,iocharset=iso8859-2,codepage=852,quiet)
  ~ # cd /q/z/
  z # mount --move /q/z /q/s
  z # lsof /q/z/
  z # lsof /q/s
COMMAND   PID USER   FD   TYPE DEVICE SIZE NODE NAME
bash    16045 root  cwd    DIR   8,17 8192    1 /q/s
lsof    16960 root  cwd    DIR   8,17 8192    1 /q/s
lsof    16961 root  cwd    DIR   8,17 8192    1 /q/s
  z # find | wc -l
646
  z # find /q/z | wc -l
1
  z # find /q/s | wc -l
646
  z # mount | grep -E '/q/z|/q/s'
/dev/sdb1 on /q/s type vfat (rw,noexec,nosuid,nodev,umask=0,iocharset=iso8859-2,codepage=852,quiet)
  z # cd
  ~ # cd -
/q/z
  z # find | wc -l
1

Może lepiej więc, ultr, gdybyś użył move? Widać, że bash, póki używa /q/z/, po zrobieniu "move" ma jeszcze dostęp do starych ścieżek (find wyświetla pliki pendrajwa).

P.S. @micu, mały wniosek z ćwiczenia: bash (16045) podczas przesunięcia nie protestował przeciw zmianie ścieżki. To zdaje się potwierdzać Twój opis: bash odwoływał się do katalogu za pomocą innego namiaru niż ścieżka (być może jest to wspomniany i-węzeł). Czyżby kawałek ćwiczenia z głowy?

[micu]

Mam nadzieję że podzielisz się z nami rezultatami Twoich badań, arctgx ! :-)

Co do dostępu po deskryptorze (czyli i-węzeł a nie ścieżka) to jest to powodem "słynnych" problemów z różnicami w wynikach 'du' i 'df' oraz z czyszczeniem filesystemów które nie zwalnia tyle miejsca ile chcieliśmy. Zapewne wiecie o co chodzi, nie chcę tutaj zanudzać :-)

@arctgx: ciekawe doświadczenie z 'move', jak widać nie jest to po prostu "bardzo szybki" umount+mount :-) W man-ie napisali że jest to robione 'atomically' więc spójność zostaje zachowana i nic nie ginie - wygodne narzędzie. Do tego ciekawie działa - choć myślę że 'lsof' identyfikuje nową ścieżkę mimo że już działające procesy nadal widzą starą (chyba nie zmienia struktur w task_struct->...) - ale to tylko przeczucie (do weryfikacji).

Pozdrawiam
Micu

[arctgx]

Mam tylko nadzieję, że ten eksperymencik (miał być najprostszy jak tylko możliwe) pokazałem tak, że mówi w swoich detalach sam za siebie (choćby cd, którym bash uwalnia zajęty w momencie przesuwania /q/z z zawartością, a po powrocie już nic stamtąd nie sięgnie prócz samego /q/z - stąd 1 na końcu).

Jeśli chodzi o miejsce z df i du, to chyba wczoraj ra-v rzucił bliskie pytanie: http://forum.linux.pl/viewtopic.php?pid=91332#p91332