Názory k článku
Jak na problémy s umountem
-
:-)) (neregistrovaný)
To mate asi tak:
1.nefunguje odpojeni USB disku ve widlich, tak si s tim bude hrat do zblbnuti pripadne se pusti do reinstalace.
2. nefunguje odpojeni USB disku v linuxu ktery si nainstaloval pred 10 minutami, tak se pusti do formatovani disku a odstranovani linuxu.
MSfans nemaji soudnost.
-
Moc problemu jsem s tim zatim nemel. Vetsinou takhle odpojuju jenom pripojene sshfs. Problem vznikne (alespon co vim) kdyz „chcipne“ program, ktery dane umisteni pak nadale blokuje. Stane se z nej pak zombie, ktera visi na nedokoncene IO operaci. Nevim presne, jak to funguje, ale kdyz jsem naposled takovou zombie proste ignoroval, tak po nejakem timeoutu ji system sam zlikvidoval… ;-) (ale mozna, ze si to jen namlouvam).
-
Proč tak komplikovaně. Něco takového pomůže prakticky vždy:
#!/bin/sh VOLUME="$1" # Pošli TERM blokujícím aplikacím. fuser -mk -TERM "/media/$VOLUME" # Dej čas na korektní ukončení. sleep 3 # Zlikviduj zbytek pomocí -KILL fuser -mk "/media/$VOLUME" # Odpoj zařízení if ! umount "/media/$VOLUME" ; then # A pokud zůstal nějaký proces zamčený v kernelu, udělej lazy umount. umount -l "/media/$VOLUME" fi
-
Skript pouštím, když chci médium odpojit, ne když na něm mám něco otevřeného.
Takový zapomenutý proces má prostě smůlu. Nemá co sahat na disk, který chci právě odpojit. Stejně to je většinou jen mc (ten to dělá často), zapomenutý shell nebo nějaký prohledávací démon.
Na každodenní používání je lepší desktopové odpojování nebo obyčejný umount. Toto je poslední záchrana, když se nechci zabývat, který z 10 puštěných mc je ten, co stojí v adresáři na flashce.
-
Jiří J. (neregistrovaný)
Taky už se mi stalo :) .. konkrétně šlo o jackd, ale stávalo se to i jiným procesům. V dmesg nic zajímavého, dodnes nevím, co brání kernelu prostě zastavit přidělování CPU time danému procesu a uvolnit místo v paměti.
Ohledně mountu – nikdy jsem nepochopil, proč rm -rf /* jde tak snadno, ale věci jako umount (třeba NFS – dříve, teď už to jde) tak spolehlivé nejsou. Co když mě absolutně nezajímá, že je tam nějaký file deskriptor otevřený, že po super-force-unmountu ten process asi segfaultí nebo dostane I/O error (read/write vrátí –1), proč sakra nejde svazek odpojit.
Asi to bude filesystémem a nějakou souvislostí mezi fd a ním, nevím. Jen mi připadne, že přístup „neunmountneme to za žádnou cenu, protože nějaký směšný userspace process to využívá“ je stejně nesmyslné jako „nedovolíme to remountnout readonly, protože by to mohlo ublížit nějakému procesu“ (kde musím remount vynutit přes sysrq nebo vyvoláním chyby na filesystému), což mi přijde stejně, s prominutím, dementní, jako windows-like „soubor nemůže být smazán, protože jej něco využívá“.
Varování je dobré, ale neschopnost –force parametru ne ..
