similar to: [PATCH] Btrfs: fix broken nocow after balance

Hello, This patch simplifies the nodatacow checker. If all references were created after the latest snapshot, then we can avoid COW safely. This patch also updates run_delalloc_nocow to do more fine-grained checking. Regards Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- diff -urp 3/fs/btrfs/ctree.h 4/fs/btrfs/ctree.h --- 3/fs/btrfs/ctree.h 2008-10-27 16:31:51.000000000 +0800 +++

From: Anand <anand.jain@oracle.com> This patch adds creation-time to the snapshot list display, which would help user to better manage the snapshots when number of snapshots grow substantially. This patch is developed and on top of the send/receive btrfs and btrfs-progs repo at git://github.com/ablock84/linux-btrfs.git (send-v2) git://github.com/ablock84/btrfs-progs.git (send-v2)

This fixes bugzilla 57491. If we take a snapshot of a fs with a unlink ongoing and then try to send that root we will run into problems. When comparing with a parent root we will search the parents and the send roots commit_root, which if we''ve just created the snapshot will include the file that needs to be evicted by the orphan cleanup. So when we find a changed extent we will try

From: Anand Jain <anand.jain@oracle.com> (This patch is for the review/test not yet for the integration). Here is an implementation of the feature to add label to the subvolume and snapshots. Which would help sysadmin to better manager the subvol and snapshots. This can be done in two ways, one - using attr which is user land only changes but drawback is able to change the label

Hi all - Here''s my current error handling patchset, against 3.1-rc8. Almost all of this patchset is preparing for actual error handling. Before we start in on that work, I''m trying to reduce the surface we need to worry about. It turns out that there is a ton of code that returns an error code but never actually reports an error. The patchset has grown to 65 patches. 46 of them

Document those places in the btrfs code which are BUGing on non-fatal error conditions that should be handled by proper error paths. This makes it easier to distinguish between what needs fixing versus which BUG_ON''s we might want to keep (to trap code bugs, unexpected inconsistencies, etc). Do this with a trivial macro, ''btrfs_fixable_bug_on'' which just defines to

If there''s an ongoing transaction when the uuid scan kthread attempts to create one, the kthread will block, waiting for that transaction to finish while it''s keeping locks on the tree root, and in turn the existing transaction is waiting for those locks to be free. The stack trace reported by the kernel follows. [36700.671601] INFO: task btrfs-uuid:15480 blocked for more than

Currently the fs sync function (super.c:btrfs_sync_fs()) doesn''t wait for delayed work to finish before returning success to the caller. This change fixes this, ensuring that there''s no data loss if a power failure happens right after fs sync returns success to the caller and before the next commit happens. Steps to reproduce the data loss issue: $ mkfs.btrfs -f /dev/sdb3 $

Hi all - The following 9 patches add more error handling to the btrfs code: - Add btrfs_panic - Catch locking failures in {set,clear}_extent_bit - Push up set_extent_bit errors to callers - Push up lock_extent errors to callers - Push up clear_extent_bit errors to callers - Push up unlock_extent errors to callers - Make pin_down_extent return void - Push up btrfs_pin_extent errors to

This patch changes some BUG_ON() to the error return. (but, most callers still use BUG_ON()) Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com> --- fs/btrfs/ctree.c | 3 ++- fs/btrfs/disk-io.c | 5 ++++- fs/btrfs/extent-tree.c | 25 ++++++++++++++++++------- fs/btrfs/file-item.c | 3 ++- fs/btrfs/inode-map.c | 3 ++- fs/btrfs/ioctl.c | 5 ++++-

I''ve been working to try to improve the write-ahead log''s performance, and I found that the bottleneck addresses in the checksum items, especially when we want to make a random write on a large file, e.g a 4G file. Then a idea for this suggested by Chris is to use sub transaction ids and just to log the part of inode that had changed since either the last log commit or the last

----- Forwarded Message ----- From: "Stefan Hajnoczi" <stefanha@redhat.com> To: "Eric Sandeen" <sandeen@redhat.com> Cc: virt-devel@redhat.com, "Kevin Wolf" <kwolf@redhat.com> Sent: Friday, November 22, 2013 9:20:51 AM Subject: [virt-devel] btrfs NOCOW for VM disk images Hi, In upstream QEMU we''re discussing patches that set the NOCOW flag

Add ''-C'' (nocow) option to vhd-util create. Btrfs has terrible performance when hosting VM images, even more when the guest in those VM are also using btrfs as file system. One way to mitigate this bad performance is to turn off COW attributes on VM files (since having copy on write for this kind of data is not useful). According to ''chattr'' manpage, NOCOW

Hello, some time ago we discussed on #btrfs that the nocow attribute for files wasn''t working (around 3.3 or 3.4 kernels). That was evident by files fragmenting even with the attribute set. Chris mentioned to find a fix quickly for that, and posted some lines of change into irc. But recently someone mentioned that 3.6-rc looks like still not respecting nocow for files. Is there really

Hello, is it possible to set nodatacow on a per-file basis? I couldn''t find anything. If not, wouldn''t that be a great feature to get around the performance issues with VM and database storage? Of course cloning should still cause COW. Thanks, Ralf-Peter -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to

Hi When GenericDirCtrl#re_create_tree is called in order to refresh the tree with any possible changes made to the file system since it was loaded, it doesn''t re-expand all the tree items that were expanded prior to calling re_create_tree. I''m working on a solution to note all open tree items and after re_create_tree manually expand the items that are still present in the tree.

This is a first draft of a subvolume quota implementation. It is possible to limit subvolumes and any group of subvolumes and also to track the amount of space that will get freed when deleting snapshots. The current version is functionally incomplete, with the main missing feature being the initial scan and rescan of an existing filesystem. I put some effort into writing an introduction into

First two patches are trivial cleanups that I''ve spotted while reading send.c, can be applied independently. The third patch contains the important bits, safety checks that the subvolumes involved in send do not accidentally lose the RO status. I haven''t seen this documented anywhere that this is mandatory, implied from how I assume send works. Please let me know if this is

When making btrfs filesystem. we firstly write root leaf to specified filed, and then we recow the root. If we don''t recow, some trees are not in the correct block group. Steps to reproduce: dd if=/dev/zero of=test.img bs=1M count=100 mkfs.btrfs -f test.img btrfs-debug-tree test.img extent tree key (EXTENT_TREE ROOT_ITEM 0) leaf 4210688 items 10 free space 3349 generation 4 owner 2

I want to eliminate the COW feature on all of my OS files. It is a nice feature for user files, but I don''t see a clear benefit for the actual OS files. And I suspect that COW induced fragmentation is causing or aggravating problems with my system including the boot open_ctree problem. I had planned to recursively chattr these files to "nodatacow" status but then I ran