On Fri, Apr 30, 2021 at 6:16 PM Roger Heflin rogerheflin@gmail.com wrote:
I don't know why but the spinning disk is being crushed.
Well, a little googling after my post it appears the database is LMDB, which is a COW db. So I can see how a COW DB on top of a COW FS may be a problem, but I have marked the directory nodatacow...
$ lsattr ~/.bitmonero/lmdb -------------------- /home/richard/.bitmonero/lmdb/lock.mdb ---------------C---- /home/richard/.bitmonero/lmdb/data.mdb
if you divide the mb/sec by the reads you get around 4k per read
(that is about as bad as you could do). if you multiply the reads/sec * r_await you get all of the time accounted for.
And since each read is taking around 8-10ms (around the disks seek time for a new track) then each block being read is not being cached in the disk hence probably not on the same track that the disk just read or as the disk recently read and still has in its cache. If the file you are rsyncing was written slowly or quickly with a number of other IO's happening between each io then that increases the chances of the file being massively fragmented and act like this.
Is this a single file and this single rsync is the only thing running?
I down know the inner workings of the client, but it is a single file as seen above.
And what disk are you syncing to/from? And how was the file that
you are rsyncing created? I have seen a DB do this (in a sequential backup) and that file was created in such a way that for the most part no 2 blocks were next to each other on a disk. I believe the average blocksize for that file was 5.1k. the filefrag command will show file fragments on some filesystems. There may be different commands needed depending on what filesystem the file comes from.
$ filefrag ~/.bitmonero/lmdb/data.mdb /home/richard/.bitmonero/lmdb/data.mdb: 388217 extents found
Thanks, Richard