From: Graham Cobb <g.btrfs@cobb.uk.net>
To: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>,
Goffredo Baroncelli <kreijack@inwind.it>
Cc: Josef Bacik <josef@toxicpanda.com>, linux-btrfs@vger.kernel.org
Subject: Re: [RFC][PATCH V5] btrfs: preferred_metadata: preferred device for metadata
Date: Sat, 23 Jan 2021 14:55:52 +0000 [thread overview]
Message-ID: <7b73eb0f-1b59-e6dd-5420-ef2d31a9fd62@cobb.uk.net> (raw)
In-Reply-To: <20210122224253.GI28049@hungrycats.org>
On 22/01/2021 22:42, Zygo Blaxell wrote:
...
>> So the point is: what happens if the root subvolume is not mounted ?
>
> It's not an onerous requirement to mount the root subvol. You can do (*)
>
> tmp="$(mktemp -d)"
> mount -osubvolid=5 /dev/btrfs "$tmp"
> setfattr -n 'btrfs...' -v... "$tmp"
> umount "$tmp"
> rmdir "$tmp"
No! I may have other data on that disk which I do NOT want to become
accessible to users on this system (even for a short time). As a simple
example, imagine, a disk I carry around to take emergency backups of
other systems, but I need to change this attribute to make the emergency
backup of this system run as quickly as possible before the system dies.
Or a disk used for audit trails, where users should not be able to
modify their earlier data. Or where I suspect a security breach has
occurred. I need to be able to be confident that the only data
accessible on this system is data in the specific subvolume I have mounted.
Also, the backup problem is a very real problem - abusing xattrs for
filesystem controls really screws up writing backup procedures to
correctly backup xattrs used to describe or manage data (or for any
other purpose).
I suppose btrfs can internally store it in an xattr if it wants, as long
as any values set are just ignored and changes happen through some other
operation (e.g. sysfs). It still might confuse programs like rsync which
would try to reset the values each time a sync is done.
next prev parent reply other threads:[~2021-01-23 14:57 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-17 18:54 [RFC][PATCH V5] btrfs: preferred_metadata: preferred device for metadata Goffredo Baroncelli
2021-01-17 18:54 ` [PATCH 1/5] Add an ioctl to set the device properties Goffredo Baroncelli
2021-01-17 18:54 ` [PATCH 2/5] Add flags for dedicated metadata disks Goffredo Baroncelli
2021-01-17 18:54 ` [PATCH 3/5] Export dev_item.type in sysfs /sys/fs/btrfs/<uuid>/devinfo/<devid>/type Goffredo Baroncelli
2021-01-17 18:54 ` [PATCH 4/5] btrfs: add preferred_metadata option Goffredo Baroncelli
2021-01-17 18:54 ` [PATCH 5/5] btrfs: add preferred_metadata mode mount option Goffredo Baroncelli
2021-01-18 3:05 ` kernel test robot
2021-01-19 23:12 ` [RFC][PATCH V5] btrfs: preferred_metadata: preferred device for metadata Zygo Blaxell
2021-01-21 8:31 ` Martin Svec
2021-01-20 16:02 ` Josef Bacik
2021-01-20 16:15 ` Johannes Thumshirn
2021-01-20 16:17 ` Josef Bacik
2021-01-20 16:20 ` Zygo Blaxell
2021-01-21 18:16 ` Goffredo Baroncelli
2021-01-21 18:54 ` Zygo Blaxell
2021-01-22 18:31 ` Goffredo Baroncelli
2021-01-22 22:42 ` Zygo Blaxell
2021-01-23 14:55 ` Graham Cobb [this message]
2021-01-23 17:21 ` Zygo Blaxell
2021-01-23 17:44 ` Graham Cobb
2021-01-24 4:00 ` Zygo Blaxell
2021-01-24 20:05 ` Goffredo Baroncelli
2021-01-25 15:21 ` Josef Bacik
2023-01-15 17:00 ` Goffredo Baroncelli
2023-01-15 17:05 ` Goffredo Baroncelli
2023-01-16 8:20 ` Paul Jones
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=7b73eb0f-1b59-e6dd-5420-ef2d31a9fd62@cobb.uk.net \
--to=g.btrfs@cobb.uk.net \
--cc=ce3g8jdj@umail.furryterror.org \
--cc=josef@toxicpanda.com \
--cc=kreijack@inwind.it \
--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).