This patch introduces '-g' '-c' '--sort' options
The option '-g' can help you filter the subvolumes by the generation, you may
use it just like:
btrfs subvol list -g +/-value <path>
'+' means the generation of the subvolumes should >= the value you specified.
'-' means the generation should <= the value
If you don't input either '+' nor '-', this command will list the subvolumes
that their generation equals to the value.
However if you want to find gengeration between value1 and value2
you may use the above like:
btrfs sub list -g -value1 -g +value2 <path>
The option '-c' can help you filter the subvolumes by the ogeneration, you may
use it just like:
btrfs subvol list -c +/-value <path>
The usage is the same to '-g'
You might want to list subvolumes in order of some items, such as root id, gen
and so on, you can use '--sort'. Now you can sort the subvolumes by root id,
gen, ogen and path.
For example:
If you want to list subvolumes in order of rootid, you can use the option like
that:
btrfs sub list --sort=+/-rooid <path>
Here, '+' means the result is sorted by ascending order. '-' is by descending
order. If you don't specify either '+' nor '-', the result is sorted by
default - ascending order.
If you want to combine sort items, you do it like that:
btrfs sub list --sort=-rootid,+path,ogen,gen <path>
Signed-off-by: Wang Shilong <wangsl-fnst@cn.fujitsu.com>
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
This patch adds the introduction of the new option '-r' into the man page of
'btrfs subvolume list' command.
Signed-off-by: Zhou Bo <zhoub-fnst@cn.fujitsu.com>
We want 'btrfs subvolume list' only to list readonly subvolumes, this patch set
introduces a new option 'r' to implement it.
You can use the command like that:
btrfs subvolume list -r <path>
Original-Signed-off-by: Zhou Bo <zhoub-fnst@cn.fujitsu.com>
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
The current code of list_subvols() has very bad scalability, if we want to
add new filter conditions or new sort methods, we have to modify lots of code.
Beside that, the most code of list_snapshots() is similar to list_subvols(),
So I restructure list_subvols(), and split the subvolume filter function,
the subvolume sort function and the output function from list_subvols().
In order to implement it, we defined some importtant structures:
struct btrfs_list_filter {
btrfs_list_filter_func filter_func;
void *data;
};
struct btrfs_list_comparer {
btrfs_list_comp_func comp_func;
int is_descending;
};
struct {
char *name;
char *column_name;
int need_print;
} btrfs_list_columns[];
If we want to add a new filter condition, we can choose a suitable filter
function, or implement a new filter function[1], and add it into a set of
the filters, and then pass the filter set into list_subvols(). We also can
mix several filters (just add those filters into the set, and pass the set
into list_subvols()) if the users specify two or more filter conditions.
The subvolume sort function is similar to the subvolume filter function. The
differentiation is the order of comparers in the array which is passed into
list_subvols() show us the priority of the sort methods.
The output function is different with the above two functions, we define a
array to manage all the columns that can be outputed, and use a member variant
(->need_print) to control the output of the relative column. Some columns are
outputed by default. But we can change it according to the requirement of the
users.
After appling this patch, we needn't implement a independent list_snapshots()
function, just pass a filter function which is used to identify the snapshot
into list_subvols().
[1]: If we implement new filter functions or compare functions, we must add
them into the array all_filter_funcs or the array all_comp_funcs, and modify
the relative enum variants(btrfs_list_filter_enum, btrfs_list_comp_enum).
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Now we check if the root item contains otime and uuid or not by comparing
->generation_v2 and ->generation of the btrfs_root_item structure, it is
wrong because it is possbile that ->generation may equal to the first
variant of the next item. We fix this problem by check the size of btrfs_root_item,
if it is larger than the original one, the new btrfs_root_item contains otime
and uuid. we needn't worry the case that the new filesystem is mounted on the
old kernel. because the otime and uuid are not changed on the old kernel, we can
get the correct result even on the kernel.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
This patch fixes the following warning:
cmds-subvolume.c:283:3: warning: implicit declaration of function "list_snapshots"
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
btrfs f l /
No valid Btrfs found on /
Segmentation fault (core dumped)
open_ctree can return NULL, we need to check that.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Applications would need to know the uuid to manage the configurations
associated with the subvol and snapshots
Signed-off-by: Anand Jain <anand.jain@oracle.com>
The idea is that we usually use snapshot to backup/restore our data, and the
common way can be a cron script which makes lots of snapshots, so we can end
up with spending some time to find the latest snapshot to restore.
This adds a feature for 'btrfs subvolume list' to let it list snapshots by their
_created_ generation.
What we need to do is just to list them in descending order and get the latest
snapshot. What's more, we can find the oldest snapshot as well by listing
snapshots in ascending order.
Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com>
This adds the ability to show root's modification generation when we use
btrfs subvol list.
NOTE:
Like file's atime and ctime, root's generation also has 'creation generation'
and 'modification generation'.
The generation that we're going to show is 'modification generation', and the
next patch is going to show 'creation generation'.
Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com>
Btrfs's subvolume/snapshot is limited to
[BTRFS_FIRST_FREE_OBJECTID, BTRFS_LAST_FREE_OBJECTID], so just apply the range.
Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com>
If we find the block by seach corresponding fs tree, we should return 0,
and tell the caller we pass the check.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
btrfsck misinformed "unresolved ref root" message when there were several
snapshots in the file system. The patch(commit cfdd42686c70) tried to fix
this bug, but didn't fix it completely. If the metadata was stored in a
shared leaf of the tree, the problem would happen again. This patch fixes
it by another way, we don't check the relationship of the trees when we
traverse the fs/file tree, we just do the check when we merge the snapshot
records to the root cache.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
The variant named 'leaf' in is_child_root() still hold old result after
we get the next leaf, it make btrfsck returns the wrong result, such as
"unresolved ref root ..", fix it.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
This patch fixed the following warning:
cmds-send.c:464:6: warning: ‘ret' may be used uninitialized in this function [-Wuninitialized]
crc32c.c:121:1: warning: control reaches end of non-void function [-Wreturn-type]
send-utils.c:69:11: warning: ‘comp' may be used uninitialized in this function [-Wuninitialized]
send-utils.c:126:6: warning: ‘comp' may be used uninitialized in this function [-Wuninitialized]
send-utils.c:99:22: warning: ‘entry' may be used uninitialized in this function [-Wuninitialized]
btrfs.c:261:2: warning: implicit declaration of function ‘crc32c_optimization_init' [-Wimplicit-function-declaration]
btrfs.c:105:2: warning: ‘cmd' may be used uninitialized in this function [-Wuninitialized]
restore.c:435:12: warning: ignoring return value of ‘ftruncate', declared with attribute warn_unused_result [-Wunused-result]
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Segmentation fault occurred in the following command.
# btrfs qgroup limit
Segmentation fault
So, we should check a minimum number of arguments.
Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
My patch
04609add88
introduced a regression where if you mkfs'ed a group of disks with different
sizes it limited the disks to the size of the first one that is specified.
This was not the intent of my patch, I only want it to limit the size based
on the -b option, so I've reworked the code to pass in a max block count and
that fixes the issue. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
find_mount_root had the problem that it tried to conclude from a file system
path to a mount point, taking the fsid as an indicator. This only works if
no two subvolumes (sharing the same btrfs fsid) are mounted in the same
hierarchy.
Now instead, we're parsing /etc/mtab and look for the longest match.
Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
The initial btrfs send code was easily confused by relative paths and by
anything that wasn't in the root of the FS. This fixes it to take
relative paths.
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Add user space commands for btrfs send/receive.
Signed-off-by: Alexander Block <ablock84@googlemail.com>
Reviewed-by: David Sterba <dave@jikos.cz>
Reviewed-by: Arne Jansen <sensille@gmx.net>
Reviewed-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
Reviewed-by: Alex Lyakas <alex.bolshoy.btrfs@gmail.com>
Btrfs send/receive and btrfs props needs this ioctl. This patch
requires a recent kernel with the "Btrfs: use _IOR for
BTRFS_IOC_SUBVOL_GETFLAGS" patch applied.
Signed-off-by: Alexander Block <ablock84@googlemail.com>
The right option is 'o' not 'c'. And this tool is used for the block devices
on which there is a btrfs file system, so change "mount_point" to "device".
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Usage of balancing btrfs is "btrfs filesystem balance",
not "btrfs device balance". And remove unneeded
usage of "btrfs filesystem defrag".
Also fix some typos and over 80 columns.
Signed-off-by: Akira Fujita <a-fujita@rs.jp.nec.com>
The function scrub_fs_info( ) closes and reopen a file handle
passed as argument, when a caller uses the file handle even after the
call.
The function scrub_fs_info( ) is updated to remove the file handle
argument, and instead uses a private own file handle.
The callers are updated to not pass the argument.
The btrfs filesystem resize command defaults to only resizing the
filesystem for devid 1, and must have a devid passed in to resize the
filesystem for the other devices in the filesystem.
Additionally the documentation lacked information on how to actually
resize the underlying partition so this provides a little more detail.
Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>
Andrei Popa reported that there were two typos of default as dafault,
this patch fixes those two typos up.
Signed-off-by: Chris Samuel <chris@csamuel.org>
I had a test that creates a 7gig raid1 device but it was ending up wonky
because the second device that gets added is the full size of the disk
instead of the limited size. So enforce the limited size on all disks
passed in at mkfs time, otherwise our threshold calculations end up wonky
when doing chunk allocations. Thanks,
Signed-off-by: Josef Bacik <josef@redhat.com>
If the fs/file tree is not the parent of the snapshot, it is reasonable
that we can not find the relative reference and back reference. But btrfsck
doesn't consider this case, and reports "unresolved refs" message, it's wrong,
fix it.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
On Wed 08-02-12 22:05:26, Phillip Susi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/08/2012 06:20 PM, Jan Kara wrote:
> > Thanks for your reply. I admit I was not sure what exactly size argument
> > should be. So after looking into the code for a while I figured it should
> > be a total size of the filesystem - or differently it should be size of
> > virtual block address space in the filesystem. Thus when filesystem has
> > more devices (or admin wants to add more devices later), it can be larger
> > than the first device. But I'm not really a btrfs developper so I might be
> > wrong and of course feel free to fix the issue as you deem fit.
>
> The size of the fs is the total size of the individual disks. When you
> limit the size, you limit the size of a disk, not the whole fs. IIRC,
> mkfs initializes the fs on the first disk, which is why it was using that
> size as the size of the whole fs, and then adds the other disks after (
> which then add their size to the total fs size ).
OK, I missed that btrfs_add_to_fsid() increases total size of the
filesystem. So now I agree with you. New patch is attached. Thanks for your
review.
> It might be nice if
> mkfs could take sizes for each disk, but it only seems to take one size
> for the initial disk.
Yes, but I don't see a realistic usecase so I don't think it's really
worth the work.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
>From e5f46872232520310c56327593c02ef6a7f5ea33 Mon Sep 17 00:00:00 2001
From: Jan Kara <jack@suse.cz>
Date: Fri, 10 Feb 2012 11:44:44 +0100
Subject: [PATCH] mkfs: Handle creation of filesystem larger than the first device
mkfs does not properly check requested size of the filesystem. Thus if the
requested size is larger than the first device, it happily creates larger
filesystem than a device it resides on which results in 'attemp to access
beyond end of device' messages from the kernel. So verify specified filesystem
size against the size of the first device.
CC: David Sterba <dsterba@suse.cz>
Signed-off-by: Jan Kara <jack@suse.cz>
wangshilong