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>
Commit bab2c565 accidentally broke 'subvol get-default' command by
removing almost all of the underlying code. Bring it back with some
fixes and improvements.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Don't pass a pointer to root_id to resolve_root(). It's always the same as
ri->root_id, passing a pointer hints that root_id can somehow change which is
not true.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
two new commands that make use of the new path resolving functions
implemented for scrub, doing the resolving in-kernel. the result for both
commands is a list of files belonging to that inode / logical address.
Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Stephane Chazelas <stephane.chazelas@gmail.com> writes:
> I've got a btrfs FS with 84 subvolumes in it (some created with
> "btrfs sub create", some with "btrfs sub snap" of the other
> ones). There's no nesting of subvolumes at all (all direct children
> of the root subvolume).
>
> The "btrfs subvolume list" is only showing 80 subvolumes. The 4
> missing ones (1 original volume, 3 snapshots) do exist on disk and
> files in there have different st_devs from any other subvolume.
>
> I found
> http://thread.gmane.org/gmane.comp.file-systems.btrfs/8123/focus=8208
>
> which looks like the same issue, with Li Zefan saying he had a
> fix, but I couldn't find any mention that it was actually fixed.
Li Zefan <lizf@cn.fujitsu.com> replied:
> After that, I posted a patch to fix btrfs-progs, which Chris aggreed
> on:
>
> http://marc.info/?l=linux-btrfs&m=129238454714319&w=2
So this btrfs-progs patch should fix missing subvolumes in the output of
"subvolume list":
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
split list_subvols to separate functions and allow printing only in the
containing function. lets us make use of those functions when resolving
logical addresses.
Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Add subcommand to get the default subvolume of btrfs filesystem
V2->V3:
* add man page
* based on http://git.darksatanic.net/repo/btrfs-progs-unstable.git
integration-20110705
Reviewed-by: Andreas Philipp <philipp.andreas@gmail.com>
Reviewed-by: Goffredo Baroncelli <kreijack@libero.it>
Reported-by: Yang, Yi <yi.y.yang@intel.com>
Signed-off-by: Zhong, Xin <xin.zhong@intel.com>
In the file btrfs-list.c version.h was included but not used. So just
drop it.
Signed-off-by: Andreas Philipp <philipp.andreas@gmail.com>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
There was some discussion on "where" subvolumes live in. Why do we not
simply print the parent ID for each subvolume in btrfs subvolume list?
This patch adds this functionality when called with parameter "-p".
Signed-off-by: Andreas Philipp <philipp.andreas@gmail.com>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
When building on ppc64 I hit a number of warnings in printf:
btrfs-map-logical.c:69: error: format ‘%Lu’ expects type ‘long long
unsigned int’, but argument 4 has type ‘u64’
Fix them.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
Hi Chris,
below is enclosed a trivial patch, which has the aim to improve the error
reporting of the "btrfs" command.
You can pull from
http://cassiopea.homelinux.net/git/btrfs-progs-unstable.git
branch
strerror
I changed every printf("some-error") to something like:
e = errno;
fprintf(stderr, "ERROR: .... - %s", strerror(e));
so:
1) all the error are reported to standard error
2) At the end of the message is printed the error as returned by the system.
The change is quite simple, I replaced every printf("some-error") to the line
above. I don't touched anything other.
I also integrated a missing "printf" on the basis of the Ben patch.
This patch leads the btrfs command to be more "user friendly" :-)
Regards
G.Baroncelli
btrfs-list.c | 40 ++++++++++++++++++++++--------
btrfs_cmds.c | 77 ++++++++++++++++++++++++++++++++++++++++-----------------
utils.c | 6 ++++
3 files changed, 89 insertions(+), 34 deletions(-)
Signed-off-by: Chris Mason <chris.mason@oracle.com>
If we meet a bad extent type, find_updated_files is going
to print random things. Better warn the user about what
happens.
This fixes:
btrfs-list.c: Dans la fonction «find_updated_files» :
btrfs-list.c:668: attention : «disk_offset» may be used uninitialized in this function
btrfs-list.c:668: note: «disk_offset» was declared here
btrfs-list.c:667: attention : «disk_start» may be used uninitialized in this function
btrfs-list.c:667: note: «disk_start» was declared here
btrfs-list.c:666: attention : «len» may be used uninitialized in this function
btrfs-list.c:666: note: «len» was declared here
make: *** [btrfs-list.o] Erreur 1
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
When we compile btrfs-progs in RHEL5(with default gcc version 4.1.2 20070626),
we can get following error:
cc1: warnings being treated as errors
btrfs-list.c: In function 'find_updated_files':
btrfs-list.c:668: warning: 'disk_offset' may be used uninitialized in this function
btrfs-list.c:667: warning: 'disk_start' may be used uninitialized in this function
btrfs-list.c:666: warning: 'len' may be used uninitialized in this function
make: *** [btrfs-list.o] Error 1
These varient are always initialized except inconsistent data in file system.
We can set initial value for these variant for this situation.
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
When we compile btrfs-progs in RHEL5(with default gcc 4.1.2 and glibc-2.5-18),
we can get following error:
cc1: warnings being treated as errors
btrfs-list.c: In function 'ino_resolve':
btrfs-list.c:511: warning: implicit declaration of function 'strndup'
btrfs-list.c:511: warning: incompatible implicit declaration of built-in function 'strndup'
make: *** [btrfs-list.o] Error 1
...
cc1: warnings being treated as errors
btrfs.c: In function 'split_command':
btrfs.c:168: warning: implicit declaration of function 'strndup'
btrfs.c:168: warning: incompatible implicit declaration of built-in function 'strndup'
make: *** [btrfs-list.o] Error 1
We can add _GNU_SOURCE definition according man strndup.
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
btrfs-subvol find-new <subvol> <id> will search through a given subvol
and print out all the files with extents newer than a given id.
Care must be taken to make sure any pending delalloc is on disk before
running this because that won't show up in the output.
This commit introduces a new command called 'btrfs' for managing
a btrfs filesystem. 'btrfs' handles:
- snapshot/subvolume creation
- adding/removal of volume (ie: disk)
- defragment of a tree
- scan of a device searching a btrfs filesystem
- re-balancing of the chunk on the disks
- listing subvolumes and snapshots
This has also been updated to include the new defrag range ioctl.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Liu Bo