rinominare una cartella enorme: è rischioso?


19

È rischioso rinominare la cartella con 180 GB con il mvcomando?

Abbiamo una cartella /datache contiene 180 GB.

Vogliamo rinominare la /datacartella /BD_FILEScon il mvcomando.

È sicuro farlo?


14
Perché e come dovrebbe essere rischioso? Se non sei sicuro, chiama mvcon l' -iopzione.
dessert

5
C'è qualcosa nel tuo ambiente che ti porta a pensare che potrebbe essere rischioso?
Jeff Schaller

2
Vuoi dire se c'è il rischio che l'atto in sé e per sé possa causare un problema o se c'è il rischio che possano esserci effetti problematici? Se si dispone di programmi che prevedono una cartella / data, la ridenominazione potrebbe causare problemi.
Accumulo

3
Nota a margine: quasi tutto è sicuro se hai verificato i backup. Niente è sicuro come dovrebbe essere se non lo fai. In altre parole: quando chiedi "è sicuro", il tuo primo pensiero dovrebbe essere "ho verificato i miei backup?"
RedGrittyBrick,

2
Intendo il rischio che potrebbe essere problematico quando si sposta una cartella enorme con i dati da questo sistema operativo, ad esempio, si potrebbe fermare lo spostamento nel mezzo o la
perdita di

Risposte:


71

La modifica del nome su una cartella è sicura, se rimane all'interno dello stesso file system.


Se è un punto di montaggio ( /datasembra che potrebbe essere un punto di montaggio per me, controlla questo con mount), allora devi fare qualcosa di diverso da un semplice mvdato mv /data /BD_FILESche sposterebbe i dati nella partizione di root (che potrebbe non essere ciò che vuoi succedere).

Dovresti smontare il filesystem, rinominare la directory ora vuota, aggiornare /etc/fstabcon la nuova posizione per questo filesystem e quindi rimontare il filesystem nella posizione rinominata.

In altre parole,

  1. umount /data
  2. mv /data /BD_FILES(supponendo /BD_FILESche non esista già, in quel caso, spostalo prima di tutto)
  3. aggiornamento /etc/fstab, cambiando il punto di montaggio da /dataa/BD_FILES
  4. mount /BD_FILES

Ciò non comporta la copia di alcun file, ma cambia semplicemente il nome della directory che funge da punto di montaggio per il filesystem.


Se la ridenominazione della directory comporta lo spostamento in un nuovo file system (che sarebbe il caso se si /datatrova su un disco mentre si /BD_FILEStrova su un altro disco, una cosa comune da fare se si spostano le cose in una partizione più grande, per esempio) , Consiglierei di copiare i dati lasciando intatto l'originale fino a quando non è possibile verificare che la copia sia corretta. Puoi farlo con

rsync -a /data/ /BD_FILES/

ad esempio, ma consultare il rsyncmanuale per ciò che fa e non fa (ad esempio, non mantiene i collegamenti reali).


Dopo aver rinominato la cartella, è inoltre necessario assicurarsi che le procedure esistenti (programmi e utenti che utilizzano la cartella, i backup ecc.) Siano a conoscenza della modifica del nome.


9
C'è il rischio che ci si aspetti mvdi fare una renamechiamata di sistema, ma a causa di circostanze non ci si è resi conto che sta per copiare i file ed eliminare l'originale. Se devo essere assolutamente certo che renameviene fatta solo una chiamata di sistema e mvnon ho intenzione di fare qualcosa di "intelligente" alle mie spalle, apro una shell Python e la utilizzo os.rename.
Kasperd,

3
Con un kernel Linux relativamente recente puoi invece spostare il mount point:mkdir /BD_FILES && mount -M /data /BD_FILES && rmdir /data
David Foerster il

2
@MichealJohnson Probabilmente funzionerà su un sistema Linux, sì. La cosa bella rsyncè che è riavviabile.
Kusalananda

3
@MichealJohnson Uno usa gli strumenti che uno si sente più a suo agio, ovviamente. Sì, rsync -aconserva quasi tutti i metadati, ma non i collegamenti fisici, gli ACL o gli attributi estesi (aggiungi -HAXper quello).
Kusalananda

3
@Max Diverse distribuzioni hanno renamecomandi diversi con comportamenti diversi. Penso che sia una ragione sufficiente per non usare il renamecomando quando vuoi essere certo di cosa farà.
Kasperd,

