similar to: [PATCH] Btrfs: improve the BIO_RW_DISCARD conditional compile func definition

Hi everyone. I was trying to test a more recent version of btrfs on my current kernel (2.6.37) using dkms, without success. I followed these instructions: https://btrfs.wiki.kernel.org/index.php/Btrfs_source_repositories - cloned the repo - symlinked to /usr/src/btrfs-git - patched version.sh: Please note version.sh requires bash (better to change the shebang or fix the script). Even with the

Hi, Unfortunately, I did not succeed to compile a btrfs module via dkms from btrfs-unstable (commit 9aeead73782c4b8e2a91def36dbf95db28605c95) for kernel version 2.6.34-git16. For the exact error message, please see the make.log attached. If I replace the symlink to btrfs-unstable/fs/btrfs by a sumlink to the corresponding subdirectory of the kernel tree everything works well. Thanks, Andreas

We have been using bytes_reserved for metadata reservations, which is wrong since we use that to keep track of outstanding reservations from the allocator. This resulted in us doing a lot of silly things to make sure we don''t allocate a bunch of metadata chunks since we never had a real view of how much space was actually in use by metadata. There are a lot of fixes in here to make this

Hello, I noticed a double definition of BTRFS_CSUM_TYPE_CRC32 in ctree.h and attach a patch that removes it. Best regards, Dirk

We have been using bytes_reserved for metadata reservations, which is wrong since we use that to keep track of outstanding reservations from the allocator. This resulted in us doing a lot of silly things to make sure we don''t allocate a bunch of metadata chunks since we never had a real view of how much space was actually in use by metadata. There are a lot of fixes in here to make this

In order to improve the performance of fsync, we use the outstanding ordered extents to avoid looking up the checksum from the csum tree. But we didn''t filter out the ordered extents whose csum is still being calculated, when we got those ordered extents, we had to wait for the csum calculation. It made the performance dropped down suddenly. (On my box, it drop down from 56MB/s to

While testing with my buffer read fio jobs[1], I find that btrfs does not perform well enough. Here is a scenario in fio jobs: We have 4 threads, "t1 t2 t3 t4", starting to buffer read a same file, and all of them will race on add_to_page_cache_lru(), and if one thread successfully puts its page into the page cache, it takes the responsibility to read the page''s data. And

Op 2014-05-20 om 16:57 schreef syslinux-bot for H. Peter Anvin: > Commit-ID: 93f89ce6697adffcb3b40d758445ff9adf18b6d4 > Gitweb: http://www.syslinux.org/commit/93f89ce6697adffcb3b40d758445ff9adf18b6d4 That yields 'Bad commit reference: 93f89ce6697adffcb3b40d758445ff9adf18b6d4' What can I do to fix it? > Author: H. Peter Anvin <hpa at linux.intel.com> >

While testing with my buffer read fio jobs[1], I find that btrfs does not perform well enough. Here is a scenario in fio jobs: We have 4 threads, "t1 t2 t3 t4", starting to buffer read a same file, and all of them will race on add_to_page_cache_lru(), and if one thread successfully puts its page into the page cache, it takes the responsibility to read the page''s data. And

The original truncation of btrfs has a bug, that is the orphan item will not be dropped when the truncation fails. This bug will trigger BUG() when unlink that truncated file. And besides that, if the user does pre-allocation for the file which is truncated unsuccessfully, after re-mount(umount-mount, not -o remount), the pre-allocated extent will be dropped. This patch modified the relative

https://bugzilla.mindrot.org/show_bug.cgi?id=2721 Bug ID: 2721 Summary: Improve SFTP server to make remove always work on ZFS/Btrfs Product: Portable OpenSSH Version: 7.5p1 Hardware: Other OS: All Status: NEW Severity: normal Priority: P5 Component: sftp-server

If you export two subvolumes of a btrfs filesystem, they will both be given the same uuid so lookups will be confused. blkid cannot differentiate the two, so we must use the fsid from statfs64 to identify the filesystem. We cannot tell if blkid or statfs is best without knowing internal details of the filesystem in question, so we need to encode specific knowledge of btrfs in mountd. This is

Currently there are 3 different capitalisations of btrfs: used in printk()''s, BTRFS: (3 occurences), Btrfs: (1 occurence) and btrfs: (77 occurences). It''s best to have them all the same for consistency, so we canonicalise the two minority cases to btrfs:. Signed-off-by: Chris Samuel <chris@csamuel.org> --- fs/btrfs/disk-io.c | 4 ++-- fs/btrfs/inode.c | 4 ++-- 2

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 <mnt> Changelog v2 -> v3: - re-implement list_subvols() - re-implement this read-only subvolume list function based on the new list_subvols() Changelog v1 -> v2: -

When using "-U" option with btrfs-corrupt-block, it will cause a segfault due to a missing break in getopt switch. Reported-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com> Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com> --- btrfs-corrupt-block.c | 1 + 1 file changed, 1 insertion(+) diff --git a/btrfs-corrupt-block.c b/btrfs-corrupt-block.c index f0c14a9..a2828d4 100644

Hello, I have a question regarding "btrfs filesystem df"output. # btrfs fi df /mnt/test Data: total=3.01GB, used=512.19MB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 <= What this means? For what is used? I''ve never seen this incremented Metadata, DUP: total=2.50GB, used=676.00KB Metadata: total=8.00MB, used=0.00

There is a missing dependency: liblzo2-dev Without it, the make fails with: ~/tmp$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git ~/tmp$ cd btrfs-progs ~/tmp/btrfs-progs$ sudo apt-get install uuid-dev libattr1-dev zlib 1g-dev libacl1-dev e2fslibs-dev libblkid-dev ~/tmp/btrfs-progs$ make [CC] ctree.o [CC] disk-io.o [CC] radix-tree.o

As for skinny metadata, key.offset stores levels rather than extent length. Signed-off-by: Liu Bo <bo.li.liu@oracle.com> --- btrfs-image.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/btrfs-image.c b/btrfs-image.c index 739ae35..e5ff795 100644 --- a/btrfs-image.c +++ b/btrfs-image.c @@ -798,9 +798,9 @@ static int copy_from_extent_tree(struct metadump_struct

Hi, this is my first post and contribution to Btrfs. I wrote a documentation on how to debug Btrfs with GDB on UML(User Mode Linux). https://btrfs.wiki.kernel.org/index.php/Debugging_Btrfs_with_GDB This document might be little bit boring for Btrfs hackers, but for beginners who want to join Btrfs development, it is worth reading, I think. (BTW, I''m a beginner, too :D) Thank you. --

Remove unused variable in btrfs-image.c (update_super) and update man page documentation about -r option. Running btrfsck on a restored image produces missing chunk information. This is because by default, btrfs-image fixes up chunk tree to use 1 stripe pointing to the primary device. This in turns results in btrfsck making some noise. $ ./mkfs.btrfs /dev/sdb2 -f $ ./btrfs-image /dev/sdb2