Unfortunately I cannot reproduce this behavior here.
There is obviously a measurable IO when snap is refreshed, but that is
expected, since a new revision needs to be downloaded (writes),
downloads could be retried (read to hash the files and then writes),
followed by the bookkeeping tasks (read & write). More snaps will
obviously lead to the higher IO though a longer time. During the
downloads, one can easily naturally expect the IO write to be as much as
the download speed, since the data has to end up on disk at one point.
Would you mind helping us debugging the problem? I think it would be
useful to collect the output of: `sudo pidstat -d -T ALL -p `pidof
snapd` 5` and `snap changes`.
In my system I get the following stats during idle:
11:12:04 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
11:12:05 0 4032 0.00 0.00 0.00 0 snapd
Then when for instance installing lxd:
>>>>> download still in progress
11:13:48 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
11:13:53 0 4032 0.00 1043.20 0.00 0 snapd
11:13:53 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
11:13:58 0 4032 5.60 925.60 0.00 0 snapd
>>>>> download done, started bookkeeping tasks
11:13:58 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
11:14:03 0 4032 1048.80 1677.60 138.40 0 snapd
>>>>> all done, back to idle
11:14:03 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
11:14:08 0 4032 0.00 0.00 0.00 0 snapd
** Changed in: snapd (Ubuntu)
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1839237
Title:
snapd disk write usage very high on 19.04 with snapd 2.39.3
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1839237/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
