similar to: [PATCH 3/4] update nodatacow code

I need everybody to go over this with a fine toothed comb since it is a pretty big change. I think it is right and it seems to come out right, but if it''s not it will mean we screw up O_DIRECT on snapshotted files with preallocated extents, so please, make sure it is correct :). --- Subject: [PATCH] Btrfs: rework can_nocow_odirect We are always doing the file extent lookup in here

Rewrite btrfs_drop_extents by using btrfs_duplicate_item, so we can avoid calling lock_extent within transaction. Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- fs/btrfs/ctree.h | 7 +- fs/btrfs/file.c | 659 ++++++++++++++++++++------------------------------- fs/btrfs/inode.c | 27 +-- fs/btrfs/ioctl.c | 3 +- fs/btrfs/tree-log.c | 4 +- 5 files changed, 277

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 we flush inodes with pending delalloc in a transaction, we may join the same transaction handler more than 2 times. The reason is: Task use_count of trans handle commit_transaction 1 |-> btrfs_start_delalloc_inodes 1 |-> run_delalloc_nocow 1 |-> join_transaction 2 |-> cow_file_range 2 |-> join_transaction 3 In fact, cow_file_range needn''t

This patch adds mixed back ref support for btrfs programs. The mixed back ref is a new disk format. back compatilibity is still not implemented. To try the new disk format, you need fresh formatted btrfs. Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- diff -urp btrfs-progs-unstable/crc32c.h btrfs-progs-2/crc32c.h --- btrfs-progs-unstable/crc32c.h 2008-09-30 16:50:58.898877720 +0800

This adds the flag to ctree.h, adds the feature option to mkfs to turn it on and fixes fsck so it doesn''t complain about missing hole extents in files when this flag is set. Signed-off-by: Josef Bacik <jbacik@fusionio.com> --- cmds-check.c | 14 ++++++++++++-- ctree.h | 5 +++-- mkfs.c | 2 ++ 3 files changed, 17 insertions(+), 4 deletions(-) diff --git

Btrfs has always had these filler extent data items for holes in inodes. This has made somethings very easy, like logging hole punches and sending hole punches. However for large holey files these extent data items are pure overhead. So add an incompatible feature to no longer add hole extents to reduce the amount of metadata used by these sort of files. This has a few changes for logging and

There were a whole bunch and I was doing it for other things. I haven''t tested these error paths but at the very least this is better than panicing. I''ve only left 2 BUG_ON()''s since they are logic errors and I want to replace them with a ASSERT framework that we can compile out for production users. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> ---

The rule originally comes from nocow writing, but snapshot-aware defrag is a different case, the extent has been writen and we''re not going to change the extent but add a reference on the data. So we''re able to allow such compressed extents to be merged into one bigger extent if they''re pointing to the same data. Signed-off-by: Liu Bo <bo.li.liu@oracle.com> ---

I''m going to be removing hole extents in the near future so I wanted to make a sanity test for btrfs_get_extent to make sure I don''t break anything in the meantime. This patch just puts btrfs_get_extent through its paces by giving it a completely unreasonable mapping to look at and make sure it is giving us back maps that make sense. Thanks, Signed-off-by: Josef Bacik

Balance will create reloc_root for each fs root, and it''s going to record last_snapshot to filter shared blocks. The side effect of setting last_snapshot is to break nocow attributes of files. So it turns out that checking last_snapshot does not always ensure that a node/leaf/file_extent is shared. That''s why shared node/leaf needs to search extent tree for number of

Just a quick update, I''ve dropped the hashing stuff in favor of doing a memcmp in the kernel to make sure the data is still the same. The thing that takes a while is reading the data up from disk, so doing a memcmp of the entire buffer isn''t that big of a deal, not to mention there''s a possiblity for malicious users if there is a problem with the hashing algorithms we

Exec btrfsck on btrfs with snapshots that are under a dropping progress will cause prompt on "ref mismatch". However we do not want this kind of prompt, since an remount operation will continue the dropping progress. Here the prompt is nonsense. Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com> --- cmds-check.c | 101

the tree log recover code expects no free space cached before it executes. Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- diff -urp 4/fs/btrfs/extent-tree.c 8/fs/btrfs/extent-tree.c --- 4/fs/btrfs/extent-tree.c 2010-05-11 14:15:29.174108554 +0800 +++ 8/fs/btrfs/extent-tree.c 2010-05-11 13:26:38.036107000 +0800 @@ -316,11 +329,6 @@ static int caching_kthread(void *data) if (!path)

Hi, Here''s an implementation of NFS support for btrfs. It does not work in one particular case as described in http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg00298.html. This uses the btrfs_iget helper introduced previously. Comments ? --- Signed-off-by: Balaji Rao <balajirrao@gmail.com> diff -r 3f0eee804974 Makefile --- a/Makefile Thu Jun 26 10:34:20 2008 -0400

As you know, revoking RSA/DSA keys in an SSH environment requires editing all authorized_keys and authorized_keys2 files that reference those public keys. This is, well, difficult at best but certainly very obnoxious, particularly in a large environment. SSH key management is difficult. This patch simplifies key management wherever GSS-API/Kerberos is used and is general enough to be used with

I noticed while running xfstests 83 that if we didn''t have enough space to delete our inode the orphan cleanup would just loop. This is because it keeps finding the same orphan item and keeps trying to kill it but can''t because we don''t get an error back from iput for deleting the inode. So keep track of the last guy we tried to kill, if it''s the same as the

This fixes up the progs to properly deal with skinny metadata. This adds the -x option to mkfs and btrfstune for enabling the skinny metadata option. This also makes changes to fsck so it can properly deal with the skinny metadata entries. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> --- V2->V3: update the mkfs.btrfs man page with the new option This is based on

The error code is returned instead of calling BUG_ON when btrfs_previous_item returns the error. Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com> --- fs/btrfs/volumes.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 8b9fb8c..c95b214 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -983,14 +983,14 @@

Here are 3 patches to avoid undesired aborts of mkfs.btrfs. These are based on top of Chris''s btrfs-progs.git: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git Thanks, H.Seto Hidetoshi Seto (3): btrfs-progs: error if device for mkfs is too small btrfs-progs: error if device have no space to make primary chunks btrfs-progs: calculate available