headers
Patrick Ng | 17 May 2013 22:13
Picon
Favicon

Re: Poor performance with bcache write-back mode

Hi Robert,

I have checked that the cache partition (/dev/sdc1) starts at 2048, it should be properly aligned.
Similarly for the backing store partition (/dev/sdb1), it starts at 2048 at well.
 
Thanks,
Patrick
>________________________________
> From: Robert Frånlund <robert.franlund@...>
>To: Patrick Ng <ppng@...> 
>Cc: "linux-bcache@..."
<linux-bcache@...> 
>Sent: Friday, May 17, 2013 2:22 AM
>Subject: Re: Poor performance with bcache write-back mode
> 
>
>
>Hi,
>
>
>Have you aligned your partitions on the SSD to at-least 4 KiB block-size, even better with 1 MiB?
>
>
>Best regards,
>Robert
>
>
>
>
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
sheng qiu | 17 May 2013 16:47
Picon

(unknown)

subscribe linux-bcache

--
Sheng Qiu
Texas A & M University
Room 332B Wisenbaker
email: herbert1984106@...
College Station, TX 77843-3259
Permalink | Reply | 0 comments |
headers
Patrick Ng | 16 May 2013 23:51
Picon
Favicon

Poor performance with bcache write-back mode

Hi all,

I have installed Linux kernel 3.9.2 in my Fedora 18.  When I ran FIO in bcache write-through mode, the
performance was good, but running a similar test in bcache write-back mode, I got very poor performance.
Did I miss any options when setting the write-back mode?

Environment
===========
500G backing store at /dev/sdb1
150G SSD at /dev/sdc1

Write-through mode
==================
make-bcache -B /dev/sdb1 -C /dev/sdc1
echo /dev/sdb1 > /sys/fs/bcache/register
echo /dev/sdc1 > /sys/fs/bcache/register
mkfs.ext4 /dev/bcache0
mount /dev/bcache0 /mnt/bcache

Running FIO with random, 100% read, iosize=4096, queue depth=16
the result is approx. 65k IOPS

Write-backe mode (setup is almost the same as write-through except the extra step at the end "echo
writeback ...")
================
make-bcache -B /dev/sdb1 -C /dev/sdc1
echo /dev/sdb1 > /sys/fs/bcache/register
echo /dev/sdc1 > /sys/fs/bcache/register
mkfs.ext4 /dev/bcache0
mount /dev/bcache0 /mnt/bcache
(Continue reading)

Permalink | Reply | 1 comment |
headers
Campbell Steven | 16 May 2013 00:03
Picon

Bcache problem perhaps bug?

Hi,

We have been using bcache in a test environment here for a while to
vastly improve performance of a CEPH cluster. We have really only run
into one issue, and I'm sure it's something to do with the way we have
things configured (otherwise others would have noticed I'm sure) but
I'm not exactly sure where. We are currently running this
http://atlas.evilpiepirate.org/git/linux-bcache.git/commit/?id=dbc52367ad8e63b5bcb8c6b1442e8fb5ed251421
commit  from the bcache tree after this when we reboot the server it
will hang for ever with timeouts shown in the screenshots of the KVM
below (sorry limited options for collecting debug data via a windows
only KVM):

https://www.btg.co.nz/Public/2.jpg
https://www.btg.co.nz/Public/3.jpg
https://www.btg.co.nz/Public/4.jpg
https://www.btg.co.nz/Public/6.jpg

I have tested a plain mainline kernel without bcache on the same
machine and that works fine as does everything up to and around the
commit from the bcache tree mentioned above. Anything later than that
(up to and including the latest mainline checkout as of today)
exhibits the behaviour above.

Our setup is:

2 x Intel 520 120GB SSD's of which 10 GB is in a RAID 1 for the OS
with LVM over top and the remaining space on both SSD's is a RAID 0
with LVM on top and used as a bcache caching device for the 4 spinning
disks in the servers.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kent Overstreet | 15 May 2013 11:48
Picon
Favicon

RAID5/6 stripe awareness

There's now raid5/6 stripe awareness in the bcache branch. I'm running
it on this machine right now.

If your backing device is a raid5 or 6 and you're using normal md raid,
in writeback mode it'll try really hard to buffer up and write out full
stripes:
 * writes to dirty stripes are forced to writeback - even if normally
   the write would've bypassed the cache because of sequential IO
   bypass/congested throttling
 * background writeback preferentially flushes full stripes, if there
   are any

There isn't currently a way to flip on the optimizations for other types
of raid where the settings can't be autodetected (could add an interface
for that if anyone wants).

I haven't benchmarked it yet, should theoretically be a big boost to
write performance - if anyone else benchmarks it I'd love to see.
Permalink | Reply | 0 comments |
headers
Kent Overstreet | 15 May 2013 09:53
Picon
Favicon

[GIT PULL] Bcache fixes for 3.10

Jens - couple more bcache patches. Bug fixes and a doc update.

The following changes since commit f50efd2fdbd9b35b11f5778ed85beb764184bda9:

  Merge branch 'bcache-for-upstream' of http://evilpiepirate.org/git/linux-bcache into
for-3.10/drivers (2013-05-01 09:23:05 +0200)

are available in the git repository at:

  http://evilpiepirate.org/git/linux-bcache.git bcache-for-upstream

for you to fetch changes up to f59fce847fc8483508b5028c24e2b1e00523dd88:

  bcache: Fix error handling in init code (2013-05-15 00:48:14 -0700)

----------------------------------------------------------------
Emil Goode (1):
      bcache: Fix incompatible pointer type warning

Gabriel (1):
      bcache: clarify free/available/unused space

Kent Overstreet (1):
      bcache: Fix error handling in init code

Paul Bolle (1):
      bcache: drop "select CLOSURES"

 Documentation/bcache.txt      |   12 ++-
 drivers/md/bcache/Kconfig     |    1 -
(Continue reading)

Permalink | Reply | 4 comments |
headers
Vincent Stehlé | 12 May 2013 18:30
Favicon

[PATCH] bcache: fix compilation warning

The release function of a block device does not return a value; make
release_dev void. This fixes the following warning:

  drivers/md/bcache/super.c:653:2: warning: initialization from incompatible pointer type [enabled
by default]
  drivers/md/bcache/super.c:653:2: warning: (near initialization for ‘bcache_ops.release’)
[enabled by default]

Signed-off-by: Vincent Stehlé <vincent.stehle@...>
---
 drivers/md/bcache/super.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index c8046bc..b09beb2 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
 <at>  <at>  -634,11 +634,10  <at>  <at>  static int open_dev(struct block_device *b, fmode_t mode)
 	return 0;
 }

