Btrfs on bcache device: mount options?

Btrfs on bcache device: mount options?

[Simon Herter]

Hello,

I'm using btrfs on a bcache device and I'm a bit confused about mount
options. For example, bcache may (if I understood correctly) bypass the
cache completely for sequential access. So should I use "ssd" mount
option or not? Are there any general recommendations?

Thanks
-Simon

Re: Btrfs on bcache device: mount options?

[Vojtech Pavlik]

On Thu, Oct 15, 2015 at 03:04:35PM +0200, Simon Herter wrote:

> I'm using btrfs on a bcache device and I'm a bit confused about mount
> options. For example, bcache may (if I understood correctly) bypass the
> cache completely for sequential access. So should I use "ssd" mount
> option or not? Are there any general recommendations?

No, you should not. It modifies the data layout behavior to ignore seek
times. These may be present when reading from the backing media.

You likely want to enable compression and autodefragmentation, too.
-- 
Vojtech Pavlik
Director SUSE Labs

Re: Btrfs on bcache device: mount options?

[Simon Herter]

Vojtech Pavlik writes:

> On Thu, Oct 15, 2015 at 03:04:35PM +0200, Simon Herter wrote:
>
>> I'm using btrfs on a bcache device and I'm a bit confused about mount
>> options. For example, bcache may (if I understood correctly) bypass the
>> cache completely for sequential access. So should I use "ssd" mount
>> option or not? Are there any general recommendations?
>
> No, you should not. It modifies the data layout behavior to ignore seek
> times. These may be present when reading from the backing media.

Sounds reasonable. A short note on that: _not_ specifying 'ssd' is not
enough, one has to specify 'nossd' explicitly. Btrfs enables 'ssd'
automatically by checking /sys/block/bcache0/queue/rotational to be
zero - which is true. (Though I'm not sure whether bcache got that right.
One could argue that returning the backing device's rotational value
would be better, especially to get the defaults right for btrfs.)

> You likely want to enable compression and autodefragmentation, too.

When I read 'autodefrag' I was worried about my ssd at first, but I found
some discussion about that on the btrfs mailing list, so that seems to
be fine. Thanks for the suggestions.

-Simon

Re: Btrfs on bcache device: mount options?

[Kai Krakow]

Am Thu, 15 Oct 2015 23:27:32 +0200
schrieb Simon Herter <sim.herter@gmail.com>:

> 
> Vojtech Pavlik writes:
> 
> > On Thu, Oct 15, 2015 at 03:04:35PM +0200, Simon Herter wrote:
> >
> >> I'm using btrfs on a bcache device and I'm a bit confused about
> >> mount options. For example, bcache may (if I understood correctly)
> >> bypass the cache completely for sequential access. So should I use
> >> "ssd" mount option or not? Are there any general recommendations?
> >
> > No, you should not. It modifies the data layout behavior to ignore
> > seek times. These may be present when reading from the backing
> > media.
> 
> Sounds reasonable. A short note on that: _not_ specifying 'ssd' is not
> enough, one has to specify 'nossd' explicitly. Btrfs enables 'ssd'
> automatically by checking /sys/block/bcache0/queue/rotational to be
> zero - which is true. (Though I'm not sure whether bcache got that
> right. One could argue that returning the backing device's rotational
> value would be better, especially to get the defaults right for
> btrfs.)
> 
> > You likely want to enable compression and autodefragmentation, too.
> 
> When I read 'autodefrag' I was worried about my ssd at first, but I
> found some discussion about that on the btrfs mailing list, so that
> seems to be fine. Thanks for the suggestions.

I found that using autodefrag with bcache eats lifetime of your SSD a
lot. I suggest watching your SSD smart stats closely for a while before
turning it permanently on. Autodefrag constantly rewrites even big
files, this is still not optimized in btrfs.

You may better want to individually mark files nocow in btrfs which are
subject to high fragmentation and source of low performance due to
this, like sqlite files, database files, vm images, etc. Such files
usually have their own transaction safety layer anyways - so you do not
really need btrfs transactional cow protection for these.

But I'll look into the nossd option. I wondered about this myself.

Regards,
Kai

--