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>