Unless the top level is mounted there is no way to know the
details of all the subvolume. For example:
mount -o subvol=sv1/newsv1 /dev/sdb /btrfs
btrfs su list /btrfs
ID 257 gen 12 top level 5 path sv1
ID 258 gen 9 top level 257 path sv1/snap
ID 259 gen 11 top level 257 path sv1/newsv1
You can't subvol show for sv1 and sv1/snap as its paths aren't
accessible to the user unless the its top level is mounted.
This patch adds two new options to the existing btrfs subvol show
cli. They are --rootid/-r or --uuid/-u, with this now the user will
be able to look for a subvolume using the rootid OR the uuid.
./btrfs su show -r 257 /btrfs
sv1
Name: sv1
UUID: 30129358-c69d-3e4a-a662-29509cc69c95
Parent UUID: -
Received UUID: -
Creation time: 2017-07-11 20:32:57 +0800
Subvolume ID: 257
Generation: 12
Gen at creation: 7
Parent ID: 5
Top level ID: 5
Flags: -
Snapshot(s):
sv1/snap
Signed-off-by: Anand Jain <anand.jain@oracle.com>
[ minor adjustments in the help text ]
Signed-off-by: David Sterba <dsterba@suse.com>
This is a kind of preparatory patch for the patch which will add
--rootid and --uuid options for the btrfs subvol show command.
As of now btrfs subvol show is using the external user provided subvol
path to show in the output. Which is kind of confusing.
btrfs su show /btrfs
/btrfs <--
Name: <FS_TREE>
It will be even more confusing when proposed --uuid or --rootid
options are used.
btrfs su show --rootid 258 /btrfs
/btrfs <--
Name: snap <--
UUID: 9630a45f-e647-4242-bd19-97590b4e20b2
Parent UUID: 30129358-c69d-3e4a-a662-29509cc69c95
Received UUID: -
Creation time: 2017-07-12 12:43:28 +0800
Subvolume ID: 258
Generation: 9
Gen at creation: 9
Parent ID: 257
Top level ID: 257
Flags: -
Snapshot(s):
Now with this patch, it will only show what is provided by the root_info.
btrfs su show --rootid 258 /btrfs
sv1/snap <--
Name: snap
UUID: 9630a45f-e647-4242-bd19-97590b4e20b2
Parent UUID: 30129358-c69d-3e4a-a662-29509cc69c95
Received UUID: -
Creation time: 2017-07-12 12:43:28 +0800
Subvolume ID: 258
Generation: 9
Gen at creation: 9
Parent ID: 257
Top level ID: 257
Flags: -
Snapshot(s):
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The toplevel subvolume is special and the other listing code leaves it
out so we have to add several special cases to handle it. There's no
backreference so the path is built artificially. New helper
btrfs_get_toplevel_subvol is a reduced version of btrfs_get_subvol.
There's some information usually missing for the toplevel subvolume, eg.
the uuid or creation info. This has to be fixed on the mkfs side, the
other subvolumes are created by kernel.
Example:
/mnt
Name: <FS_TREE>
UUID: -
Parent UUID: -
Received UUID: -
Creation time: -
Subvolume ID: 5
Generation: 233
Gen at creation: 0
Parent ID: 0
Top level ID: 0
Flags: -
Snapshot(s):
subv1
Signed-off-by: David Sterba <dsterba@suse.com>
The utils helper is not verbose in case of an error, for now the helper
used for subvolume listing will print the error message but not
duplicate the ioctl anymore.
Signed-off-by: David Sterba <dsterba@suse.com>
The option 'v' was mistakenly added in
2ed161bd28 but there's no such option for
create at the moment, remove it.
Signed-off-by: David Sterba <dsterba@suse.com>
There was already the logic for verbose output, but the flag parsing did
not include it.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Signed-off-by: David Sterba <dsterba@suse.com>
get_subvol_info() is useful as we are adding more features around
subvolume. This function was inline with the function
cmd_subvol_show().
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
"sub get-default" does't work since the following commit.
commit 176aeca9a148 ("btrfs-progs: add getopt stubs where needed")
* actual result
==================================================
# ./btrfs sub get-default /btrfs
btrfs subvolume get-default: too few arguments
usage: btrfs subvolume get-default <path>
Get the default subvolume of a filesystem
==================================================
* expected result
==================================================
# btrfs sub get-default /btrfs
ID 5 (FS_TREE)
==================================================
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The subvol sync command crashed randomly at the end with
*** glibc detected *** btrfs: double free or corruption (out): 0x00000000006ab040 ***
This is caused by running out of the ids array in case there are more
than 128 subvolumes. The array is increased in steps but does not
account the size of the item, so there was room for 1024 / 8 = 128
subvolume ids.
Fixes: c9f885ec89 ("btrfs-progs: subvol: let sync check only current deletions")
Signed-off-by: David Sterba <dsterba@suse.com>
Commands that do not take any options do not use getopt, which means the
standard option separator "--" does not work. Update all command
handlers that need it, argv needs to be referenced using the optind that
is correctly pointed after the separator.
Signed-off-by: David Sterba <dsterba@suse.com>
A subvolume is a directory with inode number 256 on a btrfs filesytem.
Add the missing check to test_issubvolume for completeness, otherwise we
always do that in btrfs_open_dir.
Signed-off-by: David Sterba <dsterba@suse.com>
The subvolume show command does not take any optios but at least it
should honor "--", as reported.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110181
Reported-by: <moviuro+kernel@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
We can use btrfs_open_dir() to check whether target dir is
in btrfs's mount point before open, instead of checking it in
kernel space of ioctl, and return fuzzy error message.
Before patch:
# (/mnt/tmp is not btrfs mountpoint)
#
# btrfs subvolume create /mnt/tmp/123
Create subvolume '/mnt/tmp/123'
ERROR: cannot create subvolume - Inappropriate ioctl for device
#
After patch:
# btrfs subvolume create /mnt/tmp/123
ERROR: not btrfs filesystem: /mnt/tmp
#
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
In my local change to 07cc891d1d
("btrfs-progs: Simplify all-subvolumn-clean condition for
wait_for_subvolume_cleaning") that reversed the meaning of the variable
dirty -> clean, I made a mistake and broke 'subvol sync' that will not
wait as expected and ends prematurely. Zhao Lei's original patch worked.
CC: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Instead of using a dirty-subvolumn-counter in old code, this patch
turn to use a simple and direct way:
If (not dirty-subvolumn found in current loop) {
return all_clean;
}
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
No need prepare memory for enumerate_dead_subvols() in caller, and pass
additional argument for allocated length.
Just do every thing inside enumerate_dead_subvols(), it will not
increase malloc count, but make code simple.
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Reproduce:
# btrfs subvolume sync /mnt/btrfs
Subvolume id 323 is gone
# echo $?
1
#
Reason:
wait_for_subvolume_cleaning() return !0 in right case, because
value of ret is set to "is subvolume clean" state before return.
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
We can trigger the bug by following operation:
(no wait between commands 3~5)
btrfs subvolume create /mnt/btrfs/mysubvol
btrfs subvolume snapshot /mnt/btrfs/mysubvol /mnt/btrfs/mysubvol_snap
btrfs subvolume delete /mnt/btrfs/mysubvol_snap
btrfs subvolume delete /mnt/btrfs/mysubvol
btrfs subvolume sync /mnt/btrfs
The last command will not exit.
Reason:
List of "deleted subvolumes" are not currectly set.
It caused by a typo of value assign, in detail:
*ids[idx] = sh->offset;
should be:
(*ids)[idx] = sh->offset;
So only first element is set to right memory address.
If there are multiple "deleted subvolumes", program will
keep wait.
Above typo also caused some segment fault in my test.
This patch fixed above bug.
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
We don't need to use value of mntid in cmd_subvol_show(), no need
to get its value.
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
At some places we do not clear the whole ioctl structure and could
pass garbage to kernel. Zero the ioctl vol_args and use a helper for
copying the path.
Signed-off-by: David Sterba <dsterba@suse.cz>
So far the subvol sync command takes a shortcut and looks if there are
any deleted subvols at all. It does not print the deleted subvolumes as
they get cleaned. Arguably this is what the user would like to see and
has to do
$ btrfs subvol sync /path $(btrfs subvol list -d /path | "extract the ids")
to see the progress.
Make it look for all currently deleted subvolumes automatically and
print the progress as if the ids were listed manually.
This is a slight change in the semantics of the command. Previously, any
new subvol deletion would prevent subvol sync to return. To simulate the
old behaviour, run 'subvol sync' in a loop until it returns 0.
Signed-off-by: David Sterba <dsterba@suse.cz>
- capitalize UUID
- print otime with timezone
- rename 'Object ID' to 'Subvolume ID'
- add ID to Parent and Top level
Signed-off-by: David Sterba <dsterba@suse.cz>
When we want to delete a subvol, we first check to see whether it is
a subvolume or not. After the check, we are sure that it is a valid
subvol, don't have to check its name.
Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com>
[removed unused variable 'len']
Signed-off-by: David Sterba <dsterba@suse.cz>
cmd_snapshot_usage in cmds-subvolume.c contains the short description
twice. Remove the first one.
Signed-off-by: Martin Volf <martin.volf.42@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.cz>