On 6/29/20 2:26 AM, John M. Harris Jr wrote:
On Sunday, June 28, 2020 5:37:08 PM MST Chris Adams wrote:
Once upon a time, John M. Harris Jr <johnmh@xxxxxxxxxxxxx> said:
XFS proved to be troublesome, and still is up to the latest of RHEL7. It's
not uncommon to have to run xfs_repair on smaller XFS partitions,
especially / boot. I'm not sure if btrfs has the same issue there?
[citation needed]
I haven't run xfs_repair in probably 15 years (and so never on Fedora or
RHEL/CentOS).
I haven't had time to figure out why the RHEL systems I have that are
(mistakenly I assume, though they were created before I was hired) using XFS
run into that issue, after about a month, they report 100% disk space
utilization on /boot, and I've gotta run xfs_repair in order to fix that. In
the unlikely event that I have the time to figure out why, before I just re-
install them (which is already planned), I'd be happy to follow up with a
citation. :)
I had a similar experience in 2016 when stopping Squid timed out and the
process was killed by systemd (fixed in RH BZ #1336940). For some reason
the filesystem got to 100% (multiple times) with no eachable file using
that.
As XFS has no reservation or space for root like ext4, the system was
unbootable without user intervention to run xfs_repair. I remember
sending a dump of the filesystem to a XFS developer on the mailing list,
so it probably got resolved on the XFS side too.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
