linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: ST <smntov@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Several questions regarding btrfs
Date: Thu, 2 Nov 2017 07:01:37 -0400	[thread overview]
Message-ID: <173c1ba3-1a05-1a27-7bee-22141200cbf8@gmail.com> (raw)
In-Reply-To: <1509613781.1662.115.camel@gmail.com>

On 2017-11-02 05:09, ST wrote:
>>>>>
>>>>> Ok. I'll use more standard approaches. Which of following commands will
>>>>> work with BTRFS:
>>>>>
>>>>> https://debian-handbook.info/browse/stable/sect.quotas.html
>>>> None, qgroups are the only option right now with BTRFS, and it's pretty
>>>> likely to stay that way since the internals of the filesystem don't fit
>>>> well within the semantics of the regular VFS quota API.  However,
>>>> provided you're not using huge numbers of reflinks and subvolumes, you
>>>> should be fine using qgroups.
>>>
>>> I want to have 7 daily (or 7+4) read-only snapshots per user, for ca.
>>> 100 users. I don't expect users to invoke cp --reflink or take
>>> snapshots.
>> Based on what you say below about user access, you should be absolutely
>> fine then.
>>
>> There's one other caveat though, only root can use the qgroup ioctls,
>> which means that only root can check quotas.
> 
> Only root can check quotas?! That is really strange. How users are
> supposed to know they are about to be out of space?... Is this by design
> so and will remain like that or it's just because this feature was not
> finished yet?
> 
I have no idea if it's intended to be that way, but quite a few things 
in BTRFS are root-only that debatably should not be.  I think the quota 
ioctls fall under the same category as the tree search ioctl, they 
access data that's technically privileged and can let you see things 
beyond the mount point they're run on.

  reply	other threads:[~2017-11-02 11:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-31 16:23 Several questions regarding btrfs ST
2017-10-31 17:45 ` Austin S. Hemmelgarn
2017-10-31 18:51   ` Andrei Borzenkov
2017-10-31 19:07     ` Austin S. Hemmelgarn
2017-10-31 20:06   ` ST
2017-11-01 12:01     ` Austin S. Hemmelgarn
2017-11-01 14:05       ` ST
2017-11-01 15:31         ` Lukas Pirl
2017-11-01 17:20         ` Austin S. Hemmelgarn
2017-11-02  9:09           ` ST
2017-11-02 11:01             ` Austin S. Hemmelgarn [this message]
2017-11-02 15:59               ` ST
     [not found]                 ` <E7316F3D-708C-4D5E-AB4B-F54B0B8471C1@rqc.ru>
2017-11-02 16:28                   ` ST
2017-11-02 17:13                     ` Austin S. Hemmelgarn
2017-11-02 17:32                       ` Andrei Borzenkov
2017-11-01 17:52       ` Andrei Borzenkov
2017-11-01 18:28         ` Austin S. Hemmelgarn
2017-11-01 12:15     ` Duncan
  -- strict thread matches above, loose matches on Subject: below --
2017-10-31 16:29 ST
2017-11-06 21:48 ` waxhead

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=173c1ba3-1a05-1a27-7bee-22141200cbf8@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=smntov@gmail.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).