On 4/28/23 15:11, Piviul wrote:
On 4/28/23 07:54, Diego Zuccato wrote:
Brutta storia quella di Hans Reiser... Anche io usavo reiserfs sulle
mie macchine, finché un aggiornamento non le ha brickate (supporto
reiserfs rimosso dal kernel). Problema limitato per root e home, più
rognoso per i dischi dati... :(
Quello che non mi convince molto del disabilitare il check è: cosa
trova se lo abiliti e fai uno shutdown pulito? Non vedere gli errori
è un po' come ignorare un memory leak... Su un desktop può non essere
grave, ma su un server è meglio evitare. Se xfs_repair -L ha
impiegato più di 4 ore per il controllo di *un* disco da 12T, quanto
ci avrebbe messo l'equivalente fsck.ext4 ?
Scusa ma chi è che usa un disco da 12T con un'unica partizione? In
ogni caso un fsck.ext4 anche su un volume di pochissimi tera mette a
dura prova... ma btrfs o xfs hanno un sistema di filesystemcheck molto
più veloce?
comunque ho fatto una prova, volume di 3T non cachato su disco
meccanico da 12T:
# date && fsck.ext4 -f /dev/backup-server-vg/nas1-backup && date
Fri 28 Apr 2023 03:21:12 PM CEST
e2fsck 1.46.2 (28-Feb-2021)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/backup-server-vg/nas1-backup: 5688300/201326592 files (0.6%
non-contiguous), 731688406/805306368 blocks
Fri 28 Apr 2023 03:24:35 PM CEST
# mount -a
# df -h /dev/backup-server-vg/nas1-backup
Filesystem Size Used Avail Use%
Mounted on
/dev/mapper/backup--server--vg-nas1--backup 3.0T 2.7T 138G 96%
/srv/backups/nas1
# lvs /dev/backup-server-vg/nas1-backup
LV VG Attr LSize Pool Origin Data%
Meta% Move Log Cpy%Sync Convert
nas1-backup backup-server-vg -wi-ao---- 3.00t
poco più di 3 minuti... mi sembra ad occhio accettabile; xfs o btrfs
farebbe di meglio?
Piviul
