This is the btrfs-progs version of the patch to add the ability to have
different csum algorithims. Note I didn't change the image maker since it
seemed a bit more complicated than just changing some stuff around so I will let
Yan take care of that.
Everything else was converted and for now a mkfs just
sets the type to be BTRFS_CSUM_TYPE_CRC32.
Signed-off-by: Josef Bacik <jbacik@redhat.com>
This patch adds btrfs image tool. The image tool is
a debugging tool that creates/restores btrfs metadump
image.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
This changes the snapshot and subvol ioctl API and command lines so
that new snapshots and subvols can be created anywhere.
Subvolume creation hasn't changed much:
btrfsctl -S subvol_name directory
This creates a new subvolume under 'directory'
Snapshot creation looks the same, but is actually different:
btrfsctl -s full_path_to_new_snapshot file_or_dir
For example: btrfsctl -s /mnt/new_snap /mnt/subvol
Will create a new snapshot named new_snap under /mnt of the root
found in /mnt/subvol. It always snapshots the entire root regardless of
which file or directory inside the root you give it.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
This patch does the following:
1) Update device management code to match the kernel code.
2) Allocator fixes.
3) Add a program called btrfstune to set/clear the SEEDING
super block flags.
The root node generation number code made commit_tree_root look like the
kernel code. It forces a cow of the tree of tree roots even when
the FS hasn't changed.
This causes errors during fsck and other readonly operations. This adds
a check to see if commit_tree_root is going to trigger writes to the
tree of tree roots, and bails if none are pending.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
This patch adds transaction IDs to root tree pointers.
Transaction IDs in tree pointers are compared with the
generation numbers in block headers when reading root
blocks of trees. This can detect some types of IO errors.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
The offset field in struct btrfs_extent_ref records the position
inside file that file extent is referenced by. In the new back
reference system, tree leaves holding reference to file extent
are recorded explicitly. We can quickly scan these tree leaves, so the
offset field is not required.
This patch also makes the back reference system check the objectid
when extents are being deleted
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
The new space balancing code needs a subvol to store the
temporary inode for data extent relocation.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
This patch makes the back reference system to explicit record the
location of parent node for all types of extents. The location of
parent node is placed into the offset field of backref key. Every
time a tree block is balanced, the back references for the affected
lower level extents are updated.
btrfs-progs-0.16.tar.bz2 seems to be distributed w/o an .hg,
which make the version.sh script go bonk.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---
This patch corrects open-coded inode_map iteration, which happens to be
illegal in new libext2fs due to inode_map being private, causing warning,
which becomes a compile error.
Many options were not mentioned in the usage message, fix that and
cleaning up the brackets
Signed-Off-By: Ahmed Kamal <email.ahmedkamal@googlemail.com>
btrfsctl -c forces a single FS sync
The transaction ioctls are unsafe for general use because they can lead
to deadlocks if the application is not very careful. But, ceph is
experimenting with btrfs as a backing store, and these ioctls are required
for testing.
Gcc only sends warnings for uninitialized variables when you compile with -O,
and there were a couple of bugs sprinkled in the code. The biggest was the
alloc_start variable for mkfs, which can cause strange things to happen.
(thanks to Gabor Micsko for helping to find this)
This patch add ext2_inode.i_size_high into account when calculating regular
file's size in btrfs-convert, which makes it deal with large files bigger than
4GB properly.
