From: Alex MacCuish <alex@maccuish.de>
To: Andrei Borzenkov <arvidjaar@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: Adding a UUID to the top level subvol on an existing filesystem
Date: Tue, 11 Jan 2022 08:31:12 +0100 [thread overview]
Message-ID: <02c7933d-e444-0eba-e46f-2cab8e7601fa@maccuish.de> (raw)
In-Reply-To: <f9e3796c-573a-a577-7a1f-4227b89e4da1@gmail.com>
I'm using btrbk which has worked successfully for me on other systems.
In their FAQ (https://github.com/digint/btrbk/blob/master/doc/FAQ.md),
they state:
---
If your file system was created with btrfs-progs < 4.16, the btrfs root
subvolume (id=5) has no UUID. You can check this by calling:
|# btrfs subvolume show /mnt/btr_pool / Name: <FS_TREE> UUID: - [...] |
Without a UUID, the snapshots would get no parent_uuid, leaving btrbk
unable to track parent/child relationships. In this case, btrbk refuses
to create snapshots and backups.
---
I've asked there on whether this can be worked around but no luck.
Am 10.01.22 um 12:38 schrieb Andrei Borzenkov:
> On 09.01.2022 13:11, Alex MacCuish wrote:
>> For use of send/receive, I need my subvolume id 5 to have a UUID. I see
> You always send read-only snapshot and send/receive is using UUID of this
> snapshot, not of original subvolume. Do you get any error or something
> does not work?
>
>> here (https://www.spinics.net/lists/linux-btrfs/msg76016.html) that it
>> was discussed to add this feature to say btrfstune, but I can't find any
>> option to do it. What's the best way to do this and ensure current
>> subvolumes have the correct parent ID?
>>
>> ---
>>
>> Linux xxx.xxx.xxx 5.15.11-051511-generic #202112220937 SMP Wed Dec 22
>> 10:04:02 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
>>
>> btrfs-progs v5.4.1
>>
>> btrfs fi show
>>
>> Label: 'storage' uuid: 61538bc8-fc27-4818-9cc9-133938e252da
>> Total devices 4 FS bytes used 2.35TiB
>> devid 1 size 1.82TiB used 1.63TiB path /dev/sdd
>> devid 2 size 1.82TiB used 1.63TiB path /dev/sdc
>> devid 3 size 1.82TiB used 744.03GiB path /dev/sdb
>> devid 4 size 931.51GiB used 738.03GiB path /dev/sde
>>
>> btrfs fi df /mnt/storage
>> Data, RAID1: total=2.35TiB, used=2.34TiB
>> System, RAID1: total=32.00MiB, used=368.00KiB
>> Metadata, RAID1: total=5.00GiB, used=4.32GiB
>> GlobalReserve, single: total=512.00MiB, used=0.00B
>>
>> btrfs subvolume show /mnt/storage/
>> /
>> Name: <FS_TREE>
>> UUID: -
>> Parent UUID: -
>> Received UUID: -
>> Creation time: -
>> Subvolume ID: 5
>> Generation: 4620363
>> Gen at creation: 0
>> Parent ID: 0
>> Top level ID: 0
>> Snapshot(s):
>> CN_IMGS
>> CN_PKGS
>> CN_PKGS/.snapshots
>> CN_SHARE
>> CN_SHARE/.snapshots
>> CN_MEDIA
>> CN_MEDIA/.snapshots
>> CN_HOMES
>> CN_HOMES/.snapshots
>> CN_BACKUPS
>>
prev parent reply other threads:[~2022-01-11 7:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-09 10:11 Adding a UUID to the top level subvol on an existing filesystem Alex MacCuish
2022-01-10 11:38 ` Andrei Borzenkov
2022-01-11 7:31 ` Alex MacCuish [this message]
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=02c7933d-e444-0eba-e46f-2cab8e7601fa@maccuish.de \
--to=alex@maccuish.de \
--cc=arvidjaar@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).