From: Christian Brunner <chb@muc.de>
To: linux-btrfs@vger.kernel.org
Cc: ceph-devel@vger.kernel.org
Subject: Btrfs slowdown with ceph (how to reproduce)
Date: Fri, 20 Jan 2012 13:13:37 +0100 [thread overview]
Message-ID: <CAO47_-8Eb_v8X95KxSZ2H-DNC3hLZkrfq1ce3CAfW2G9CUV5gQ@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]
As you might know, I have been seeing btrfs slowdowns in our ceph
cluster for quite some time. Even with the latest btrfs code for 3.3
I'm still seeing these problems. To make things reproducible, I've now
written a small test, that imitates ceph's behavior:
On a freshly created btrfs filesystem (2 TB size, mounted with
"noatime,nodiratime,compress=lzo,space_cache,inode_cache") I'm opening
100 files. After that I'm doing random writes on these files with a
sync_file_range after each write (each write has a size of 100 bytes)
and ioctl(BTRFS_IOC_SYNC) after every 100 writes.
After approximately 20 minutes, write activity suddenly increases
fourfold and the average request size decreases (see chart in the
attachment).
You can find IOstat output here: http://pastebin.com/Smbfg1aG
I hope that you are able to trace down the problem with the test
program in the attachment.
Thanks,
Christian
[-- Attachment #2: btrfstest.c --]
[-- Type: text/x-csrc, Size: 1230 bytes --]
#define _GNU_SOURCE
#include <inttypes.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <unistd.h>
#include <attr/xattr.h>
#define FILE_COUNT 100
#define FILE_SIZE 4194304
#define STRING "0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789"
#define BTRFS_IOCTL_MAGIC 0x94
#define BTRFS_IOC_SYNC _IO(BTRFS_IOCTL_MAGIC, 8)
int main(int argc, char *argv[]) {
char *imgname = argv[1];
char *tempname;
int fd[FILE_COUNT];
int ilen, i;
ilen = strlen(imgname);
tempname = malloc(ilen + 8);
for(i=0; i < FILE_COUNT; i++) {
snprintf(tempname, ilen + 8, "%s.%i", imgname, i);
fd[i] = open(tempname, O_CREAT|O_RDWR);
}
i=0;
while(1) {
int start = rand() % FILE_SIZE;
int file = rand() % FILE_COUNT;
putc('.', stderr);
lseek(fd[file], start, SEEK_SET);
write(fd[file], STRING, 100);
sync_file_range(fd[file], start, 100, 0x2);
usleep(25000);
i++;
if (i == 100) {
i=0;
ioctl(fd[file], BTRFS_IOC_SYNC);
}
}
}
[-- Attachment #3: btrfstest.png --]
[-- Type: image/png, Size: 6698 bytes --]
next reply other threads:[~2012-01-20 12:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-20 12:13 Christian Brunner [this message]
2012-01-23 18:19 ` Btrfs slowdown with ceph (how to reproduce) Josef Bacik
2012-01-23 18:50 ` Chris Mason
2012-01-23 20:53 ` Christian Brunner
2012-01-24 19:15 ` Martin Mailand
2012-01-24 19:40 ` Chris Mason
2012-01-24 20:55 ` Martin Mailand
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=CAO47_-8Eb_v8X95KxSZ2H-DNC3hLZkrfq1ce3CAfW2G9CUV5gQ@mail.gmail.com \
--to=chb@muc.de \
--cc=ceph-devel@vger.kernel.org \
--cc=linux-btrfs@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).