From: Marc MERLIN <marc@merlins.org>
To: John Stoffel <john@stoffel.org>
Cc: Zdenek Kabelac <zkabelac@redhat.com>,
LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Why use thin_pool_autoextend_threshold < 100 ?
Date: Fri, 27 Jul 2018 16:35:18 -0700 [thread overview]
Message-ID: <20180727233518.ncockmduihftg5do@merlins.org> (raw)
In-Reply-To: <23387.35362.249651.285808@quad.stoffel.home>
On Fri, Jul 27, 2018 at 05:09:54PM -0400, John Stoffel wrote:
> That's the key part that I didn't realize. And this is why I'm still
> leary of btrfs (and zfs for that matter) since as you push the limits,
> they tend to fall off a cliff performance wise, instead of degrading
> more gracefully. So you're obvisously also using source brtfs
> volume(s) for your data being backed up. So can understand what
> you're trying to do...
>
> So is it a single 14tb source btrfs volume, and did you make snapshots
> on a rotating basis to the destinations volumes?
Maybe we should continue this on the btrfs list, I don't want to spam
people here who don't care about btrfs :) but I'll answer this and if we
continue, let's move lists if you don't mind.
btrfs send/receive needs a snapshot for each copy. I then have a script
that decides that I keep X of the older snapshots I don't need anymore
for send/receive to work, but that I keep around for posterity.
Snapshots do not actually cause performance issues that I've noticed day
to day with btrfs, but if you do quotas, or balance (which is a
complicated operation), or btrfsck, then the number of snapshots
matters, and performance gets hurt quite a bit if you have 270
snapshots, like I ended up having in the end :)
> Marc> 4) because I still need the same amount of backups and want the same
> Marc> amount of history, fewer subvolumes means moving each separate subvolume
> Marc> into its own separate filesystem.
>
> So you're doing snapshots of source sub-volumes? I figure you must be
> running into performance problems no matter which end you're talking
> about here, because the btrfs stuff is just going to bite you one way
> or another.
Not really, performance was fine. It was so much better than using
rsync (sometimes by 100x or more)
But yeah, send/receive makes a snapshots of the source, and leaves a
snapshot on the destination volume.
You can work with only 2 snapshots, but I keep more for historical
restores.
> Marc> Then there is the last part that btrfs is still not super stable
> Marc> and can have corruption problems (although in my case I had
> Marc> clear problems due to an underlying unreliable SATA subsystem
> Marc> which caused writes not to make it to all the blocks of each
> Marc> drive of a raid set, something that even careful journalling
> Marc> does not deal with with). So, I have:
>
> Man, you love living dangerously! *grin*
It is a good time to say that I actually use all of this on one
filesystem?
mdadm raid5
bcache
dmcrypt
dm-thin
lvm
btrfs
:)
> I think you're a little crazy using btrfs in this way, *grin* since
> losing my data is a big no-no in my world. Personally love my Netapps
> because they're super reliable and super easy to grow-shrink volumes
> and snapshots just work, along with cloning volumes across to other
> systems.
I used to work at netapp, they're great, but they don't work inside my
laptop, obviously they're not open source and I'd rather avoid using
NFS if I can at this point (ok, they also do iscsi).
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 7F55D5F27AAF9D08
next prev parent reply other threads:[~2018-07-27 23:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-26 16:31 [linux-lvm] Why use thin_pool_autoextend_threshold < 100 ? Marc MERLIN
2018-07-27 12:59 ` Zdenek Kabelac
2018-07-27 18:26 ` Marc MERLIN
2018-07-27 19:31 ` John Stoffel
2018-07-27 19:58 ` Marc MERLIN
2018-07-27 21:09 ` John Stoffel
2018-07-27 23:35 ` Marc MERLIN [this message]
2018-07-31 4:52 ` Chris Murphy
2018-08-01 1:33 ` John Stoffel
2018-08-01 2:43 ` Chris Murphy
2018-08-02 17:42 ` Chris Murphy
2018-07-31 2:44 ` Marc MERLIN
2018-07-31 12:35 ` Zdenek Kabelac
2018-07-31 21:17 ` Marc MERLIN
2018-08-01 11:37 ` Zdenek Kabelac
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=20180727233518.ncockmduihftg5do@merlins.org \
--to=marc@merlins.org \
--cc=john@stoffel.org \
--cc=linux-lvm@redhat.com \
--cc=zkabelac@redhat.com \
/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).