Smontaggio di dispositivi rimovibili (eSATA, memoria USB) in Linux


4

Un dispositivo rimovibile come eSATA, unità USB può essere rimosso bruscamente (semplicemente staccando la spina).

Se sono presenti handle di file aperti su una partizione, queste partizioni non verranno smontate, ovvero Linux umount il comando fallirà, anche dopo che l'unità è fisicamente staccata.

Se lo smontaggio non riesce, quindi su riattacco del dispositivo, il mount fallirà pure. Quindi devi scoprire quali processi stanno usando l'unità e ucciderli o chiudere tutti gli handle. Se non puoi farlo, dovrai riavviare la scatola per far montare l'unità. E non posso assolutamente uccidere il processo che lo usa.

Non vedo l'opzione "Forza smontaggio", c'è a -f opzione, ma è solo per NFS.

Questo suona molto strano, Linux non accetta questo scenario in cui un utente semplicemente strappa un disco? Qualcuno sa come gestire questo scenario con garbo in Linux?

C'è un modo per scoprire quali handle di file sono aperti su una particolare partizione / dispositivo o per chiudere e chiudere selettivamente tutti gli handle di file solo per un particolare dispositivo?

Notare la lsof il comando non è disponibile nel Linux incorporato che sto usando (busybox).


"fuser" non è disponibile nel mio Linux incorporato.

Ho provato il pigro umount -l. Tuttavia, non sembra funzionare in modo coerente. Dì per es. Mantengo aperto un handle di file (con "tail -f" su qualche file sul dispositivo). Quindi rimuovo un'unità e poi eseguo "umount -l" e smonta. E poi riattacco l'unità e provo a montarla di nuovo sullo stesso punto di montaggio, mentre la coda è ancora in esecuzione. Non funziona in modo coerente. A volte succede e talvolta no. Questo mi mette a disagio nell'usare l'opzione lazy e se lascia il file system in uno stato incoerente. E inoltre non sono sicuro se questa opzione pigra fosse pensata per essere utilizzata per tali scenari.

Non riesco a terminare il processo con maniglie di file aperte.


Sembra che se ho montato il dispositivo su / mnt / abc e se disconnetto l'unità e poi riconnetti, Linux sembra riattaccare il file system del dispositivo allo stesso punto di mount "/ mnt / abc", senza che noi facciamo nulla smontare o montare. E poi lo stesso vecchio handle di file aperti sembra iniziare a funzionare dopo il ricollegamento (almeno per l'operazione di lettura dei file). Questa è la mia osservazione. Non sono sicuro se questo è il comportamento previsto .. Tuttavia, anche questo non sembra funzionare in modo coerente.

Avevo un handle di file aperto per la lettura ("tail -f") che ho lasciato aperto, quindi ho rimosso e ricollegato e poi modificato il file in coda e ho visto l'output "tail -f" che veniva aggiornato con le modifiche. Tuttavia, se provo a modificare un file dopo che il dispositivo è scomparso (dà un errore come previsto) e quindi ricollego, il file system del dispositivo non viene correttamente riattaccato allo stesso punto di montaggio. In caso di scrittura di un file (mentre il dispositivo non era lì) non sembra funzionare.

C'è un comportamento standard / coerente che Linux segue quando un'unità viene rimossa bruscamente senza chiudere tutti i manici e smontare correttamente tutte le partizioni?

Risposte:


3

È possibile scrivere uno script bash per eseguire la scansione di tutti i descrittori di file elencati in /proc (supponi di averlo) ed elenca / uccidi i processi.

/proc/$m/fd/$n è l'n-esimo descrittore di file per PID presentato come collegamento simbolico. busybox ha il supporto per il readlink, quindi dovresti essere in grado di automatizzarlo.

Modifica: solo per dire questo è essenzialmente ri-attuazione lsof, ma in realtà è abbastanza semplice.


Grazie per la risposta. Ma dal file fd presente in / proc / $ m / fd posso scoprire a quale dispositivo o volume appartiene. Ho bisogno di questo, ho bisogno di chiudere i dischi del dispositivo rimovibile (eSATA) SOLO in caso di disconnessione e non gli altri che potrebbero essere un socket fd o un file handle sul dispositivo interno.
solidstate

Esiste un modo affidabile per scoprire quale handle fd / file (dal / proc) appartiene a quale dispositivo e volume?
solidstate

Mi dispiace per aver risposto così tardi. Un modo di base / (non così affidabile) per farlo è quello di usare readlink per ottenere il percorso i FDS sono puntati e confrontarli con il punto di montaggio elencato da mount. Per esempio. qualcosa di simile a if readlink $fd | grep ^$mount-point ; then .... fi
billc.cn

Grazie billc.cn. Ma perché dici che non è "così affidabile", cosa c'è di sbagliato in questo approccio. Quando potrebbe dare risultati sbagliati?
solidstate

1
Ho già controllato questo. Se un file aperto con un comando "tail -f" è un collegamento simbolico e se viene visualizzata la voce proc / & lt; pid & gt; / fd, il file fd indicherà il file effettivo e non il collegamento. Quindi readlink & lt; fd & gt; restituirà il percorso al file attuale. E anche se non credo che si possa fare di nuovo il readlink, sul percorso restituito, in un ciclo per ottenere il file di destinazione.
solidstate

2

Puoi usare lsof per elencare i file aperti in una determinata directory usando lsof +D /path/to/mountpoint.


Grazie per la risposta. In realtà lsof non è disponibile nel linux embedded che sto usando. lsof non è disponibile in busybox.

lsof di semplici troll attraverso le directory proc / ## / fd per-process - quasi sicuramente hai un filesystem / proc in questi giorni. In questo modo è possibile effettuare il porting di lsof o duplicare facilmente la sua funzionalità. È probabile che sia già disponibile come opzione in busybox che semplicemente non hai abilitato nella tua build.
Chris Stratton

1

Hai provato:

umount -l /path/to/mountpoint
O

fuser -km /path/to/mountpoint
?


Ok, quindi i miei suggerimenti precedenti non hanno funzionato. So che potrebbe essere stupido, ma in realtà hai provato:

umount -f /path/to/mountpoint

Secondo la documentazione di Busybox dovrebbe essere l'opzione di smontaggio forzato (che mostra NFS come esempio).

Se ciò non funziona, hai provato:

eject -s /dev/my-sata-or-usb-device


Secondo l'OP, fuser non è disponibile, e umount -l non funziona in modo coerente (vedi le modifiche alla domanda)
slhck

Non eravamo lì quando ho postato, eh. Bene, questo uccide le mie idee. :(
Justin Pearce

Grazie. espulsione non disponibile umount -f non funziona (anche dopo che l'unità è scollegata fisicamente e c'è un handle di file aperto - "tail -f") dice umount: non può forzare umount / mnt / abc: dispositivo o risorsa occupato
solidstate

Sono fuori di idee, mi dispiace. :(
Justin Pearce

0

Una soluzione rapida quando ti manca lsof sarebbe find /proc/*/fd | xargs readlink | grep /mount_point sostituendo mount_point con il punto di montaggio effettivo. Questo è basato sulla risposta di billc.cn sopra.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.