È 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?
È 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?
Risposte:
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,
umount /datamv /data /BD_FILES(supponendo /BD_FILESche non esista già, in quel caso, spostalo prima di tutto)/etc/fstab, cambiando il punto di montaggio da /dataa/BD_FILESmount /BD_FILESCiò 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.
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.
mkdir /BD_FILES && mount -M /data /BD_FILES && rmdir /data
rsyncè che è riavviabile.
rsync -aconserva quasi tutti i metadati, ma non i collegamenti fisici, gli ACL o gli attributi estesi (aggiungi -HAXper quello).
renamecomandi diversi con comportamenti diversi. Penso che sia una ragione sufficiente per non usare il renamecomando quando vuoi essere certo di cosa farà.
Non stai rinominando tutti i file nella directory, stai rinominando un file in /. È perché:
Pertanto, rinominare una directory, non importa quanti file o quanti dati siano in essa contenuti, è banale.
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
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
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.
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.
mvcon l'-iopzione.