Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Neuer User <auslands-kv@gmx.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs und lvm-cache?
Date: Thu, 24 Dec 2015 16:29:14 +0100	[thread overview]
Message-ID: <n5h30b$8vd$1@ger.gmane.org> (raw)
In-Reply-To: <567C07A6.7080503@siedziba.pl>

Am 24.12.2015 um 15:56 schrieb Piotr Pawłow:
> Hello,
>> - both hdd and ssd in one LVM VG
>> - one LV on each hdd, containing a btrfs filesystem
>> - both btrfs LV configured as RAID1
>> - the single SDD used as a LVM cache device for both HDD LVs to speed up
>> random access, where possible
> 
> I have a setup like this for my /home. It works but it's a crappy solution.
> 
Indeed? Exactly like this? Great to hear. But sad to hear it is not a
good solution.

> The effective capacity for caching is halved, and it takes twice as much
> time to fully cache your working set, because you get a cache miss at
> least once for each mirror.
> 
> There are also some gotchas:
> 
> - you should use "device=" mount options, or else there is a danger of
> btrfs mounting origin devices and even mixing cached and origin in one
> FS. I completely broke my FS before realizing what's going on.

Hmm, strange. I thought btrfs should not even know of the lvmcache. It
would just try to mount the HDD LVs and the caching is done
automatically via lvmcache?

> - you should use writethrough mode if you only have one SSD. There was a
> bug in LVM where it wouldn't save the caching mode and revert to
> writeback after restart, so make sure you use the latest version of LVM
> tools.
Do you know, which version is good?

> - if your SSD dies, you may have to use vgcfgbackup, manual config edit,
> then vgcfgrestore to remove the cache, because last time I checked, LVM
> tools still were handling writethrough cache the same as writeback,
> disallowing volume activation without the cache and removal of missing
> cache.
> 
Sounds complicated, but possible. Pity that LVM does not auto-remove the
cache if it is not there...

> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



  reply	other threads:[~2015-12-24 15:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-23 10:45 btrfs und lvm-cache? Neuer User
2015-12-23 11:21 ` Martin Steigerwald
2015-12-23 11:38   ` Neuer User
2015-12-23 19:45     ` Noah Massey
2015-12-23 20:07       ` Neuer User
2015-12-23 20:38         ` Holger Hoffstätte
2015-12-23 19:49     ` Chris Murphy
2015-12-23 20:21       ` Neuer User
2015-12-23 20:56         ` Chris Murphy
2015-12-24 15:19           ` Neuer User
2015-12-23 20:24 ` Neuer User
2015-12-23 20:59   ` Chris Murphy
2015-12-24  2:04 ` Duncan
2015-12-24 15:24   ` Neuer User
2015-12-24 14:56 ` Piotr Pawłow
2015-12-24 15:29   ` Neuer User [this message]
2015-12-24 16:42     ` Piotr Pawłow
2015-12-25 17:11       ` Neuer User

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='n5h30b$8vd$1@ger.gmane.org' \
    --to=auslands-kv@gmx.de \
    --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