Ho una macchina Debian sulla mia LAN che funge da server di backup per gli altri. Ha quattro HDD combinati in un dispositivo RAID 5 software md, su quel LVM e su quel btrfs. I backup vengono eseguiti utilizzando rsync e per un file system di grandi dimensioni richiede più di un'ora. Per molto tempo ho pensato che ci sarebbe stato poco da fare al riguardo.
Di recente, tuttavia, ho notato che l'attività dell'HDD era molto diversa su entrambe le estremità del trasferimento. Mentre il lato di invio, che utilizzava Gentoo e utilizzava principalmente ext4, non aveva quasi alcun disco IO, il lato di ricezione era costantemente occupato. Poiché la maggior parte dei dati non cambierebbe tra i trasferimenti, credo che le letture dei metadati dovrebbero costituire la maggior parte dei dati. Ma sarei davvero sorpreso se leggere gli inode in btrfs sia tanto lavoro che fare lo stesso in ext4.
iotop
letture del disco confermate di circa 1-4 MB / s sul lato di ricezione, mentre il lato di invio ha avuto solo occasionali scoppi di 0,5 MB / s.
La mia domanda è: qualcuno può spiegare cosa sta succedendo qui? Preferibilmente con qualche indicazione su come aggirare il problema, se possibile.
Forse c'è qualche flag di tuning btrfs che potrei usare, o qualcosa di simile. Ho bisogno di un FS con capacità di snapshot sul server di backup e il mio tentativo di utilizzare FreeBSD e ZFS porta rapidamente a un FS incoerente, quindi al momento vedo poche alternative a btrfs. Pertanto le risposte che mi dicono di usare ext4 o zfs potrebbero ricevere voti positivi ma nessun segno di spunta.
Opzioni Rsync in uso, come richiesto da cjm :
--rsync-path='rsync --fake-super'
--archive # -rlptgoD
--hard-links # detect and preserve these
--acls
--xattrs
--sparse
--noatime # based on patch from samba #7249c1
--delete
--delete-delay
--fuzzy
--human-readable # size suffixes, base 1000
--stats
Oltre a un mucchio di -f
regole per omettere alcuni file.
Le opzioni di mount di btrfs sono riportate da mount
as
rw,nosuid,noexec,noatime,nospace_cache
In particolare, questo include il noatime
flag, quindi non dovrebbe esserci alcuna scrittura a meno che non ci siano effettivamente differenze in alcuni file. Ho aggiunto queste informazioni in risposta alla risposta di Kyle Jones .
dtrace
o systemtap
scoprire dove si sta passando il tempo.