[PATCH] btrfs/ctree.c: remove the unnecessary 'return -1;' at the end of bin_search
The code path should not reach there. Remove it.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
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
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 sbehr...@giantdisaster.de
---
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
Each CRC or header error was counted twice, this is now fixed.
Signed-off-by: Stefan Behrens sbehr...@giantdisaster.de
---
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
Re: btrfs bugs on statfs on ro device
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
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 dave.kleik...@oracle.com
Cc: Zach Brown z...@zabbo.net
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 hirof...@mail.parknet.co.jp
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
[RFC PATCH v2 20/21] btrfs: add support for read_iter and write_iter
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 dave.kleik...@oracle.com
Cc: Zach Brown z...@zabbo.net
Cc: Chris Mason chris.ma...@oracle.com
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 =
Re: kernel BUG at fs/btrfs/volumes.c:2733
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 dev' 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 mnt') 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
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
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
On Fri, Mar 30, 2012 at 10:51 AM, Chris Mason chris.ma...@oracle.com 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
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 dev' 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 mnt'. 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
On Fri, Mar 30, 2012 at 12:50 PM, Linus Torvalds torva...@linux-foundation.org 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
On Fri, Mar 30, 2012 at 12:50:26PM -0700, Linus Torvalds wrote:
On Fri, Mar 30, 2012 at 10:51 AM, Chris Mason chris.ma...@oracle.com 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
On Fri, Mar 30, 2012 at 12:54:03PM -0700, Linus Torvalds wrote: On Fri, Mar 30, 2012 at 12:50 PM, Linus Torvalds torva...@linux-foundation.org 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
Chris Mason chris.mason at 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
On 30/03/2012, at 2:22 PM, Fajar A. Nugraha wrote: On Fri, Mar 30, 2012 at 5:08 AM, member graysky gray...@archlinux.us 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 http://www.oracle.com 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
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] [c000ff5b] (unwind_backtrace+0x1/0x8a) from [c00601f3] (warn_alloc_failed+0x9f/0xc4) [10013.881286] [c00601f3] (warn_alloc_failed+0x9f/0xc4) from [c0061ed7] (__alloc_pages_nodemask+0x3e3/0x410) [10013.883270] [c0061ed7] (__alloc_pages_nodemask+0x3e3/0x410) from [c007b57b] (cache_alloc_refill+0x1ab/0x364) [10013.893646] [c007b57b] (cache_alloc_refill+0x1ab/0x364) from [c007b78d] (__kmalloc+0x59/0x84) [10013.893646] [c007b78d] (__kmalloc+0x59/0x84) from [c02e0bcd] (__alloc_skb+0x37/0xb2) [10013.922058] [c02e0bcd] (__alloc_skb+0x37/0xb2) from [c02e1033] (__netdev_alloc_skb+0x15/0x2e) [10013.922058] [c02e1033] (__netdev_alloc_skb+0x15/0x2e) from [c0243839] (rx_submit+0x15/0x130) [10013.931365] [c0243839] (rx_submit+0x15/0x130) from [c0248187] (usb_hcd_giveback_urb+0x3f/0x74) [10013.931365] [c0248187] (usb_hcd_giveback_urb+0x3f/0x74) from [c0250739] (ehci_urb_done+0x5f/0x68) [10013.931365] [c0250739] (ehci_urb_done+0x5f/0x68) from [c0252497] (qh_completions+0x6f/0x2b8) [10013.968780] [c0252497] (qh_completions+0x6f/0x2b8) from [c0252ca5] (ehci_work+0x65/0x5d8) [10013.968780] [c0252ca5] (ehci_work+0x65/0x5d8) from [c0253635] (ehci_irq+0x171/0x198) [10013.986175] [c0253635] (ehci_irq+0x171/0x198) from [c0247c47] (usb_hcd_irq+0x1f/0x3a) [10013.986175] [c0247c47] (usb_hcd_irq+0x1f/0x3a) from [c0057165] (handle_irq_event_percpu+0x19/0xd4) [10013.986175] [c0057165] (handle_irq_event_percpu+0x19/0xd4) from [c0057249] (handle_irq_event+0x29/0x3c) [10013.986175] [c0057249] (handle_irq_event+0x29/0x3c) from [c0058c5d] (handle_fasteoi_irq+0x81/0xb4) [10013.986175] [c0058c5d] (handle_fasteoi_irq+0x81/0xb4) from [c0056dcf] (generic_handle_irq+0x13/0x1c) [10014.02] [c0056dcf] (generic_handle_irq+0x13/0x1c) from [c000cc97] (handle_IRQ+0x4b/0x7c) [10014.02] [c000cc97] (handle_IRQ+0x4b/0x7c) from [c00084b1] (gic_handle_irq+0x4d/0x68) [10014.052398] [c00084b1] (gic_handle_irq+0x4d/0x68) from [c000bfdb] (__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] [c000bfdb] (__irq_svc+0x3b/0x60) from [c042107a] (_raw_spin_unlock_irq+0x8/0xa) [10014.083526] [c042107a] (_raw_spin_unlock_irq+0x8/0xa) from [c007b297] (cache_reap+0x5b/0xb8) [10014.083526] [c007b297] (cache_reap+0x5b/0xb8) from [c002f827] (process_one_work+0x155/0x22e) [10014.083526] [c002f827] (process_one_work+0x155/0x22e) from [c002fc3b] (worker_thread+0x127/0x1e8) [10014.083526] [c002fc3b] (worker_thread+0x127/0x1e8) from [c0032059] (kthread+0x4d/0x60) [10014.133026] [c0032059] (kthread+0x4d/0x60) from [c000cd39] (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]
Re: btrfsck integration with userlevel API for fsck
On Sat, Mar 31, 2012 at 3:35 AM, Avi Miller avi.mil...@oracle.com wrote: On 30/03/2012, at 2:22 PM, Fajar A. Nugraha wrote: On Fri, Mar 30, 2012 at 5:08 AM, member graysky gray...@archlinux.us 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
