From: Jeremiah Mahler <jmmahler@gmail.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: linux-kernel@vger.kernel.org
Subject: [BUG, bisect] hang when copying large file to disc
Date: Fri, 30 Jan 2015 19:40:51 -0800 [thread overview]
Message-ID: <20150131034051.GA1289@hudson.localdomain> (raw)
If a large file (> 1 GB) is transferred from a USB stick or a mmc
to an local disc (using ext4), it will proceed normally until it
has transferred approximately 600 MB. Then the speed will drop off
to zero and the terminal performing the operation will usually
hang. And sometimes other terminals will hang as well. A reboot
is required to get the system working again.
mount /dev/sdb1 /mnt
pv /mnt/large_file > large_file_out
(... ~600 MB ... hang)
I have performed a bisect and found that commit ef39794651347 introduced
the bug. This commit is present in the latest -next 20150130.
From ef397946513470381c0e9ed5b355cd1c9855a364 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <tytso@mit.edu>
Date: Sat, 24 Jan 2015 20:51:05 -0500
Subject: [PATCH] vfs: add support for a lazytime mount option
Add a new mount option which enables a new "lazytime" mode. This mode
causes atime, mtime, and ctime updates to only be made to the
in-memory version of the inode. The on-disk times will only get
updated when (a) if the inode needs to be updated for some non-time
related change, (b) if userspace calls fsync(), syncfs() or sync(), or
(c) just before an undeleted inode is evicted from memory.
This is OK according to POSIX because there are no guarantees after a
crash unless userspace explicitly requests via a fsync(2) call.
For workloads which feature a large number of random write to a
preallocated file, the lazytime mount option significantly reduces
writes to the inode table. The repeated 4k writes to a single block
will result in undesirable stress on flash devices and SMR disk
drives. Even on conventional HDD's, the repeated writes to the inode
table block will trigger Adjacent Track Interference (ATI) remediation
latencies, which very negatively impact long tail latencies --- which
is a very big deal for web serving tiers (for example).
Google-Bug-Id: 18297052
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
---
fs/ext4/inode.c | 6 ++++
fs/fs-writeback.c | 62 +++++++++++++++++++++++++++++++++-------
fs/gfs2/file.c | 4 +--
fs/inode.c | 56 +++++++++++++++++++++++++-----------
fs/jfs/file.c | 2 +-
fs/libfs.c | 2 +-
fs/proc_namespace.c | 1 +
fs/sync.c | 8 ++++++
include/linux/backing-dev.h | 1 +
include/linux/fs.h | 5 ++++
include/trace/events/writeback.h | 60 +++++++++++++++++++++++++++++++++++++-
include/uapi/linux/fs.h | 4 ++-
mm/backing-dev.c | 10 +++++--
13 files changed, 186 insertions(+), 35 deletions(-)
If I can do anything else to help, let me know.
--
- Jeremiah Mahler
next reply other threads:[~2015-01-31 3:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-31 3:40 Jeremiah Mahler [this message]
2015-02-01 2:02 ` Theodore Ts'o
2015-02-01 19:30 ` Jeremiah Mahler
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=20150131034051.GA1289@hudson.localdomain \
--to=jmmahler@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/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
all inboxes | Powered by JetHome®