[PATCH] btrfs/ctree.c: remove the unnecessary 'return -1;' at the end of bin_search

[Wang Sheng-Hui]

The code path should not reach there. Remove it.

Signed-off-by: Wang Sheng-Hui 
---
 fs/btrfs/ctree.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 0639a55..c1be2da 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -829,20 +829,18 @@ static noinline int generic_bin_search(struct 
extent_buffer *eb,
 static int bin_search(struct extent_buffer *eb, struct btrfs_key *key,
  int level, int *slot)
 {
-   if (level == 0) {
+   if (level == 0)
return generic_bin_search(eb,
  offsetof(struct btrfs_leaf, items),
  sizeof(struct btrfs_item),
  key, btrfs_header_nritems(eb),
  slot);
-   } else {
+   else
return generic_bin_search(eb,
  offsetof(struct btrfs_node, ptrs),
  sizeof(struct btrfs_key_ptr),
  key, btrfs_header_nritems(eb),
  slot);
-   }
-   return -1;
 }
 
 int btrfs_bin_search(struct extent_buffer *eb, struct btrfs_key *key,
-- 
1.7.1



--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Btrfs: fix that check_int_data mount option was ignored

[Stefan Behrens]

The bitfield member mount_opt was too small by one bit to hold the mount
option that enabled to include data extents in the integrity checker.
Since the same issue happened when the BTRFS_MOUNT_PANIC_ON_FATAL_ERROR
option was added (git rebase silently merges so that the increase of the
size of the bitfield member is lost), the bit limit was removed entirely.

Signed-off-by: Stefan Behrens 
---
The patch is based on cmason/integration as of 3/30/2012.

 fs/btrfs/ctree.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 5b8ef8e..ec42a24 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -1078,7 +1078,7 @@ struct btrfs_fs_info {
 * is required instead of the faster short fsync log commits
 */
u64 last_trans_log_full_commit;
-   unsigned long mount_opt:21;
+   unsigned long mount_opt;
unsigned long compress_type:4;
u64 max_inline;
u64 alloc_start;
-- 
1.7.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Btrfs: don't count CRC or header errors twice while scrubbing

[Stefan Behrens]

Each CRC or header error was counted twice, this is now fixed.

Signed-off-by: Stefan Behrens 
---
The patch is based on cmason/integration as of 3/30/2012.

 fs/btrfs/scrub.c |   15 ---
 1 files changed, 0 insertions(+), 15 deletions(-)

diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index c9a2c1a..196d48f 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -1254,12 +1254,6 @@ static int scrub_checksum_data(struct scrub_block 
*sblock)
if (memcmp(csum, on_disk_csum, sdev->csum_size))
fail = 1;
 
-   if (fail) {
-   spin_lock(&sdev->stat_lock);
-   ++sdev->stat.csum_errors;
-   spin_unlock(&sdev->stat_lock);
-   }
-
return fail;
 }
 
@@ -1332,15 +1326,6 @@ static int scrub_checksum_tree_block(struct scrub_block 
*sblock)
if (memcmp(calculated_csum, on_disk_csum, sdev->csum_size))
++crc_fail;
 
-   if (crc_fail || fail) {
-   spin_lock(&sdev->stat_lock);
-   if (crc_fail)
-   ++sdev->stat.csum_errors;
-   if (fail)
-   ++sdev->stat.verify_errors;
-   spin_unlock(&sdev->stat_lock);
-   }
-
return fail || crc_fail;
 }
 
-- 
1.7.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Btrfs: change integrity checker to support big blocks

[Stefan Behrens]

The integrity checker used to be coded for nodesize == leafsize ==
sectorsize == PAGE_CACHE_SIZE.
This is now changed to support sizes for nodesize and leafsize which are
N * PAGE_CACHE_SIZE.

Signed-off-by: Stefan Behrens 
---
The patch is based on cmason/integration as of 3/30/2012.

 fs/btrfs/check-integrity.c |  561 
 1 files changed, 415 insertions(+), 146 deletions(-)

diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c
index d986824..013fb04 100644
--- a/fs/btrfs/check-integrity.c
+++ b/fs/btrfs/check-integrity.c
@@ -104,8 +104,6 @@
 #define BTRFSIC_BLOCK_STACK_FRAME_MAGIC_NUMBER 20111300
 #define BTRFSIC_TREE_DUMP_MAX_INDENT_LEVEL (200 - 6)   /* in characters,
 * excluding " [...]" */
-#define BTRFSIC_BLOCK_SIZE PAGE_SIZE
-
 #define BTRFSIC_GENERATION_UNKNOWN ((u64)-1)
 
 /*
@@ -211,8 +209,9 @@ struct btrfsic_block_data_ctx {
u64 dev_bytenr; /* physical bytenr on device */
u32 len;
struct btrfsic_dev_state *dev;
-   char *data;
-   struct buffer_head *bh; /* do not use if set to NULL */
+   char **datav;
+   struct page **pagev;
+   void *mem_to_free;
 };
 
 /* This structure is used to implement recursion without occupying
@@ -244,6 +243,8 @@ struct btrfsic_state {
struct btrfs_root *root;
u64 max_superblock_generation;
struct btrfsic_block *latest_superblock;
+   u32 metablock_size;
+   u32 datablock_size;
 };
 
 static void btrfsic_block_init(struct btrfsic_block *b);
@@ -291,8 +292,10 @@ static int btrfsic_process_superblock(struct btrfsic_state 
*state,
 static int btrfsic_process_metablock(struct btrfsic_state *state,
 struct btrfsic_block *block,
 struct btrfsic_block_data_ctx *block_ctx,
-struct btrfs_header *hdr,
 int limit_nesting, int force_iodone_flag);
+static void btrfsic_read_from_block_data(
+   struct btrfsic_block_data_ctx *block_ctx,
+   void *dst, u32 offset, size_t len);
 static int btrfsic_create_link_to_next_block(
struct btrfsic_state *state,
struct btrfsic_block *block,
@@ -319,12 +322,13 @@ static void btrfsic_release_block_ctx(struct 
btrfsic_block_data_ctx *block_ctx);
 static int btrfsic_read_block(struct btrfsic_state *state,
  struct btrfsic_block_data_ctx *block_ctx);
 static void btrfsic_dump_database(struct btrfsic_state *state);
+static void btrfsic_complete_bio_end_io(struct bio *bio, int err);
 static int btrfsic_test_for_metadata(struct btrfsic_state *state,
-const u8 *data, unsigned int size);
+char **datav, unsigned int num_pages);
 static void btrfsic_process_written_block(struct btrfsic_dev_state *dev_state,
- u64 dev_bytenr, u8 *mapped_data,
- unsigned int len, struct bio *bio,
- int *bio_is_patched,
+ u64 dev_bytenr, char **mapped_datav,
+ unsigned int num_pages,
+ struct bio *bio, int *bio_is_patched,
  struct buffer_head *bh,
  int submit_bio_bh_rw);
 static int btrfsic_process_written_superblock(
@@ -376,7 +380,7 @@ static struct btrfsic_dev_state *btrfsic_dev_state_lookup(
 static void btrfsic_cmp_log_and_dev_bytenr(struct btrfsic_state *state,
   u64 bytenr,
   struct btrfsic_dev_state *dev_state,
-  u64 dev_bytenr, char *data);
+  u64 dev_bytenr);
 
 static struct mutex btrfsic_mutex;
 static int btrfsic_is_initialized;
@@ -652,7 +656,7 @@ static int btrfsic_process_superblock(struct btrfsic_state 
*state,
int pass;
 
BUG_ON(NULL == state);
-   selected_super = kmalloc(sizeof(*selected_super), GFP_NOFS);
+   selected_super = kzalloc(sizeof(*selected_super), GFP_NOFS);
if (NULL == selected_super) {
printk(KERN_INFO "btrfsic: error, kmalloc failed!\n");
return -1;
@@ -719,7 +723,7 @@ static int btrfsic_process_superblock(struct btrfsic_state 
*state,
 
num_copies =
btrfs_num_copies(&state->root->fs_info->mapping_tree,
-next_bytenr, PAGE_SIZE);
+next_bytenr, state->metablock_size);
if (state->print_mask & BTRFSIC_PRINT_MASK_NUM_COPIES)
printk(KERN_INFO "num_copies(log_bytenr=%llu) = %d\n",

btrfs bugs on statfs on ro device

[Jan Engelhardt]

Attempting to run `df` on a read-only btrfs crashes the kernel:

  # losetup -r -o $[313344*512] /dev/loop4 wholedisk.img
  # mount -o ro /dev/loop4 /mnt

device fsid 4ba1fa38-d62b-4940-9825-7e6cceb7fcc8 devid 1 transid 4333 /dev/loop4

  # df

kernel BUG at [openSUSE 12.1 Rescue CD kernel] 
/home/abuild/rpmbuild/BUILD/kernel-default-3.1.0/linux-3.1/fs/btrfs/super.c:984!
 968:   static int btrfs_calc_avail_data_space(struct btrfs_root *root, u64 
*free_bytes)
 969:   {
 ...
 983:   nr_devices = fs_info->fs_devices->rw_devices;
>984:   BUG_ON(!nr_devices);


invalid opcode:  [#1] SMP 
CPU 0 
Modules linked in: btrfs zlib_deflate nls_utf8 usb_storage arc4 ecb mperf fan 
thermal nfs nfs_acl lockd fscache auth_rpcgss sunrpc nls_iso8859_1 nls_cp437 
af_packet usbhid st ohci_hcd sg sr_mod parport_pc parport ac cdrom ssb mptsas 
processor ehci_hcd mptscsih mmc_core button e1000 thermal_sys mptbase vboxguest 
usbcore pcmcia scsi_transport_sas pcmcia_core edd squashfs loop

Pid: 2333, comm: df Not tainted 3.1.0-1.2-default #1 innotek GmbH VirtualBox
RIP: 0010:[]  [] 
btrfs_calc_avail_data_space+0x278/0x280 [btrfs]
RSP: 0018:880013b7fd98  EFLAGS: 00010246
RAX: 8800139ac000 RBX: 880013b7ff00 RCX: 000c
RDX: 9123683e RSI: 880013b7fe38 RDI: 
RBP: 880013b24800 R08: 0003 R09: 88000a536e78
R10: 0003 R11: 8800034e8001 R12: 880013b16480
R13: 880013b24800 R14: 0004e340 R15: 000c
FS:  7f0640f99700() GS:88001560() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f0640a3c75a CR3: 0448d000 CR4: 06f0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process df (pid: 2333, threadinfo 880013b7e000, task 88001396e1c0)
Stack:
 0001 0292  81158c1c
 8800139ac000 880013b7fe38 880013b7fed8 a03184f1
 0001 880013b7ff00 8800139ac000 880005bb1a40
Call Trace:
 [] btrfs_statfs+0x129/0x1d0 [btrfs]
 [] statfs_by_dentry+0x98/0x140
 [] vfs_statfs+0x21/0x60
 [] user_statfs+0x30/0x50
 [] sys_statfs+0x12/0x30
 [] system_call_fastpath+0x16/0x1b
 [<7f0640abbd07>] 0x7f0640abbd06
Code: c4 48 5b 5d 41 5c 41 5d 41 5e 41 5f c3 45 31 c0 48 c7 c1 40 e0 2f a0 ba 
20 00 00 00 31 f6 48 89 df 45 31 ed e8 fa c1 fa e0 eb 81 <0f> 0b 66 0f 1f 44 00 
00 41 57 41 56 45 31 f6 41 55 41 54 49 89 
RIP  [] btrfs_calc_avail_data_space+0x278/0x280 [btrfs]
 RSP 
---[ end trace 0f0a04393e646822 ]---

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs bugs on statfs on ro device

[Jan Engelhardt]

On Friday 2012-03-30 17:13, Jan Engelhardt wrote:

>Attempting to run `df` on a read-only btrfs crashes the kernel:
>  # losetup -r -o $[313344*512] /dev/loop4 wholedisk.img
>  # mount -o ro /dev/loop4 /mnt
>device fsid 4ba1fa38-d62b-4940-9825-7e6cceb7fcc8 devid 1 transid 4333 
>/dev/loop4
>  # df
>kernel BUG at [openSUSE 12.1 Rescue CD kernel] 
>/home/abuild/rpmbuild/BUILD/kernel-default-3.1.0/linux-3.1/fs/btrfs/super.c:984!
> 983:   nr_devices = fs_info->fs_devices->rw_devices;
>>984:   BUG_ON(!nr_devices);

Turns out this was addressed in later stable kernels of theirs (which 
rescue cds unfortunately seldom get).
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH v2 09/21] dio: Convert direct_IO to use iov_iter

[Dave Kleikamp]

Change the direct_IO aop to take an iov_iter argument rather than an iovec.
This will get passed down through most filesystems so that only the
__blockdev_direct_IO helper need be aware of whether user or kernel memory
is being passed to the function.

Signed-off-by: Dave Kleikamp 
Cc: Zach Brown 
Cc: v9fs-develo...@lists.sourceforge.net
Cc: linux-btrfs@vger.kernel.org
Cc: ceph-de...@vger.kernel.org
Cc: linux-e...@vger.kernel.org
Cc: OGAWA Hirofumi 
Cc: jfs-discuss...@lists.sourceforge.net
Cc: linux-...@vger.kernel.org
Cc: linux-ni...@vger.kernel.org
Cc: ocfs2-de...@oss.oracle.com
Cc: reiserfs-de...@vger.kernel.org
Cc: x...@oss.sgi.com
---
 Documentation/filesystems/Locking |4 +--
 Documentation/filesystems/vfs.txt |4 +--
 fs/9p/vfs_addr.c  |8 ++---
 fs/block_dev.c|8 ++---
 fs/btrfs/inode.c  |   70 ++---
 fs/ceph/addr.c|3 +-
 fs/direct-io.c|   19 +-
 fs/ext2/inode.c   |8 ++---
 fs/ext3/inode.c   |   15 
 fs/ext4/ext4.h|3 +-
 fs/ext4/indirect.c|   16 -
 fs/ext4/inode.c   |   23 ++--
 fs/fat/inode.c|   10 +++---
 fs/gfs2/aops.c|7 ++--
 fs/hfs/inode.c|7 ++--
 fs/hfsplus/inode.c|6 ++--
 fs/jfs/inode.c|7 ++--
 fs/nfs/direct.c   |8 ++---
 fs/nilfs2/inode.c |8 ++---
 fs/ocfs2/aops.c   |8 ++---
 fs/reiserfs/inode.c   |7 ++--
 fs/xfs/xfs_aops.c |   11 +++---
 include/linux/fs.h|   18 +-
 include/linux/nfs_fs.h|3 +-
 mm/filemap.c  |   13 +--
 25 files changed, 144 insertions(+), 150 deletions(-)

diff --git a/Documentation/filesystems/Locking 
b/Documentation/filesystems/Locking
index 4fca82e..1e725f7 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -194,8 +194,8 @@ prototypes:
int (*invalidatepage) (struct page *, unsigned long);
int (*releasepage) (struct page *, int);
void (*freepage)(struct page *);
-   int (*direct_IO)(int, struct kiocb *, const struct iovec *iov,
-   loff_t offset, unsigned long nr_segs);
+   int (*direct_IO)(int, struct kiocb *, struct iov_iter *iter,
+   loff_t offset);
int (*get_xip_mem)(struct address_space *, pgoff_t, int, void **,
unsigned long *);
int (*migratepage)(struct address_space *, struct page *, struct page 
*);
diff --git a/Documentation/filesystems/vfs.txt 
b/Documentation/filesystems/vfs.txt
index 3d9393b..0029302 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -573,8 +573,8 @@ struct address_space_operations {
int (*invalidatepage) (struct page *, unsigned long);
int (*releasepage) (struct page *, int);
void (*freepage)(struct page *);
-   ssize_t (*direct_IO)(int, struct kiocb *, const struct iovec *iov,
-   loff_t offset, unsigned long nr_segs);
+   ssize_t (*direct_IO)(int, struct kiocb *, struct iov_iter *iter,
+   loff_t offset);
struct page* (*get_xip_page)(struct address_space *, sector_t,
int);
/* migrate the contents of a page to the specified target */
diff --git a/fs/9p/vfs_addr.c b/fs/9p/vfs_addr.c
index 0ad61c6..e70f239 100644
--- a/fs/9p/vfs_addr.c
+++ b/fs/9p/vfs_addr.c
@@ -239,9 +239,8 @@ static int v9fs_launder_page(struct page *page)
  * v9fs_direct_IO - 9P address space operation for direct I/O
  * @rw: direction (read or write)
  * @iocb: target I/O control block