16

Non stai rinominando tutti i file nella directory, stai rinominando un file in /. È perché:

  1. le directory sono file e
  2. il file system si preoccupa davvero dell'inode, non del testo reale.

Pertanto, rinominare una directory, non importa quanti file o quanti dati siano in essa contenuti, è banale.


14

Se si rinomina (origine e destinazione nello stesso file system), si tratta semplicemente di una ridenominazione di una voce della directory. O ha esito positivo e la directory ha un nuovo nome oppure non riesce, nel qual caso non cambia nulla * .

Se l'origine e la destinazione si trovano su file system diversi, i dati devono essere copiati mv. Le differenze nelle funzionalità del file system, come la dimensione massima del file, le limitazioni nei nomi dei file, ecc., Possono causare problemi. Per evitare problemi, i file prima copia ( cp, rsync, ...) e dopo la copia viene completata correttamente, rimuovere i file nella posizione originale.

* Comunque ci sono alcuni casi angolari, ad esempio menzionati nella sezione BUGS in rename man 2


> "O ha esito positivo e la directory ha un nuovo nome oppure non riesce, nel qual caso non cambia nulla". Com'è garantito? È vero per tutti i filesystem? Ci sono dei documenti a riguardo?
turbante

Rinomina è un singolo syscall, tuttavia è presente una nota su NFS nella sezione BUGS di man rename : la ridenominazione può avere esito positivo anche quando viene restituito un errore quando si utilizza NFS (vedere i dettagli nella pagina man). Ho aggiunto anche una nota nella risposta. Non mi aspetto che nessun file system nel kernel lo consideri accettabile perché una voce di directory svanisca in caso di errore nel rinominare.
sebasth,

8

Come altri hanno già detto, rinominare una cartella non comporta rischi intrinseci per il contenuto. Ma esiste un diverso tipo di rischio che potresti voler prendere in considerazione.

Procedure esistenti, script, scorciatoie definite dall'utente e configurazioni che fanno riferimento alla posizione originale potrebbero essere interrotte da questa modifica e, se i percorsi sono memorizzati in un database, ad esempio, aggiornarli potrebbe essere un grosso lavoro.

Una cosa che puoi fare è creare un collegamento simbolico per il nuovo nome della directory, ma lasciare il vecchio nome in posizione per un po '. Ciò ti darà il tempo di valutare l'impatto di questo cambiamento. Puoi rimuovere temporaneamente il vecchio nome, vedere se ci sono problemi e, in tal caso, ricreare il vecchio nome in modo che le persone possano continuare a lavorare mentre capisci cosa deve essere aggiornato.

Un comando simile a questo dovrebbe farlo: ln -s /data /BD_FILES


4
Un altro rischio lieve che nessuno ha ancora menzionato è che, a seconda della strategia di backup per quella cartella, potrebbe causare problemi di spazio su disco e latenza sull'unità di backup a causa della comparsa improvvisa di 180 GB di "nuovi" dati, che devono essere eseguire il backup.
Kent,

Preferisco qualcosa del genere mv thing1 thing2 ; ln --symbolic ./thing2 thing1. In questo modo ho il nuovo nome e posso facilmente testare l'assenza del vecchio eliminando il collegamento simbolico.
can-ned_food,

3

Rinomina è atomico. L'unico rischio ragionevole è che mvdecide di copiare tutto per qualche motivo e che si blocca a metà. Se hai GNU mv, mv -Trimuoverà questo rischio.

mv -Tdice mvche si sta spostando in una non cartella; che lo farà rifiutare di fare e mkdir()che a sua volta provocherà il fallimento se si sposta una cartella e ha deciso di copiarlo per qualche motivo.

Sono stato coinvolto nel rimuovere gli insetti mv -Tmentre lavoravo alla tesi del mio maestro anni fa. In passato faceva la cosa sbagliata in troppi casi limite.

D'altra parte, hai 180 GB di dati utente sulla partizione di root. Probabilmente vuoi spostarlo dalla partizione di root.


Non si può dire dal solo nome se qualcosa è nella "partizione di root" o no.
Peter,

@Peter: se non si trova sulla partizione root è un mountpoint. Non è possibile rinominare i mountpoint montati con il comando mv.
Giosuè,
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.