Re: btrfs system slow down with 100GB file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I don't know why but the spinning disk is being crushed.

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?

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.

On Fri, Apr 30, 2021 at 5:42 PM Richard Shaw <hobbes1069@xxxxxxxxx> wrote:
>
> A little thread necro... I stopped the blockchain daemon for a while and recently restarted it and am now seeing GUI freezes while it resyncs even though the file itself is marked +C...
>
> Here's the output of the requested commands:
>
> https://pastebin.com/9i0DaVpf
>
> 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



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux