From: Tomasz Pala <gotar@polanet.pl>
To: "Tomasz Kłoczko" <kloczko.tomasz@gmail.com>
Cc: Linux fs Btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: your mail
Date: Sun, 18 Feb 2018 10:28:02 +0100 [thread overview]
Message-ID: <20180218092802.GA25085@polanet.pl> (raw)
In-Reply-To: <CABB28Cw2+jYynXk1e+Lbx+4otsj5BLXucVV6W3+kvm3RDbH_AQ@mail.gmail.com>
On Sun, Feb 18, 2018 at 08:14:25 +0000, Tomasz Kłoczko wrote:
> For some reasons btrfs pool each volume is not displayed in mount and
> df output, and I cannot find how to display volumes/snapshots usage
> using btrfs command.
In general: not possible without enabling quotas, which in turn impact
snapshot performance significally.
btrfs quota enable /
btrfs quota rescan /
btrfs qgroup sh --sort=excl /
> So now I have many volumes and snapshots in my home directory, but to
> maintain all this I must use root permission. As non-root working in
> my own home which is separated btrfs volume it would be nice to have
> the possibility to delegate permission to create, destroy,
> send/receive, mount/umount etc. snapshots, volumes like it os possible
> on zfs.
I've already noticed this problem on February 10th:
[btrfs-progs] coreutils-like -i parameter, splitting permissions for various tasks
In short: not possible. Regular user can only create subvolumes.
> BTW: someone maybe started working on something like .zfs hidden
> directory functions which is in each zfs volume mountpoint?
In btrfs world this is done differently - don't put main (working) volume in the
root, but mount some branch by default, keeping all the subvolumes next
to it. I.e. don't:
@working_subvolume
@working_subvolume/snapshots
but:
@root_of_the_fs
@root_of_the_fs/working_subvolume
@root_of_the_fs/snapshots
In fact this is manual workaroud for the problem you've mentioned.
> Have few or few tenths snapshots is not so big deal but the same on
> scale few hundreds, thousands or more snapshots I think that would be
> really hard without something like hidden .btrfs/snapshots directory.
With few hundreds of subvolumes btrfs would fail miserably.
> After few years not using btrfs (because previously was quite
> unstable) It is really good to see that now I'm not able to crash it.
It's not crashing with LTS 4.4 and 4.9 kernels, many reports of various
crashes in 4.12, 4.14 and 4.15 were posted here. It is really hard to say,
which of the post-4.9 kernels have reliable btrfs.
--
Tomasz Pala <gotar@pld-linux.org>
next prev parent reply other threads:[~2018-02-18 9:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-18 8:14 Tomasz Kłoczko
2018-02-18 9:28 ` Tomasz Pala [this message]
2018-02-18 9:34 ` your mail Tomasz Pala
-- strict thread matches above, loose matches on Subject: below --
2016-09-01 2:02 Fennec Fox
2016-09-01 7:44 ` your mail M G Berberich
2016-09-01 11:17 ` Austin S. Hemmelgarn
2016-09-01 16:44 ` Kyle Gates
2016-09-01 17:06 ` Austin S. Hemmelgarn
2016-09-02 1:51 ` Jeff Mahoney
2016-09-01 21:15 ` M G Berberich
[not found] <1330599216.71336.YahooMailNeo@web30703.mail.mud.yahoo.com>
2012-03-01 12:41 ` (unknown) bella tk
2012-03-01 12:58 ` your mail David Sterba
2012-03-01 14:26 ` Chris Mason
2011-09-20 15:24 (unknown) Ken D'Ambrosio
2011-09-20 15:35 ` your mail Hugo Mills
2011-09-20 15:40 ` Hugo Mills
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=20180218092802.GA25085@polanet.pl \
--to=gotar@polanet.pl \
--cc=kloczko.tomasz@gmail.com \
--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).