-static int release_dev(struct gendisk *b, fmode_t mode)
+static void release_dev(struct gendisk *b, fmode_t mode)
 {
 	struct bcache_device *d = b->private_data;
 	closure_put(&d->cl);
-	return 0;
 }

 static int ioctl_dev(struct block_device *b, fmode_t mode,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcel Ammerlaan | 12 May 2013 15:03

Patching kernel 3.2

Hi,

Although I see the patches being pushed to kernel 3.10, I'd like to
patch a 3.2 kernel as well. However, it seems I cannot clone the git
repository (many timeouts) and git cannot restart a partial clone. Is
it possible to either download the repo as a zipfile or otherwise
receive the repo or a patch containing the changes for a 3.2 kernel.

Regards,

Marcel Ammerlaan.
Permalink | Reply | 1 comment |
headers
matthew patton | 11 May 2013 06:09
Picon
Favicon

bcache vs dm-cache

so this was a surprise to me in the latest 3.9 kernel. I like the flexibility of the design but the million
dollar question is which performs better. Congrats for getting bcache into the queue for 3.10. Are there
efforts to combine the best aspects of both projects?
Permalink | Reply | 0 comments |
headers
Giovanni Lenzi | 10 May 2013 12:28
Picon

bcache on ubuntu

Hi,
I want to use bcache on ubuntu.

I saw that I have to download it from git with git clone command. Is it right?

I never recompiled a kernel. Is it so hard?

What kind of steps am I supposed to do, if I have a fresh ubuntu installation?

Thanks for any help.

Giovanni
Permalink | Reply | 3 comments |
headers
Gabriel de Perthuis | 5 May 2013 21:33
Picon

[PATCH v2] bcache: Reload device size

Adds /sys/block/bcache*/bcache/resize; writing "max"
to such a file will reload the device size to match
the size of the underlying device, minus the bcache
superblock.

This is useful to grow a filesystem stacked on top
of bcache and a logical volume.

Other values than max are reserved for now; support
for shrinking might be added if the need comes up.

Signed-off-by: Gabriel de Perthuis <g2p.code+bcache@...>
---
v2: use revalidate_disk to commit changes

 Documentation/bcache.txt   |  4 ++++
 drivers/md/bcache/bcache.h |  1 +
 drivers/md/bcache/super.c  | 10 +++++++++-
 drivers/md/bcache/sysfs.c  | 11 +++++++++++
 4 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/Documentation/bcache.txt b/Documentation/bcache.txt
index acfa679..a53ee2d 100644
--- a/Documentation/bcache.txt
+++ b/Documentation/bcache.txt
 <at>  <at>  -215,10 +215,14  <at>  <at>  label
 readahead
   Size of readahead that should be performed.  Defaults to 0.  If set to e.g.
   1M, it will round cache miss reads up to that size, but without overlapping
   existing cache entries.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane