| 2019-01-03 06:22:53 |
Daniel Axtens |
bug |
|
|
added bug |
| 2019-01-03 06:51:28 |
Daniel Axtens |
attachment added |
|
0001-cachefilesd-can-spin-when-disk-space-is-short.patch https://bugs.launchpad.net/ubuntu/+source/cachefilesd/+bug/1810372/+attachment/5226523/+files/0001-cachefilesd-can-spin-when-disk-space-is-short.patch |
|
| 2019-01-03 08:20:08 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
| 2019-01-03 08:20:17 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Review Team |
| 2019-01-07 00:27:12 |
Daniel Axtens |
nominated for series |
|
Ubuntu Xenial |
|
| 2019-01-07 00:28:43 |
Daniel Axtens |
attachment added |
|
cachefilesd_0.10.5-1ubuntu1.diff.gz https://bugs.launchpad.net/ubuntu/+source/cachefilesd/+bug/1810372/+attachment/5227284/+files/cachefilesd_0.10.5-1ubuntu1.diff.gz |
|
| 2019-01-07 00:29:00 |
Daniel Axtens |
bug |
|
|
added subscriber STS Sponsors |
| 2019-01-08 14:08:52 |
Dan Streetman |
tags |
patch |
patch sts sts-sponsor sts-sponsor-ddstreet |
|
| 2019-01-08 14:27:23 |
Dan Streetman |
bug task added |
|
cachefilesd (Ubuntu Xenial) |
|
| 2019-01-11 14:18:31 |
Dan Streetman |
description |
[Impact]
A user reports that cachefilesd will spin at 100% of a cpu when started on a filesystem where the free space is less than the bcull threshold and culling the cache is insufficient to free up space.
Investigation shows that this is because cachefilesd detects that culling is required, tries to cull, and does not realise that culling cannot free up enough space, so just keeps retrying.
[Testing/Reproducing]
I created a VM with a spare disk, mounted it to /raid (or whatever).
I changed the /etc/default/cachefilesd to start at boot, filled the /raid filesystem to over the bcull threshold, and started cachefilesd. When running top, the cachefilesd process is at the top using approx 100% of 1 CPU. It appears to be trying to free up space in the cache (that is not even used) because the filesystem is over the threshold for culling.
[Fix]
This is fixed upstream in 0.10.6:
* Wed Feb 3 2016 David Howells <dhowells@redhat.com> 0.10.6-1
...
- Suspend culling when cache space is short and cache objects are pinned.
The particular patch is ce353f5b6b5b ("cachefilesd can spin when disk space is short.")
[Regression Potential]
The patch is small and easily understood and backports with minimal effort. |
[Impact]
A user reports that cachefilesd will spin at 100% of a cpu when started on a filesystem where the free space is less than the bcull threshold and culling the cache is insufficient to free up space.
Investigation shows that this is because cachefilesd detects that culling is required, tries to cull, and does not realise that culling cannot free up enough space, so just keeps retrying.
[Test Case]
I created a VM with a spare disk, mounted it to /raid (or whatever).
I changed the /etc/default/cachefilesd to start at boot, filled the /raid filesystem to over the bcull threshold, and started cachefilesd. When running top, the cachefilesd process is at the top using approx 100% of 1 CPU. It appears to be trying to free up space in the cache (that is not even used) because the filesystem is over the threshold for culling.
[Regression Potential]
The patch makes changes to how cachefilesd detects if it should sleep
or cull, so regressions would be in the area of cachefilesd spinning
instead of sleeping (which is what it does now) or sleeping instead
of culling.
However the patch is small and easily understood and backports with minimal effort.
[Fix]
This is fixed upstream in 0.10.6:
* Wed Feb 3 2016 David Howells <dhowells@redhat.com> 0.10.6-1
...
- Suspend culling when cache space is short and cache objects are pinned.
The particular patch is ce353f5b6b5b ("cachefilesd can spin when disk space is short.") |
|
| 2019-01-11 14:19:01 |
Dan Streetman |
description |
[Impact]
A user reports that cachefilesd will spin at 100% of a cpu when started on a filesystem where the free space is less than the bcull threshold and culling the cache is insufficient to free up space.
Investigation shows that this is because cachefilesd detects that culling is required, tries to cull, and does not realise that culling cannot free up enough space, so just keeps retrying.
[Test Case]
I created a VM with a spare disk, mounted it to /raid (or whatever).
I changed the /etc/default/cachefilesd to start at boot, filled the /raid filesystem to over the bcull threshold, and started cachefilesd. When running top, the cachefilesd process is at the top using approx 100% of 1 CPU. It appears to be trying to free up space in the cache (that is not even used) because the filesystem is over the threshold for culling.
[Regression Potential]
The patch makes changes to how cachefilesd detects if it should sleep
or cull, so regressions would be in the area of cachefilesd spinning
instead of sleeping (which is what it does now) or sleeping instead
of culling.
However the patch is small and easily understood and backports with minimal effort.
[Fix]
This is fixed upstream in 0.10.6:
* Wed Feb 3 2016 David Howells <dhowells@redhat.com> 0.10.6-1
...
- Suspend culling when cache space is short and cache objects are pinned.
The particular patch is ce353f5b6b5b ("cachefilesd can spin when disk space is short.") |
[Impact]
A user reports that cachefilesd will spin at 100% of a cpu when started on a filesystem where the free space is less than the bcull threshold and culling the cache is insufficient to free up space.
Investigation shows that this is because cachefilesd detects that culling is required, tries to cull, and does not realise that culling cannot free up enough space, so just keeps retrying.
[Test Case]
I created a VM with a spare disk, mounted it to /raid (or whatever).
I changed the /etc/default/cachefilesd to start at boot, filled the /raid filesystem to over the bcull threshold, and started cachefilesd. When running top, the cachefilesd process is at the top using approx 100% of 1 CPU. It appears to be trying to free up space in the cache (that is not even used) because the filesystem is over the threshold for culling.
[Regression Potential]
The patch makes changes to how cachefilesd detects if it should sleep
or cull, so regressions would be in the area of cachefilesd spinning
instead of sleeping (which is what it does now) or sleeping instead
of culling.
However the patch is small and easily understood and backports with minimal effort.
[Other Info]
This is fixed upstream in 0.10.6:
* Wed Feb 3 2016 David Howells <dhowells@redhat.com> 0.10.6-1
...
- Suspend culling when cache space is short and cache objects are pinned.
The particular patch is ce353f5b6b5b ("cachefilesd can spin when disk space is short.") |
|
| 2019-01-11 14:27:04 |
Dan Streetman |
nominated for series |
|
Ubuntu Trusty |
|
| 2019-01-11 14:27:04 |
Dan Streetman |
bug task added |
|
cachefilesd (Ubuntu Trusty) |
|
| 2019-01-11 14:27:10 |
Dan Streetman |
cachefilesd (Ubuntu Trusty): status |
New |
In Progress |
|
| 2019-01-11 14:27:13 |
Dan Streetman |
cachefilesd (Ubuntu Xenial): status |
New |
In Progress |
|
| 2019-01-11 14:27:23 |
Dan Streetman |
cachefilesd (Ubuntu Trusty): assignee |
|
Daniel Axtens (daxtens) |
|
| 2019-01-11 14:27:32 |
Dan Streetman |
cachefilesd (Ubuntu Xenial): assignee |
|
Daniel Axtens (daxtens) |
|
| 2019-01-11 14:27:35 |
Dan Streetman |
cachefilesd (Ubuntu Trusty): importance |
Undecided |
Medium |
|
| 2019-01-11 14:27:37 |
Dan Streetman |
cachefilesd (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2019-01-11 14:27:39 |
Dan Streetman |
cachefilesd (Ubuntu): importance |
Undecided |
Medium |
|
| 2019-01-11 14:27:43 |
Dan Streetman |
cachefilesd (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2019-01-11 14:28:45 |
Dan Streetman |
description |
[Impact]
A user reports that cachefilesd will spin at 100% of a cpu when started on a filesystem where the free space is less than the bcull threshold and culling the cache is insufficient to free up space.
Investigation shows that this is because cachefilesd detects that culling is required, tries to cull, and does not realise that culling cannot free up enough space, so just keeps retrying.
[Test Case]
I created a VM with a spare disk, mounted it to /raid (or whatever).
I changed the /etc/default/cachefilesd to start at boot, filled the /raid filesystem to over the bcull threshold, and started cachefilesd. When running top, the cachefilesd process is at the top using approx 100% of 1 CPU. It appears to be trying to free up space in the cache (that is not even used) because the filesystem is over the threshold for culling.
[Regression Potential]
The patch makes changes to how cachefilesd detects if it should sleep
or cull, so regressions would be in the area of cachefilesd spinning
instead of sleeping (which is what it does now) or sleeping instead
of culling.
However the patch is small and easily understood and backports with minimal effort.
[Other Info]
This is fixed upstream in 0.10.6:
* Wed Feb 3 2016 David Howells <dhowells@redhat.com> 0.10.6-1
...
- Suspend culling when cache space is short and cache objects are pinned.
The particular patch is ce353f5b6b5b ("cachefilesd can spin when disk space is short.") |
[Impact]
A user reports that cachefilesd will spin at 100% of a cpu when started on a filesystem where the free space is less than the bcull threshold and culling the cache is insufficient to free up space.
Investigation shows that this is because cachefilesd detects that culling is required, tries to cull, and does not realise that culling cannot free up enough space, so just keeps retrying.
[Test Case]
I created a VM with a spare disk, mounted it to /raid (or whatever).
I changed the /etc/default/cachefilesd to start at boot, filled the /raid filesystem to over the bcull threshold, and started cachefilesd. When running top, the cachefilesd process is at the top using approx 100% of 1 CPU. It appears to be trying to free up space in the cache (that is not even used) because the filesystem is over the threshold for culling.
[Regression Potential]
The patch makes changes to how cachefilesd detects if it should sleep
or cull, so regressions would be in the area of cachefilesd spinning
instead of sleeping (which is what it does now) or sleeping instead
of culling.
However the patch is small and easily understood and backports with minimal effort.
[Other Info]
This is fixed upstream in 0.10.6:
* Wed Feb 3 2016 David Howells <dhowells@redhat.com> 0.10.6-1
...
- Suspend culling when cache space is short and cache objects are pinned.
The particular patch is ce353f5b6b5b ("cachefilesd can spin when disk space is short.")
Since bionic has version 0.10.10-0.1, this fix is needed only for xenial and trusty. |
|
| 2019-01-11 15:06:45 |
Dan Streetman |
description |
[Impact]
A user reports that cachefilesd will spin at 100% of a cpu when started on a filesystem where the free space is less than the bcull threshold and culling the cache is insufficient to free up space.
Investigation shows that this is because cachefilesd detects that culling is required, tries to cull, and does not realise that culling cannot free up enough space, so just keeps retrying.
[Test Case]
I created a VM with a spare disk, mounted it to /raid (or whatever).
I changed the /etc/default/cachefilesd to start at boot, filled the /raid filesystem to over the bcull threshold, and started cachefilesd. When running top, the cachefilesd process is at the top using approx 100% of 1 CPU. It appears to be trying to free up space in the cache (that is not even used) because the filesystem is over the threshold for culling.
[Regression Potential]
The patch makes changes to how cachefilesd detects if it should sleep
or cull, so regressions would be in the area of cachefilesd spinning
instead of sleeping (which is what it does now) or sleeping instead
of culling.
However the patch is small and easily understood and backports with minimal effort.
[Other Info]
This is fixed upstream in 0.10.6:
* Wed Feb 3 2016 David Howells <dhowells@redhat.com> 0.10.6-1
...
- Suspend culling when cache space is short and cache objects are pinned.
The particular patch is ce353f5b6b5b ("cachefilesd can spin when disk space is short.")
Since bionic has version 0.10.10-0.1, this fix is needed only for xenial and trusty. |
[Impact]
A user reports that cachefilesd will spin at 100% of a cpu when started on a filesystem where the free space is less than the bcull threshold and culling the cache is insufficient to free up space.
Investigation shows that this is because cachefilesd detects that culling is required, tries to cull, and does not realise that culling cannot free up enough space, so just keeps retrying.
[Test Case]
Create a trusty or xenial VM, and install cachefilesd. Using either a real disk or loopback image, create a ext4 filesystem, and edit fstab to mount it at /var/cache/fscache, e.g.:
$ sudo dd if=/dev/zero of=/cache.img bs=1024m count=1024
$ sudo losetup -f /cache.img
$ sudo losetup -a
$ sudo mkfs.ext4 /dev/loop0 (note, adjust loop0 if needed)
edit fstab e.g.:
$ grep fscache /etc/fstab
/cache.img /var/cache/fscache ext4 defaults,loop,user_xattr 0 0
It's important to include the 'user_xattr' option as cachefilesd requires that.
stop the cachefilesd service and move the fscache contents:
$ sudo service cachefilesd stop
$ cd /var/cache
$ sudo mkdir fscache2
$ sudo mv -vf fscache/* fscache2/
$ sudo mount fscache
$ sudo mv -vf fscache2/* fscache/
$ sudo rmdir fscache2
create a file to fill up the fscache space, e.g.:
$ sudo dd if=/dev/zero of=/var/cache/fscache/largefile.txt bs=1024k count=850
$ df /var/cache/fscache
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/loop0 999320 922896 7612 100% /var/cache/fscache
edit /etc/default/cachefilesd to uncomment 'RUN=yes', e.g.:
$ grep RUN /etc/default/cachefilesd
RUN=yes
reboot, or just restart cachefilesd service
$ sudo service cachefilesd start
check top
$ top
cachefilesd should be spinning, using 100% (or as much as it can) cpu time.
[Regression Potential]
The patch makes changes to how cachefilesd detects if it should sleep
or cull, so regressions would be in the area of cachefilesd spinning
instead of sleeping (which is what it does now) or sleeping instead
of culling.
However the patch is small and easily understood and backports with minimal effort.
[Other Info]
This is fixed upstream in 0.10.6:
* Wed Feb 3 2016 David Howells <dhowells@redhat.com> 0.10.6-1
...
- Suspend culling when cache space is short and cache objects are pinned.
The particular patch is ce353f5b6b5b ("cachefilesd can spin when disk space is short.")
Since bionic has version 0.10.10-0.1, this fix is needed only for xenial and trusty. |
|
| 2019-01-15 23:51:51 |
Brian Murray |
cachefilesd (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2019-01-15 23:51:53 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-01-15 23:51:56 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2019-01-15 23:52:00 |
Brian Murray |
tags |
patch sts sts-sponsor sts-sponsor-ddstreet |
patch sts sts-sponsor sts-sponsor-ddstreet verification-needed verification-needed-xenial |
|
| 2019-01-15 23:52:50 |
Brian Murray |
cachefilesd (Ubuntu Trusty): status |
In Progress |
Fix Committed |
|
| 2019-01-15 23:52:55 |
Brian Murray |
tags |
patch sts sts-sponsor sts-sponsor-ddstreet verification-needed verification-needed-xenial |
patch sts sts-sponsor sts-sponsor-ddstreet verification-needed verification-needed-trusty verification-needed-xenial |
|
| 2019-01-17 03:47:34 |
Daniel Axtens |
tags |
patch sts sts-sponsor sts-sponsor-ddstreet verification-needed verification-needed-trusty verification-needed-xenial |
patch sts sts-sponsor sts-sponsor-ddstreet verification-done-xenial verification-needed verification-needed-trusty |
|
| 2019-01-17 05:14:17 |
Daniel Axtens |
tags |
patch sts sts-sponsor sts-sponsor-ddstreet verification-done-xenial verification-needed verification-needed-trusty |
patch sts sts-sponsor sts-sponsor-ddstreet verification-done-trusty verification-done-xenial verification-needed |
|
| 2019-01-17 14:11:59 |
Dan Streetman |
tags |
patch sts sts-sponsor sts-sponsor-ddstreet verification-done-trusty verification-done-xenial verification-needed |
patch sts sts-sponsor sts-sponsor-ddstreet verification-done verification-done-trusty verification-done-xenial |
|
| 2019-01-17 14:12:13 |
Dan Streetman |
tags |
patch sts sts-sponsor sts-sponsor-ddstreet verification-done verification-done-trusty verification-done-xenial |
patch sts verification-done verification-done-trusty verification-done-xenial |
|
| 2019-01-23 14:20:01 |
Robie Basak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2019-01-23 14:20:06 |
Launchpad Janitor |
cachefilesd (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
| 2019-01-23 14:20:15 |
Launchpad Janitor |
cachefilesd (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
