From: bugzilla-daemon@bugzilla.kernel.org
To: linux-xfs@vger.kernel.org
Subject: [Bug 202349] New: Extreme desktop freezes during sustained write operations with XFS
Date: Sat, 19 Jan 2019 16:50:46 +0000 [thread overview]
Message-ID: <bug-202349-201763@https.bugzilla.kernel.org/> (raw)
https://bugzilla.kernel.org/show_bug.cgi?id=202349
Bug ID: 202349
Summary: Extreme desktop freezes during sustained write
operations with XFS
Product: File System
Version: 2.5
Kernel Version: 4,19.16
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: XFS
Assignee: filesystem_xfs@kernel-bugs.kernel.org
Reporter: nfxjfg@googlemail.com
Regression: No
If you keep appending data to a a file on a XFS filesystem, the entire system
will occasionally freeze for up to 4 seconds or so. Then it recovers and
continues for a few minutes, until it happens again. Although the freezes
happen at sort of random times, it's generally highly reproducible.
This is extremely bothersome for desktop use, as _everything_ stops during the
freeze. Even typing text into a terminal. Even processes that don't appear to
do any I/O are frozen (at least not I/O to disks). For example, a python script
that does nothing else than printing a counter to stdout (running in a X11
terminal emulator) will stop. Everything is completely in memory; the system
disk is on a SSD anyway.
In general, the desktop becomes completely unusable garbage, which in turn
makes XFS unsuitable for desktop operation until this is fixed.
Reproduction is simple enough: if I copy multiple large files (dozens of files
with about 500-5000 MB per file) with rsync from one disk to another (both hard
disks using XFS filesystems), the freezes will happen at least every few
minutes.
Someone else observed something similar independently just now, and suspects
this is happening because XFS blocks the entire kernel when freeing certain
caches: https://twitter.com/marcan42/status/1086652425061056515
I don't know whether my case is the same, but it sure looks very similar.
This is with kernel 4.19.16, deadline scheduler for both source and target (as
recommended by XFS FAQ), and full kernel preemption enabled. The system has
16GB RAM, of which 10GB are usually available for caches. I don't know what
information is useful, so please request whatever information might be useful
for analyzing this.
--
You are receiving this mail because:
You are watching the assignee of the bug.
next reply other threads:[~2019-01-19 16:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-19 16:50 bugzilla-daemon [this message]
2019-01-19 17:15 ` [Bug 202349] Extreme desktop freezes during sustained write operations with XFS bugzilla-daemon
2019-01-19 22:20 ` bugzilla-daemon
2019-01-20 21:59 ` bugzilla-daemon
2019-01-21 16:16 ` bugzilla-daemon
2019-01-21 19:04 ` bugzilla-daemon
2019-01-24 11:59 ` bugzilla-daemon
2019-01-24 23:31 ` Dave Chinner
2019-01-24 23:31 ` bugzilla-daemon
2019-01-25 9:55 ` bugzilla-daemon
2019-01-25 12:50 ` bugzilla-daemon
2019-01-29 22:03 ` bugzilla-daemon
2019-01-30 17:58 ` bugzilla-daemon
2019-01-31 14:56 ` bugzilla-daemon
2019-09-29 11:52 ` bugzilla-daemon
2019-11-22 10:46 ` bugzilla-daemon
2020-03-12 16:12 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-202349-201763@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@bugzilla.kernel.org \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).