388217 * 10ms = about 3800 seconds to read that file or about 26MB/sec, but with all of the seeks most of that time will be idle time waiting on disk (iowait), and it is very possible that parts of the file have large extents and other parts of the file are horribly fragmented. And that ignores any time to do any other work related to the rsync and file io. How long does it take to copy the file? btrfs has an autodefrag mount option, no idea how good or bad it works, but it might be able to reduce the extents given enough time to a reasonable number and keep it under control. so long as you are using rsync to read the file the fact that the db is cow is probably not an issue (since from rsync's point of view it is just one big file). if you have small writes to the file and btrfs was set to cow that would make a mess. Not sure for a db btrfs is a good filesystem choice on a spinning disk, disabling cow might have mostly fixed this. it not clear to me that if you set the defrag option now if it will fix the already fragmented parts of the file or not. And if you turned off cow later the file may have already been heavily fragemented. On Fri, Apr 30, 2021 at 7:20 PM Richard Shaw <hobbes1069@xxxxxxxxx> wrote: > > On Fri, Apr 30, 2021 at 6:16 PM Roger Heflin <rogerheflin@xxxxxxxxx> 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 > _______________________________________________ > users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
