This changes restore to set the i_size of the files it
copies out based on the size in the inode. It also changes
it to skip over holes.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
/proc/mounts contains device names that don't exist,
we end up erroring out because we're not able to stat
the device (that doesn't exist).
Fix this by allowing the mkfs when the target device doesn't exist.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Profiles other than SINGLE for mixed chunks might sound a bit strange,
but there is nothing in the filesystem that prevents a crazy user from
doing it. So make "btrfs fi df" report them properly.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
* Initialize ret in btrfs_csum_file_block
* Do not abort when xattr is not supported in the source directory
* Remove size limitation of 256M
* Alloc data chunk in a smaller size (8M) to make btrfs image smaller
* Let user specify the btrfs image name
Depends on below patch from samsung guys:
http://marc.info/?l=linux-btrfs&m=127858068226025&w=2
Signed-off-by: Zhong, Xin <xin.zhong@intel.com>
During the commands:
- btrfs filesystem show
- btrfs device scan
the devices "scanned" are extracted from /proc/partitions. This
should avoid to scan devices not suitable for a btrfs filesystem like cdrom
and floppy or to scan not existant devices.
The old behavior (scan all the block devices under /dev) may be
forced passing the "--all-devices" switch.
Hello,
While going through the mkfs.c, I noticed there is an issue for label
length checking, mkfs.btrfs will crashed if the label length exceeding
255 bytes, it's easy to triggered that out as below:
jeff@pibroch:~/opensource/btrfs-progs$ sudo ./mkfs.btrfs -L `perl -e
'print "A"x256'` /usr/src/linux-3.0/img0
WARNING! - Btrfs v0.19-35-g1b444cd IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using
*** buffer overflow detected ***: ./mkfs.btrfs terminated
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x50)[0xb7774df0]
/lib/i386-linux-gnu/libc.so.6(+0xe4cca)[0xb7773cca]
/lib/i386-linux-gnu/libc.so.6(__strcpy_chk+0x3f)[0xb777305f]
./mkfs.btrfs[0x805acc4]
./mkfs.btrfs[0x805def6]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0xb76a5e37]
./mkfs.btrfs[0x8048ef1]
======= Memory map: ========
......
a tiny patch could fix it.
Signed-off-by: Jie Liu <jeff.liu@oracle.com>
check_mounted() returns kernel-style negative errors.
Patch drops sign for strerror().
Before the patch:
check_mounted(): Could not open /dev/sdb2
Could not check mount status: Unknown error 18446744073709551603
After the patch:
check_mounted(): Could not open /dev/sdb2
Could not check mount status: Permission denied
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Check whether there are the right number of arguments (exatly 2 without
the flag -r) in the subcommand handler for the btrfs subvolume snapshot
command.
Signed-off-by: Andreas Philipp <philipp.andreas@gmail.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>
From c04da1655df6d75db834ddbd3a3b4a58a0d9a0c9 Mon Sep 17 00:00:00 2001
From: Wang Sheng-Hui <shhuiw@gmail.com>
Date: Mon, 18 Jul 2011 02:17:31 -0500
Subject: [PATCH] btrfs-progs-unstable: replace debug-tree to btrfs-debug-tree in INSTALL
debug-tree doesn't exist after btrfs-progs installed.
Use btrfs-debug-tree to print FS metadata in text form,
not debug-tree.
Signed-off-by: Wang Sheng-Hui <shhuiw@gmail.com>
Stephane Chazelas and Andreas Philipp spotted that the earlier patch
fixing this issue was incomplete, and should also update the argument-
count checking code as well.
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
new version of check_mounted() returning more information gathered while
searching. check_mounted() is now a wrapper for check_mounted_where(). the
new version is needed by scrub.c
Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
- scrub structs added
- ioctls for scrub
- BTRFS_FSID_SIZE moved
Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
- scrub commands added
- open_file_or_dir no longer static (needed by scrub.c)
Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
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>
Update the manpage entries for the btrfs subvolume list command to
reflect the newly created additional option '-p'.
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>
Just do a few simple style/layout changes to make the makefile look
better.
Signed-off-by: Andreas Philipp <philipp.andreas@gmail.com>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
When issuing 'make clean' not all files generated by the individual
targets have been deleted since some files have been missing in the
definition of the 'make clean' target.
Signed-off-by: Andreas Philipp <philipp.andreas@gmail.com>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
gcc 4.6 complains about several possible use-before-initialise cases
in mkfs, and stops. Fix these by initialising one of the variables in
question, and using the correct error-handling paths for the
remainder.
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
Bcp was assuming that a path on the command line would never have a slash after
it, which is silly, and would cause the first letter of everything in the root
of the source to be truncated. Instead, use os.path.relpath to handle
it properly.
Signed-off-by: Carey Underwood <cwillu@cwillu.com>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
when no output file is given, info_file stays NULL and the following
fprintf segfaults. Default to stdout.
Signed-off-by: Arne Jansen <sensille@gmx.net>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
Smart gcc noticed use of uninitialized warning when compiled
with -O0 flags:
mkfs.c:1291: error: 'file' may be used uninitialized in this function
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
found by valgrind:
==2559== 16 bytes in 1 blocks are definitely lost in loss record 3 of 19
==2559== at 0x4C2720E: malloc (vg_replace_malloc.c:236)
==2559== by 0x412F7E: pretty_sizes (utils.c:1054)
==2559== by 0x4179E9: main (mkfs.c:1395)
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
Found by valgrind:
==8968== Use of uninitialised value of size 8
==8968== at 0x41CE7D: crc32c_le (crc32c.c:98)
==8968== by 0x40A1D0: csum_tree_block_size (disk-io.c:82)
==8968== by 0x40A2D4: csum_tree_block (disk-io.c:105)
==8968== by 0x40A7D6: write_tree_block (disk-io.c:241)
==8968== by 0x40ACEE: __commit_transaction (disk-io.c:354)
==8968== by 0x40AE9E: btrfs_commit_transaction (disk-io.c:385)
==8968== by 0x42CF66: make_image (mkfs.c:1061)
==8968== by 0x42DE63: main (mkfs.c:1410)
==8968== Uninitialised value was created by a stack allocation
==8968== at 0x42B5FB: add_inode_items (mkfs.c:493)
1. On-disk inode format has reserved (and thus, random at alloc time) fields:
btrfs_inode_item: __le64 reserved[4]
2. Sometimes extents are created on disk without writing data there.
(Or at least not all data is written there). Kernel code always had
it kzalloc'ed.
Zero them all.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
Found by valgrind:
==8968== Use of uninitialised value of size 8
==8968== at 0x41CE7D: crc32c_le (crc32c.c:98)
==8968== by 0x40A1D0: csum_tree_block_size (disk-io.c:82)
==8968== by 0x40A2D4: csum_tree_block (disk-io.c:105)
==8968== by 0x40A7D6: write_tree_block (disk-io.c:241)
==8968== by 0x40ACEE: __commit_transaction (disk-io.c:354)
==8968== by 0x40AE9E: btrfs_commit_transaction (disk-io.c:385)
==8968== by 0x42CF66: make_image (mkfs.c:1061)
==8968== by 0x42DE63: main (mkfs.c:1410)
==8968== Uninitialised value was created by a stack allocation
==8968== at 0x42B5FB: add_inode_items (mkfs.c:493)
readlink(2) does not write '\0' for us, so make it manually.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
==31873== Command: ./mkfs.btrfs -r /some/root/
==31873== Parent PID: 31872
==31873==
==31873== Conditional jump or move depends on uninitialised value(s)
==31873== at 0x42C3D0: add_file_items (mkfs.c:792)
==31873== by 0x42CAB3: traverse_directory (mkfs.c:948)
==31873== by 0x42CF11: make_image (mkfs.c:1047)
==31873== by 0x42DE53: main (mkfs.c:1401)
==31873== Uninitialised value was created by a stack allocation
==31873== at 0x41B1B1: btrfs_csum_file_block (file-item.c:195)
'ret' value was not initialized for 'found' branch.
The same fix sits in kernel:
> commit 639cb58675ce9b507eed9c3d6b3335488079b21a
> Author: Chris Mason <chris.mason@oracle.com>
> Date: Thu Aug 28 06:15:25 2008 -0400
>
> Btrfs: Fix variable init during csum creation
>
> Signed-off-by: Chris Mason <chris.mason@oracle.com>
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
mkfs.btrfs does not handle relative pathnames for now. When
they are passed to it it creates empty image. So first time
I thought it does not work at all.
This patch adds error handling for scandir(). With patch it behaves
this way:
$ mkfs.btrfs -r ./root
...
fs created label (null) on output.img
nodesize 4096 leafsize 4096 sectorsize 4096 size 256.00MB
Btrfs v0.19-52-g438c5ff-dirty
scandir for ./root failed: No such file or directory
unable to traverse_directory
Making image is aborted.
mkfs.btrfs: mkfs.c:1402: main: Assertion `!(ret)' failed.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
This simple patch makes "btrfs filesystem label" command actually work.
On tmp branch, commit d1dc6a9, "btrfs filesystem label" functionality
was introduced. However the commit lacks one component that lets
"btrfs" accept "filesystem label" command.
Test case:
/dev/loop0
WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using
fs created label old on /dev/loop0
nodesize 4096 leafsize 4096 sectorsize 4096 size 1.00GB
Btrfs Btrfs v0.19
old
new
FATAL: the filesystem has to be unmounted
new
Not sure if you need if you need a signoff for something as trivial as
this, but here it is just in case.
Signed-off-by: Fajar A. Nugraha <list@fajar.net>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
When creating a mixed fs with mkfs, an extra metadata chunk got allocated.
This is because btrfs_reserve_extent calls do_chunk_alloc for METADATA,
which in turn wasn't able to find the proper space_info, as __find_space_info
did a hard compare of the flags. It is now sufficient for the space_info to
include the proper flag. This reflects the change done to the kernel code
to support mixed chunks.
Also for a subsequent chunk allocation (which should not be hit in the mkfs
case), the chunk is now created with the flags from the space_info instead
of the requested flags. A better solution would be to pull the full changeset
for the mixed case from the kernel into the user mode (or, even better, share
the code)
The additional chunk probably confused block_rsv calculation, which in turn
led to severeal ENOSPC Oopses.
Signed-off-by: Arne Jansen <sensille@gmx.net>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
gcc-4.4 complains (rightly) that the strncpy has a limit too large for
the array it's copying into. Use the correct array length.
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
Now 'btrfs subvolume snapshot' takes not two but only at least two
parameters. Additionally, the help message is updated accordingly.
Signed-off-by: Andreas Philipp <philipp.andreas@gmail.com>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
Use BTRFS_IOC_CREATE_SNAP_V2 instead of BTRFS_IOC_CREATE_SNAP and add
an option for the creation of a readonly snapshot.
Signed-off-by: Andreas Philipp <philipp.andreas@gmail.com>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
Added BTRFS_IOC_SNAP_CREATE_V2 and struct btrfs_ioctl_vol_args_v2 as
defined in fs/btrfs/ioctl.h in the kernel sources.
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>
gcc-4.6 (as shipped in Fedora) turns on -Wunused-but-set-variable by
default, which breaks the build when combined with -Wall, e.g.:
debug-tree.c: In function ‘print_extent_leaf’:
debug-tree.c:45:13: error: variable ‘last_len’ set but not used [-Werror=unused-but-set-variable]
debug-tree.c:44:13: error: variable ‘last’ set but not used [-Werror=unused-but-set-variable]
debug-tree.c:41:21: error: variable ‘item’ set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
This patch fixes the errors by removing the unused variables.
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
extend the
btrfs <cmd> --help
command to print detailed help message if available but fallback to
basic help message if detailed is unavailable
add detailed help message for 'filesystem defragment' command
little tweaks in comments
Signed-off-by: Hubert Kario <kario@wit.edu.pl>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
explain how to use
btrfs <cmd> --help
command in help message
Signed-off-by: Hubert Kario <kario@wit.edu.pl>
Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