- * @iov: array of vectors that define I/O buffer
+ * @iter: array of vectors that define I/O buffer
  * @pos: offset in file to begin the operation
- * @nr_segs: size of iovec array
  *
  * The presence of v9fs_direct_IO() in the address space ops vector
  * allowes open() O_DIRECT flags which would have failed otherwise.
@@ -255,8 +254,7 @@ static int v9fs_launder_page(struct page *page)
  *
  */
 static ssize_t
-v9fs_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov,
-  loff_t pos, unsigned long nr_segs)
+v9fs_direct_IO(int rw, struct kiocb *iocb, struct iov_iter *iter, loff_t pos)
 {
/*
 * FIXME
@@ -265,7 +263,7 @@ v9fs_direct_IO(int rw, struct kiocb *iocb, const struct 
iovec *iov,
 */
p9_debug(P9_DEBUG_VFS, "v9fs_direct_IO: v9fs_direct_IO (%s) 
off/no(%lld/%lu) EINVAL\n",
 iocb->ki_filp->f_path.dentry->d_name.name,
-(long long)pos, nr_segs);
+(long long)pos, iter->nr_segs);
 
return -EINVAL;
 }
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 

[RFC PATCH v2 20/21] btrfs: add support for read_iter and write_iter

[Dave Kleikamp]

