diff options
author | Josef Bacik <josef@redhat.com> | 2011-09-30 15:23:54 -0400 |
---|---|---|
committer | Chris Mason <chris.mason@oracle.com> | 2011-09-30 15:23:54 -0400 |
commit | b6316429af7f365f307dfd2b6a7a42f2563aef19 (patch) | |
tree | f445576e448d3287d56650775bb7d0bc5a7d37c7 /fs/btrfs/transaction.c | |
parent | b6f3409b2197e8fcedb43e6600e37b7cfbe0715b (diff) | |
download | op-kernel-dev-b6316429af7f365f307dfd2b6a7a42f2563aef19.zip op-kernel-dev-b6316429af7f365f307dfd2b6a7a42f2563aef19.tar.gz |
Btrfs: force a page fault if we have a shorty copy on a page boundary
A user reported a problem where ceph was getting into 100% cpu usage while doing
some writing. It turns out it's because we were doing a short write on a not
uptodate page, which means we'd fall back at one page at a time and fault the
page in. The problem is our position is on the page boundary, so our fault in
logic wasn't actually reading the page, so we'd just spin forever or until the
page got read in by somebody else. This will force a readpage if we end up
doing a short copy. Alexandre could reproduce this easily with ceph and reports
it fixes his problem. I also wrote a reproducer that no longer hangs my box
with this patch. Thanks,
Reported-and-tested-by: Alexandre Oliva <aoliva@redhat.com>
Signed-off-by: Josef Bacik <josef@redhat.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Diffstat (limited to 'fs/btrfs/transaction.c')
0 files changed, 0 insertions, 0 deletions