dobbiamo correggere il danneggiamento del file system su sdb sulla versione 6 di redhat
sdb è il file system xfs
df -h | egrep "Filesystem|/data" Filesystem Size Used Avail Use% Mounted on /dev/sdb 8.2T 7.0T 1.0T 86% /data perché i dati su sdb sono enormi
vogliamo sapere qual è la migliore opzione 1 o 2?
o altra idea per riparare il file system?
opzione 1
umount /data fsck -y /dev/sdb mount /data opzione 2
umount /data e2fsck -y /dev/sdb mount /data opzione 3
umount /data xfs_repair /dev/sdb mount /data secondo: quali sono i rischi quando si esegue fsck su dati enormi?
Commenti
Risposta
Citando questo post SuperUser :
fsckè solo il nome originale. Quando sono usciti con nuovi file system, avrebbero avuto bisogno di uno strumento specifico per ciascuno,efsckper ext,e2fsckper ext2,dosfsck,fsckvfat. Quindi hanno creatofsckil front-end che chiama semplicemente lo strumento appropriato.
fsck.xfs è probabilmente quello che stai cercando.
Aggiornamento relativo a XFS:
xfs_check e xfs_repair dovrebbero aiutarti a valutare il danno e riparare se possibile.
Si prega di consultare le pagine di manuale per informazioni sullutilizzo specifico.
Commenti
- così possiamo essere sicuri quando facciamo – fsck -y / dev / sdb?
- @yael Dipende, personalmente penso che lo sia, ma questo è probabilmente basato sullopinione.
- quindi cosè meglio fsck .xfs -y / dev / sdb o fsck -y / dev / sdb
- @yael Penso che entrambi farebbero lo stesso lavoro. Ma tendo a specificare sempre il tipo, ad es. Vorrei utilizzare
fsck.xfs. - quindi qual è la differenza tra xfs_repair e fsck.xfs?
Rispondi
Per le persone che votano per fsck.xfs … è solo una versione rinominata di / bin / true. Non fa altro che restituire “0” ed uscire . La risposta corretta è:
umount /data xfs_repair /dev/sdb mount /data Commenti
- Noterai che xfs_repair è stato menzionato in l altra risposta
e2fscksu di esso?