btrfs can use generic_file_read_iter(). Base btrfs_file_write_iter()
on btrfs_file_aio_write(), then have the latter call the former.

Signed-off-by: Dave Kleikamp 
Cc: Zach Brown 
Cc: Chris Mason 
Cc: linux-btrfs@vger.kernel.org
---
 fs/btrfs/file.c |   55 ++-
 1 file changed, 30 insertions(+), 25 deletions(-)

diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index e8d06b6..31275d1 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1285,20 +1285,17 @@ static noinline ssize_t __btrfs_buffered_write(struct 
file *file,
 }
 
 static ssize_t __btrfs_direct_write(struct kiocb *iocb,
-   const struct iovec *iov,
-   unsigned long nr_segs, loff_t pos,
-   loff_t *ppos, size_t count, size_t ocount)
+   struct iov_iter *iter,
+   loff_t pos, loff_t *ppos, size_t count)
 {
struct file *file = iocb->ki_filp;
struct inode *inode = fdentry(file)->d_inode;
-   struct iov_iter i;
ssize_t written;
ssize_t written_buffered;
loff_t endbyte;
int err;
 
-   written = generic_file_direct_write(iocb, iov, &nr_segs, pos, ppos,
-   count, ocount);
+   written = generic_file_direct_write_iter(iocb, iter, pos, ppos, count);
 
/*
 * the generic O_DIRECT will update in-memory i_size after the
@@ -1317,8 +1314,7 @@ static ssize_t __btrfs_direct_write(struct kiocb *iocb,
 
pos += written;
count -= written;
-   iov_iter_init(&i, iov, nr_segs, count, written);
-   written_buffered = __btrfs_buffered_write(file, &i, pos);
+   written_buffered = __btrfs_buffered_write(file, iter, pos);
if (written_buffered < 0) {
err = written_buffered;
goto out;
@@ -1335,9 +1331,8 @@ out:
return written ? written : err;
 }
 
-static ssize_t btrfs_file_aio_write(struct kiocb *iocb,
-   const struct iovec *iov,
-   unsigned long nr_segs, loff_t pos)
+static ssize_t btrfs_file_write_iter(struct kiocb *iocb,
+struct iov_iter *iter, loff_t pos)
 {
struct file *file = iocb->ki_filp;
struct inode *inode = fdentry(file)->d_inode;
@@ -1346,18 +1341,13 @@ static ssize_t btrfs_file_aio_write(struct kiocb *iocb,
u64 start_pos;
ssize_t num_written = 0;
ssize_t err = 0;
-   size_t count, ocount;
+   size_t count;
 
vfs_check_frozen(inode->i_sb, SB_FREEZE_WRITE);
 
mutex_lock(&inode->i_mutex);
 
-   err = generic_segment_checks(iov, &nr_segs, &ocount, VERIFY_READ);
-   if (err) {
-   mutex_unlock(&inode->i_mutex);
-   goto out;
-   }
-   count = ocount;
+   count = iov_iter_count(iter);
 
current->backing_dev_info = inode->i_mapping->backing_dev_info;
err = generic_write_checks(file, &pos, &count, S_ISBLK(inode->i_mode));
@@ -1406,14 +1396,10 @@ static ssize_t btrfs_file_aio_write(struct kiocb *iocb,
}
 
if (unlikely(file->f_flags & O_DIRECT)) {
-   num_written = __btrfs_direct_write(iocb, iov, nr_segs,
-  pos, ppos, count, ocount);
+   num_written = __btrfs_direct_write(iocb, iter, pos, ppos,
+  count);
} else {
-   struct iov_iter i;
-
-   iov_iter_init(&i, iov, nr_segs, count, num_written);
-
-   num_written = __btrfs_buffered_write(file, &i, pos);
+   num_written = __btrfs_buffered_write(file, iter, pos);
if (num_written > 0)
*ppos = pos + num_written;
}
@@ -1443,6 +1429,23 @@ out:
return num_written ? num_written : err;
 }
 
+static ssize_t btrfs_file_aio_write(struct kiocb *iocb,
+   const struct iovec *iov,
+   unsigned long nr_segs, loff_t pos)
+{
+   struct iov_iter i;
+   int ret;
+   size_t count;
+
+   ret = generic_segment_checks(iov, &nr_segs, &count, VERIFY_WRITE);
+   if (ret)
+   return ret;
+
+   iov_iter_init(&i, iov, nr_segs, count, 0);
+
+   return btrfs_file_write_iter(iocb, &i, pos);
+}
+
 int btrfs_release_file(struct inode *inode, struct file *filp)
 {
/*
@@ -1874,7 +1877,9 @@ const struct file_operations btrfs_file_operations = {
.write  = do_sync_write,
.aio_read   = generic_file_aio_read,
.splice_read= generic_file_splice_read,
+   .read_iter  = generic_file_read_iter,
.aio_write  = btrfs_file_aio_write,
+   .write_iter = btrfs_file_write_iter,
.mmap   = btrfs_file_mmap,
.open

Re: kernel BUG at fs/btrfs/volumes.c:2733

[Sander]

Hello Ilya,

Ilya Dryomov wrote (ao):
> > > I'm definitely intrested in reproducing it. Could you please umount this
> > > filesystem, capture the output of 'btrfs-debug-tree -d ' and post it
> > > somewhere ?
> > 
> > Will do. It is the / filesystem, so I'll need to reboot.
> 
> I need this to confirm that balance item is on disk.

I'm sorry it took so long. I'll mail the output to you directly.

> > > After that mount it back and see if there is "btrfs: continuing
> > > balance" line in dmesg (and if btrfs-balance kthread shows up)?

There is no such line in dmesg, and currently no btrfs-balance kthread
is running. I've pulled Chris Masons for-linus and booted with the
resulting kernel.

> > > If so, just let it run, it should finish the balance and remove
> > > on-disk item. (You can query the status of running balance with 'btrfs
> > > balance status ')
> > 
> > Do I need newer tools for that? This is Debian Sid (unstable):
> 
> Yeah, you do. That command is in master now, but it's not really
> needed. If btrfs-balance shows up, just wait for it to finish, it
> should get rid of the balance item. If it doesn't show up but the item
> is there we will have to dig deeper.

Ok :-)

Sander

-- 
Humilis IT Services and Solutions
http://www.humilis.net
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] Btrfs fixes and features

[Chris Mason]

Hi everyone,

This pull request is pretty big, picking up patches that have been under
development for some time.  I have it in two branches:

# against 3.3
#
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus

# merged with linus git as of this morning (conflict in fs/btrfs/scrub.c)
#
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git 
for-linus-merged

The conflict resolution was to pick my version of scrub.c and then go in
and drop all the KM_ args from kmap/unmap_atomic.

We've merged in the error handling patches from SuSE.  These are already
shipping in the sles kernel, and they give btrfs the ability to abort
transactions and go readonly on errors.  It involves a lot of churn as
they clarify BUG_ONs, and remove the ones we now properly deal with.

Josef reworked the way our metadata interacts with the page cache.
page->private now points to the btrfs extent_buffer object, which makes
everything faster.  He changed it so we write an whole extent buffer at
a time instead of allowing individual pages to go down,, which will be
important for the raid5/6 code (for the 3.5 merge window ;)

Josef also made us more aggressive about dropping pages for metadata
blocks that were freed due to COW.  Overall, our metadata caching is
much faster now.

We've integrated my patch for metadata bigger than the page size.  This
allows metadata blocks up to 64KB in size.  In practice 16K and 32K seem
to work best.  For workloads with lots of metadata, this cuts down the
size of the extent allocation tree dramatically and fragments much less.

Scrub was updated to support the larger block sizes, which ended up
being a fairly large change (thanks Stefan Behrens).

We also have an assortment of fixes and updates, especially to the
balancing code (Ilya Dryomov), the back ref walker (Jan Schmidt) and the
defragging code (Liu Bo).

Jeff Mahoney (21) commits (+1982/-1051):
btrfs: clean_tree_block should panic on observed memory corruption and 
return void (+12/-7)
btrfs: avoid NULL deref in btrfs_reserve_extent with DEBUG_ENOSPC (+2/-1)
btrfs: Catch locking failures in {set,clear,convert}_extent_bit (+38/-20)
btrfs: return void in functions without error conditions (+293/-410)
btrfs: replace many BUG_ONs with proper error handling (+980/-385)
btrfs: Remove set bits return from clear_extent_bit (+5/-7)
btrfs: enhance transaction abort infrastructure (+300/-56)
btrfs: Factor out tree->ops->merge_bio_hook call (+17/-5)
btrfs: Fix kfree of member instead of structure (+3/-3)
btrfs: btrfs_drop_snapshot should return int (+12/-8)
btrfs: ->submit_bio_hook error push-up (+31/-15)
btrfs: find_and_setup_root error push-up (+6/-5)
btrfs: __add_reloc_root error push-up (+16/-6)
btrfs: btrfs_update_root error push-up (+7/-4)
btrfs: Panic on bad rbtree operations (+39/-9)
btrfs: Simplify btrfs_submit_bio_hook (+4/-3)
btrfs: drop gfp_t from lock_extent (+63/-76)
btrfs: add varargs to btrfs_error (+66/-9)
btrfs: Simplify btrfs_insert_root (+3/-6)
btrfs: split extent_state ops (+25/-15)
btrfs: Add btrfs_panic() (+60/-1)

Ilya Dryomov (11) commits (+177/-159):
Btrfs: validate target profiles only if we are going to use them (+11/-16)
Btrfs: stop silently switching single chunks to raid0 on balance (+2/-3)
Btrfs: add wrappers for working with alloc profiles (+30/-30)
Btrfs: move alloc_profile_is_valid() to volumes.c (+25/-30)
Btrfs: make profile_is_valid() check more strict (+17/-12)
Btrfs: fix infinite loop in btrfs_shrink_device() (+2/-3)
Btrfs: improve the logic in btrfs_can_relocate() (+18/-6)
Btrfs: allow dup for data chunks in mixed mode (+9/-4)
Btrfs: add __get_block_group_index() helper (+12/-5)
Btrfs: add get_restripe_target() helper (+50/-44)
Btrfs: fix memory leak in resolver code (+1/-6)

Mark Fasheh (10) commits (+60/-19):
btrfs: Don't BUG_ON kzalloc error in btrfs_lookup_csums_range() (+13/-2)
btrfs: Don't BUG_ON insert errors in btrfs_alloc_dev_extent() (+3/-1)
btrfs: Go readonly on bad extent refs in update_ref_for_cow() (+5/-1)
btrfs: Don't BUG_ON errors from btrfs_create_subvol_root() (+6/-2)
btrfs: Don't BUG_ON errors from update_ref_for_cow() (+4/-1)
btrfs: Don't BUG_ON errors in __finish_chunk_alloc() (+6/-4)
btrfs: Don't BUG_ON() errors in update_ref_for_cow() (+7/-4)
btrfs: Go readonly on tree errors in balance_level (+11/-2)
btrfs: Remove BUG_ON from __finish_chunk_alloc() (+3/-1)
btrfs: Remove BUG_ON from __btrfs_alloc_chunk() (+2/-1)

Liu Bo (8) commits (+133/-52):
Btrfs: do not bother to defrag an extent if it is a big real extent (+3/-6)
Btrfs: add a check to decide if we should defrag the range (+35/-1)
Btrfs: show useful info in space reservation tracepoint (+13/-25)
Btrfs: fix recursive defragment with autodefrag option (+5/-3)
Btrfs: fix race between direct io and autodefrag (+5/-1)

Re: btrfs-convert processing time

[Olivier Bonvalet]

Le 22/02/2012 17:55, Olivier Bonvalet a écrit :

So, the btrfs-convert for the smaller drive is done... after near 5 days. Which 
stats can I give you ?

It's a 340GB LVM block device, and "btrfs filesystem df /backup/" say that :

Data: total=225.97GB, used=181.94GB
System: total=32.00MB, used=24.00KB
Metadata: total=111.00GB, used=91.56GB


If I mount the ext2_saved/image copy, I can see 257GB of data (78% of the block 
device used), with 17M of inodes.


The other btrfs-convert stay running.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html



Well, the second one is still running :

root! backup:~# uptime
 21:17:43 up 41 days, 19:59,  1 user,  load average: 2.06, 1.90, 1.88


root! backup:~# ps auxw | grep btrfs
root  1978 25.6 74.3 1269072 1141212 ? DFeb18 15421:50 
btrfs-convert /dev/vg-backup/backup


root! backup:~# iostat -k
Linux 2.6.42.3-dae-xen (backup) 30/03/2012  _x86_64_(2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
  10,540,062,36   54,210,09   32,74

Device:tpskB_read/skB_wrtn/skB_readkB_wrtn
xvda724,70   175,50  3181,13  634342597 11498370400
xvdy  0,00 0,00 0,00   1381  0
xvdz  0,00 0,00 0,00   4065  0
dm-0  0,49 3,22 1,78   116274976435028
dm-1837,57   171,69  3178,57  620593936 11489105416
dm-2  0,34 0,59 0,7821208002830584

11498370400 kB written, so, 11TB written to convert a 518GB partition ?


but more important : is it safe to abort the process ?

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes and features

[Linus Torvalds]

On Fri, Mar 30, 2012 at 10:51 AM, Chris Mason  wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus

This causes a new warning for me:

  fs/btrfs/extent_io.c: In function ‘repair_eb_io_failure’:
  fs/btrfs/extent_io.c:1940:6: warning: ‘ret’ may be used
uninitialized in this function

Hmm?

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG at fs/btrfs/volumes.c:2733

[Ilya Dryomov]

On Fri, Mar 30, 2012 at 07:49:56PM +0200, Sander wrote:
> Hello Ilya,
> 
> Ilya Dryomov wrote (ao):
> > > > I'm definitely intrested in reproducing it. Could you please umount this
> > > > filesystem, capture the output of 'btrfs-debug-tree -d ' and post 
> > > > it
> > > > somewhere ?
> > > 
> > > Will do. It is the / filesystem, so I'll need to reboot.
> > 
> > I need this to confirm that balance item is on disk.
> 
> I'm sorry it took so long. I'll mail the output to you directly.

Thanks.  btrfs-debug-tree confirms that you've got a balance item on
media.

> 
> > > > After that mount it back and see if there is "btrfs: continuing
> > > > balance" line in dmesg (and if btrfs-balance kthread shows up)?
> 
> There is no such line in dmesg, and currently no btrfs-balance kthread
> is running. I've pulled Chris Masons for-linus and booted with the
> resulting kernel.

And given the above it's weird.  We are failing to locate the item
during mount for some reason and I would like to find out why.  So if
you are up for running debugging patches (really just compiling btrfs
module and sending me dmesg output) I would appreciate that.

If you don't want to do that you can try to compile btrfs-progs from
git, mount fs and run 'btrfs balance resume '.  If that doesn't
work I'll send you a small util that will simply delete the item from
disk.

Thanks,

Ilya
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes and features

[Linus Torvalds]

On Fri, Mar 30, 2012 at 12:50 PM, Linus Torvalds
 wrote:
>
> This causes a new warning for me:
>
>  fs/btrfs/extent_io.c: In function ‘repair_eb_io_failure’:
>  fs/btrfs/extent_io.c:1940:6: warning: ‘ret’ may be used
> uninitialized in this function
>
> Hmm?

Ok, so presumably num_pages (which is "num_extent_pages(eb->start,
eb->len)") cannot be zero, so I guess the code is ok. But gcc can't
know that, and it's an annoying warning.

So please fix, but it's not urgent. In the meantime I've pulled and pushed out.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes and features

[Chris Mason]

On Fri, Mar 30, 2012 at 12:50:26PM -0700, Linus Torvalds wrote:
> On Fri, Mar 30, 2012 at 10:51 AM, Chris Mason  wrote:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git 
> > for-linus
> 
> This causes a new warning for me:
> 
>   fs/btrfs/extent_io.c: In function ‘repair_eb_io_failure’:
>   fs/btrfs/extent_io.c:1940:6: warning: ‘ret’ may be used
> uninitialized in this function

Interesting that my gcc doesn't warn here.  Strictly speaking, gcc isn't
wrong, but num_extent_pages() will always be at least 1.  This function
is new in this pull, so it can't be a conflict.

Do you want a new pull with the ret = 0 patch?

int repair_eb_io_failure(struct btrfs_root *root, struct extent_buffer
*eb,
 int mirror_num)
{
struct btrfs_mapping_tree *map_tree = &root->fs_info->mapping_tree;
u64 start = eb->start;
unsigned long i, num_pages = num_extent_pages(eb->start, eb->len);
int ret;

for (i = 0; i < num_pages; i++) {
struct page *p = extent_buffer_page(eb, i);
ret = repair_io_failure(map_tree, start, PAGE_CACHE_SIZE,
start, p, mirror_num);
if (ret)
break;
start += PAGE_CACHE_SIZE;
}

return ret;
}

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes and features

[Chris Mason]

On Fri, Mar 30, 2012 at 12:54:03PM -0700, Linus Torvalds wrote:
> On Fri, Mar 30, 2012 at 12:50 PM, Linus Torvalds
>  wrote:
> >
> > This causes a new warning for me:
> >
> >  fs/btrfs/extent_io.c: In function ‘repair_eb_io_failure’:
> >  fs/btrfs/extent_io.c:1940:6: warning: ‘ret’ may be used
> > uninitialized in this function
> >
> > Hmm?
> 
> Ok, so presumably num_pages (which is "num_extent_pages(eb->start,
> eb->len)") cannot be zero, so I guess the code is ok. But gcc can't
> know that, and it's an annoying warning.

Whoops, my reply was too slow, sorry.  If you're curious my gcc that
doesn't warn in 4.6.3.

> 
> So please fix, but it's not urgent. In the meantime I've pulled and pushed 
> out.

Ok, I'll send just the incremental in a later pull.

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes and features

[Alex]

Chris Mason  oracle.com> writes:

> 
> Hi everyone,
> 
> This pull request is pretty big, picking up patches that have been under
> development for some time.  I have it in two branches:
> 

Thank you all guys for your time, effort and responses here.
No problems here so far ;-)




--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfsck integration with userlevel API for fsck

[Avi Miller]

On 30/03/2012, at 2:22 PM, Fajar A. Nugraha wrote:

> On Fri, Mar 30, 2012 at 5:08 AM, member graysky  wrote:
>> Are there plans to integrate btrfsck with the userlevel API for fsck?
> 
> There isn't even a stable, working, fixing btrfsck yet :)

Yes, there is. Chris merged the btrfsck changes into the btrfs-progs master in 
git a few days ago and we shipped it with the Oracle Linux UEK2 update as well.

Cheers,
Avi

---
Oracle 
Avi Miller | Principal Program Manager | +61 (412) 229 687
Oracle Linux and Virtualization
417 St Kilda Road, Melbourne, Victoria 3004 Australia

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG at fs/btrfs/volumes.c:2733

[Sander]

Ilya Dryomov wrote (ao):
> On Fri, Mar 30, 2012 at 07:49:56PM +0200, Sander wrote:
> Thanks. btrfs-debug-tree confirms that you've got a balance item on
> media.

> > > > > After that mount it back and see if there is "btrfs: continuing
> > > > > balance" line in dmesg (and if btrfs-balance kthread shows up)?
> > 
> > There is no such line in dmesg, and currently no btrfs-balance kthread
> > is running. I've pulled Chris Masons for-linus and booted with the
> > resulting kernel.
> 
> And given the above it's weird. We are failing to locate the item
> during mount for some reason and I would like to find out why. So if
> you are up for running debugging patches (really just compiling btrfs
> module and sending me dmesg output) I would appreciate that.

Sure, please send me patches.

In the mean time, I got these (not related I guess, but it's the first
time it mentions btrfs, and I wonder where gzip is from):

[10013.866973] kworker/0:2: page allocation failure: order:3, mode:0x20
[10013.866973] [] (unwind_backtrace+0x1/0x8a) from [] 
(warn_alloc_failed+0x9f/0xc4)
[10013.881286] [] (warn_alloc_failed+0x9f/0xc4) from [] 
(__alloc_pages_nodemask+0x3e3/0x410)
[10013.883270] [] (__alloc_pages_nodemask+0x3e3/0x410) from 
[] (cache_alloc_refill+0x1ab/0x364)
[10013.893646] [] (cache_alloc_refill+0x1ab/0x364) from [] 
(__kmalloc+0x59/0x84)
[10013.893646] [] (__kmalloc+0x59/0x84) from [] 
(__alloc_skb+0x37/0xb2)
[10013.922058] [] (__alloc_skb+0x37/0xb2) from [] 
(__netdev_alloc_skb+0x15/0x2e)
[10013.922058] [] (__netdev_alloc_skb+0x15/0x2e) from [] 
(rx_submit+0x15/0x130)
[10013.931365] [] (rx_submit+0x15/0x130) from [] 
(usb_hcd_giveback_urb+0x3f/0x74)
[10013.931365] [] (usb_hcd_giveback_urb+0x3f/0x74) from [] 
(ehci_urb_done+0x5f/0x68)
[10013.931365] [] (ehci_urb_done+0x5f/0x68) from [] 
(qh_completions+0x6f/0x2b8)
[10013.968780] [] (qh_completions+0x6f/0x2b8) from [] 
(ehci_work+0x65/0x5d8)
[10013.968780] [] (ehci_work+0x65/0x5d8) from [] 
(ehci_irq+0x171/0x198)
[10013.986175] [] (ehci_irq+0x171/0x198) from [] 
(usb_hcd_irq+0x1f/0x3a)
[10013.986175] [] (usb_hcd_irq+0x1f/0x3a) from [] 
(handle_irq_event_percpu+0x19/0xd4)
[10013.986175] [] (handle_irq_event_percpu+0x19/0xd4) from 
[] (handle_irq_event+0x29/0x3c)
[10013.986175] [] (handle_irq_event+0x29/0x3c) from [] 
(handle_fasteoi_irq+0x81/0xb4)
[10013.986175] [] (handle_fasteoi_irq+0x81/0xb4) from [] 
(generic_handle_irq+0x13/0x1c)
[10014.02] [] (generic_handle_irq+0x13/0x1c) from [] 
(handle_IRQ+0x4b/0x7c)
[10014.02] [] (handle_IRQ+0x4b/0x7c) from [] 
(gic_handle_irq+0x4d/0x68)
[10014.052398] [] (gic_handle_irq+0x4d/0x68) from [] 
(__irq_svc+0x3b/0x60)
[10014.052398] Exception stack(0xedf73f00 to 0xedf73f48)
[10014.052398] 3f00: ef002a64 ef00a440  ee097b40 ef000140 ef002a40 
 c1a40d08
[10014.052398] 3f20:  c1a40d08 c1a404bc  0020 edf73f48 
c0421079 c042107a
[10014.052398] 3f40: 6033 
[10014.083526] [] (__irq_svc+0x3b/0x60) from [] 
(_raw_spin_unlock_irq+0x8/0xa)
[10014.083526] [] (_raw_spin_unlock_irq+0x8/0xa) from [] 
(cache_reap+0x5b/0xb8)
[10014.083526] [] (cache_reap+0x5b/0xb8) from [] 
(process_one_work+0x155/0x22e)
[10014.083526] [] (process_one_work+0x155/0x22e) from [] 
(worker_thread+0x127/0x1e8)
[10014.083526] [] (worker_thread+0x127/0x1e8) from [] 
(kthread+0x4d/0x60)
[10014.133026] [] (kthread+0x4d/0x60) from [] 
(kernel_thread_exit+0x1/0x6)
[10014.133026] Mem-info:
[10014.133026] Normal per-cpu:
[10014.133026] CPU0: hi:  186, btch:  31 usd: 156
[10014.133026] CPU1: hi:  186, btch:  31 usd: 168
[10014.152069] active_anon:19949 inactive_anon:506 isolated_anon:0
[10014.152069]  active_file:52991 inactive_file:52991 isolated_file:0
[10014.157104]  unevictable:469 dirty:2108 writeback:0 unstable:0
[10014.157104]  free:3283 slab_reclaimable:51064 slab_unreclaimable:5690
[10014.157104]  mapped:2477 shmem:522 pagetables:569 bounce:0
[10014.188293] Normal free:13132kB min:3512kB low:4388kB high:5268kB 
active_anon:79796kB inactive_anon:2024kB active_file:211964kB 
inactive_file:211964kB unevictable:1876kB isolated(anon):0kB isolated(file):0kB 
present:771136kB mlocked:0kB dirty:8432kB writeback:0kB mapped:9908kB 
shmem:2088kB slab_reclaimable:204256kB slab_unreclaimable:22760kB 
kernel_stack:1608kB pagetables:2276kB unstable:0kB bounce:0kB writeback_tmp:0kB 
pages_scanned:0 all_unreclaimable? no
[10014.188293] lowmem_reserve[]: 0 0
[10014.188293] Normal: 2383*4kB 278*8kB 34*16kB 26*32kB 0*64kB 0*128kB 0*256kB 
0*512kB 0*1024kB 0*2048kB 0*4096kB = 13132kB
[10014.188293] 107008 total pagecache pages
[10014.188293] 0 pages in swap cache
[10014.188293] Swap cache stats: add 0, delete 0, find 0/0
[10014.253112] Free swap  = 0kB
[10014.261566] Total swap = 0kB
[10014.261566] 194560 pages of RAM
[10014.311492] 5438 free pages
[10014.314422] 3772 reserved pages
[10014.314422] 56747 slab pages
[10014.320709] 125870 pages shared
[10014.320709] 0 pages swap cached
[10015.815917] gzip: page allocation fail

Re: btrfsck integration with userlevel API for fsck

[Fajar A. Nugraha]

On Sat, Mar 31, 2012 at 3:35 AM, Avi Miller  wrote:
>
> On 30/03/2012, at 2:22 PM, Fajar A. Nugraha wrote:
>
>> On Fri, Mar 30, 2012 at 5:08 AM, member graysky  wrote:
>>> Are there plans to integrate btrfsck with the userlevel API for fsck?
>>
>> There isn't even a stable, working, fixing btrfsck yet :)
>
> Yes, there is. Chris merged the btrfsck changes into the btrfs-progs master 
> in git a few days ago and we shipped it with the Oracle Linux UEK2 update as 
> well.

Ah, OK. I must've missed the announcement. Thanks for the update.

Now if only UEK2 fully supports LXC as well instead of tech preview ... :D

-- 
Fajar
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] btrfs/extent_io.c: cleanup the comment for clear_state_bit

[Wang Sheng-Hui]

No 'delete' arg is used for clear_state_bit anymore.
Cleanup the comment.

Signed-off-by: Wang Sheng-Hui 
---
 fs/btrfs/extent_io.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 2862454..b67814c 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -394,8 +394,7 @@ static int split_state(struct extent_io_tree *tree, struct 
extent_state *orig,
 
 /*
  * utility function to clear some bits in an extent state struct.
- * it will optionally wake up any one waiting on this state (wake == 1), or
- * forcibly remove the state from the tree (delete == 1).
+ * it will optionally wake up any one waiting on this state (wake == 1).
  *
  * If no bits are set on the state struct after clearing things, the
  * struct is freed and removed from the tree
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html