Re: kernel BUG at fs/btrfs/extent-tree.c:8113! (4.1.3 kernel)
Marc MERLIN wrote on 2015/08/23 21:28 -0700: On Mon, Aug 24, 2015 at 09:10:30AM +0800, Qu Wenruo wrote: Would you please take the following output? 1) btrfs check output With error message if it happens. myth:~# btrfs check /dev/mapper/crypt_sdd1 Checking filesystem on /dev/mapper/crypt_sdd1 UUID: 024ba4d0-dacb-438d-9f1b-eeb34083fe49 checking extents cmds-check.c:4486: add_data_backref: Assertion `back->bytes != max_size` failed. btrfs[0x8066a73] btrfs[0x8066aa4] btrfs[0x8067991] btrfs[0x806b4ab] btrfs[0x806b9a3] btrfs[0x806c5b2] btrfs(cmd_check+0x1088)[0x806eddf] btrfs(main+0x153)[0x80557c6] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb753a4d3] btrfs[0x80557ec] 2) btrfs check --repair output Full output until segfault. myth:~# btrfs check --repair /dev/mapper/crypt_sdd1 enabling repair mode Checking filesystem on /dev/mapper/crypt_sdd1 UUID: 024ba4d0-dacb-438d-9f1b-eeb34083fe49 checking extents cmds-check.c:4486: add_data_backref: Assertion `back->bytes != max_size` failed. btrfs[0x8066a73] btrfs[0x8066aa4] btrfs[0x8067991] btrfs[0x806b4ab] btrfs[0x806b9a3] btrfs[0x806c5b2] btrfs(cmd_check+0x1088)[0x806eddf] btrfs(main+0x153)[0x80557c6] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb75114d3] btrfs[0x80557ec] Strangely I'm not getting a segfault anymore. It seems that the tree block's backref has something wrong. 3) btrfs-debug-tree output With assert output. The full output is multi gigabyte. Do you need this and if so, do I need to upload it somewhere and will you download the multi gigabyte file? The errors and assert, I already posted here: Sure thing: btrfs-debug-tree /dev/mapper/crypt_sdd1 > /tmp/tree.out parent transid verify failed on 2968115101696 wanted 34855 found 39533 parent transid verify failed on 2968115101696 wanted 34855 found 39533 parent transid verify failed on 2968115101696 wanted 34855 found 39533 parent transid verify failed on 2968115101696 wanted 34855 found 39533 Ignoring transid failure parent transid verify failed on 2968115134464 wanted 34855 found 39533 parent transid verify failed on 2968115134464 wanted 34855 found 39533 parent transid verify failed on 2968115134464 wanted 34855 found 39533 parent transid verify failed on 2968115134464 wanted 34855 found 39533 Ignoring transid failure parent transid verify failed on 2968115150848 wanted 34855 found 39533 parent transid verify failed on 2968115150848 wanted 34855 found 39533 parent transid verify failed on 2968115150848 wanted 34855 found 39533 parent transid verify failed on 2968115150848 wanted 34855 found 39533 Ignoring transid failure parent transid verify failed on 2968115691520 wanted 34855 found 39533 parent transid verify failed on 2968115691520 wanted 34855 found 39533 parent transid verify failed on 2968115691520 wanted 34855 found 39533 parent transid verify failed on 2968115691520 wanted 34855 found 39533 Ignoring transid failure parent transid verify failed on 1291597152256 wanted 35830 found 39530 parent transid verify failed on 1291597152256 wanted 35830 found 39530 parent transid verify failed on 1291597152256 wanted 35830 found 39530 parent transid verify failed on 1291597152256 wanted 35830 found 39530 Ignoring transid failure parent transid verify failed on 2968116592640 wanted 34855 found 39533 parent transid verify failed on 2968116592640 wanted 34855 found 39533 parent transid verify failed on 2968116592640 wanted 34855 found 39533 parent transid verify failed on 2968116592640 wanted 34855 found 39533 Ignoring transid failure parent transid verify failed on 2968116609024 wanted 34855 found 39533 parent transid verify failed on 2968116609024 wanted 34855 found 39533 parent transid verify failed on 2968116609024 wanted 34855 found 39533 parent transid verify failed on 2968116609024 wanted 34855 found 39533 Ignoring transid failure print-tree.c:1094: btrfs_print_tree: Assertion failed. btrfs-debug-tree[0x805ce93] btrfs-debug-tree(btrfs_print_tree+0x26d)[0x805eb51] btrfs-debug-tree(btrfs_print_tree+0x279)[0x805eb5d] btrfs-debug-tree(main+0x8b5)[0x804dfb7] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb757c4d3] btrfs-debug-tree[0x804e221] Oh, sorry for ignoring the existing output. And the last assert info should be enough. No need to upload it. The b-tree seems to be hugely damaged, or at least one leaf tree block is referred by higher level node. It maybe something wrong happened when level of a btree is reduced. Normally, I have no idea on how to fix such huge problem in btrfsck. But there is still some clue. In your debug-tree output, the transid difference between wanted and found is quite huge. I suppose there would be a much much newer root tree, but not recorded in superblock. So, my last bet will be, using "btrfs-find-root -a" to find the root with highest generation, and use the new root to exec "btrfsck -b ". The latest btrfs-find-root would output possible tree root by descending order of its generation. You'll find proper by
Re: kernel BUG at fs/btrfs/extent-tree.c:8113! (4.1.3 kernel)
On Mon, Aug 24, 2015 at 09:10:30AM +0800, Qu Wenruo wrote: > Would you please take the following output? > > 1) btrfs check output > With error message if it happens. myth:~# btrfs check /dev/mapper/crypt_sdd1 Checking filesystem on /dev/mapper/crypt_sdd1 UUID: 024ba4d0-dacb-438d-9f1b-eeb34083fe49 checking extents cmds-check.c:4486: add_data_backref: Assertion `back->bytes != max_size` failed. btrfs[0x8066a73] btrfs[0x8066aa4] btrfs[0x8067991] btrfs[0x806b4ab] btrfs[0x806b9a3] btrfs[0x806c5b2] btrfs(cmd_check+0x1088)[0x806eddf] btrfs(main+0x153)[0x80557c6] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb753a4d3] btrfs[0x80557ec] > 2) btrfs check --repair output > Full output until segfault. myth:~# btrfs check --repair /dev/mapper/crypt_sdd1 enabling repair mode Checking filesystem on /dev/mapper/crypt_sdd1 UUID: 024ba4d0-dacb-438d-9f1b-eeb34083fe49 checking extents cmds-check.c:4486: add_data_backref: Assertion `back->bytes != max_size` failed. btrfs[0x8066a73] btrfs[0x8066aa4] btrfs[0x8067991] btrfs[0x806b4ab] btrfs[0x806b9a3] btrfs[0x806c5b2] btrfs(cmd_check+0x1088)[0x806eddf] btrfs(main+0x153)[0x80557c6] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb75114d3] btrfs[0x80557ec] Strangely I'm not getting a segfault anymore. > 3) btrfs-debug-tree output > With assert output. The full output is multi gigabyte. Do you need this and if so, do I need to upload it somewhere and will you download the multi gigabyte file? The errors and assert, I already posted here: > >>Sure thing: > >>btrfs-debug-tree /dev/mapper/crypt_sdd1 > /tmp/tree.out > >>parent transid verify failed on 2968115101696 wanted 34855 found 39533 > >>parent transid verify failed on 2968115101696 wanted 34855 found 39533 > >>parent transid verify failed on 2968115101696 wanted 34855 found 39533 > >>parent transid verify failed on 2968115101696 wanted 34855 found 39533 > >>Ignoring transid failure > >>parent transid verify failed on 2968115134464 wanted 34855 found 39533 > >>parent transid verify failed on 2968115134464 wanted 34855 found 39533 > >>parent transid verify failed on 2968115134464 wanted 34855 found 39533 > >>parent transid verify failed on 2968115134464 wanted 34855 found 39533 > >>Ignoring transid failure > >>parent transid verify failed on 2968115150848 wanted 34855 found 39533 > >>parent transid verify failed on 2968115150848 wanted 34855 found 39533 > >>parent transid verify failed on 2968115150848 wanted 34855 found 39533 > >>parent transid verify failed on 2968115150848 wanted 34855 found 39533 > >>Ignoring transid failure > >>parent transid verify failed on 2968115691520 wanted 34855 found 39533 > >>parent transid verify failed on 2968115691520 wanted 34855 found 39533 > >>parent transid verify failed on 2968115691520 wanted 34855 found 39533 > >>parent transid verify failed on 2968115691520 wanted 34855 found 39533 > >>Ignoring transid failure > >>parent transid verify failed on 1291597152256 wanted 35830 found 39530 > >>parent transid verify failed on 1291597152256 wanted 35830 found 39530 > >>parent transid verify failed on 1291597152256 wanted 35830 found 39530 > >>parent transid verify failed on 1291597152256 wanted 35830 found 39530 > >>Ignoring transid failure > >>parent transid verify failed on 2968116592640 wanted 34855 found 39533 > >>parent transid verify failed on 2968116592640 wanted 34855 found 39533 > >>parent transid verify failed on 2968116592640 wanted 34855 found 39533 > >>parent transid verify failed on 2968116592640 wanted 34855 found 39533 > >>Ignoring transid failure > >>parent transid verify failed on 2968116609024 wanted 34855 found 39533 > >>parent transid verify failed on 2968116609024 wanted 34855 found 39533 > >>parent transid verify failed on 2968116609024 wanted 34855 found 39533 > >>parent transid verify failed on 2968116609024 wanted 34855 found 39533 > >>Ignoring transid failure > >>print-tree.c:1094: btrfs_print_tree: Assertion failed. > >>btrfs-debug-tree[0x805ce93] > >>btrfs-debug-tree(btrfs_print_tree+0x26d)[0x805eb51] > >>btrfs-debug-tree(btrfs_print_tree+0x279)[0x805eb5d] > >>btrfs-debug-tree(main+0x8b5)[0x804dfb7] > >>/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb757c4d3] > >>btrfs-debug-tree[0x804e221] Thanks, Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | PGP 1024R/763BE901 -- 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
Newbie: RAID5 available space
I'm trying out RAID5 to understand its space usage. First off, I've 3 devices of 2GB each, in RAID5. Old school RAID5 tells me I've 4GB of usable space. Actual fact: I've about 3.5GB, until it tells me I'm out of space. This is understandable, as Metadata and System took up some space. Next, I tried device add and remove. My "common sense" tells me, I should be able to remove a device of size equal or smaller than one I added. (isn't it simply move all blocks from old device to new?) So I proceeded to add a 4th device of 2GB, and remove the 2nd device (of 2GB). btrfs device delete tells me I'm out of space. Why? Here are my steps: 01. dd if=/dev/zero of=/root/btrfs-test-1 bs=1G count=2 02. losetup /dev/loop1 /root/btrfs-test-1 03. dd if=/dev/zero of=/root/btrfs-test-2 bs=1G count=2 04. losetup /dev/loop2 /root/btrfs-test-2 05. dd if=/dev/zero of=/root/btrfs-test-3 bs=1G count=2 06. losetup /dev/loop3 /root/btrfs-test-3 07. mkfs.btrfs --data raid5 --metadata raid5 --label testbtrfs2 --nodiscard -f /dev/loop1 /dev/loop2 /dev/loop3 08. mount /dev/loop2 /mnt/b 09. dd if=/dev/zero of=/mnt/b/test1g1 bs=1G count=1 10. dd if=/dev/zero of=/mnt/b/test1g2 bs=1G count=1 11. dd if=/dev/zero of=/mnt/b/test1g3 bs=1G count=1 12. dd if=/dev/zero of=/mnt/b/test512M1 bs=512M count=1 13. dd if=/dev/zero of=/root/btrfs-test-4 bs=1G count=2 14. losetup /dev/loop4 /root/btrfs-test-4 15. btrfs device add --nodiscard -f /dev/loop4 /mnt/b 16. btrfs device delete /dev/loop2 /mnt/b My kernel is 4.0.5-gentoo, btrfs-progs is 4.0.1 from Gentoo. AFTER adding /dev/loop4. As can be seen, /dev/loop4 has lots of space, almost 2GB. # btrfs device usage /mnt/b /dev/loop1, ID: 1 Device size: 2.00GiB Data,single: 8.00MiB Data,RAID5: 1.76GiB Data,RAID5: 10.50MiB Metadata,single: 8.00MiB Metadata,RAID5:204.75MiB System,single: 4.00MiB System,RAID5:8.00MiB Unallocated: 0.00B /dev/loop2, ID: 2 Device size: 2.00GiB Data,RAID5: 1.78GiB Data,RAID5: 10.50MiB Metadata,RAID5:204.75MiB System,RAID5:8.00MiB Unallocated: 1.00MiB /dev/loop3, ID: 3 Device size: 2.00GiB Data,RAID5: 1.78GiB Data,RAID5: 10.50MiB Metadata,RAID5:204.75MiB System,RAID5:8.00MiB Unallocated: 1.00MiB /dev/loop4, ID: 4 Device size: 2.00GiB Data,RAID5: 10.50MiB Data,RAID5: 19.00MiB Unallocated: 1.97GiB -- 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] Fujitsu pull part1: cleanup
Stefan, Please send your patches to the mailing list for reviews by everybody. Do you see any patch below which wasn't posted to the mailing list. ? Thanks, Anand Qu Wenruo (1): btrfs: async_thread: Fix workqueue 'max_active' value when initializing Tsutomu Itoh (1): Btrfs: cleanup: remove unnecessary check before btrfs_free_path is called Zhao Lei (6): btrfs: Update out-of-date "skip parity stripe" comment btrfs: Remove noused chunk_tree and chunk_objectid from scrub_enumerate_chunks and scrub_chunk btrfs: Cleanup for btrfs_calc_num_tolerated_disk_barrier_failures btrfs: Add raid56 support for updating num_tolerated_disk_barrier_failures in btrfs_balance btrfs: Remove useless condition in start_log_trans btrfs: Remove unused arguments in tree-log.c -- 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/extent-tree.c:8113! (4.1.3 kernel)
Marc MERLIN wrote on 2015/08/22 07:37 -0700:
On Mon, Aug 17, 2015 at 07:49:04AM -0700, Marc MERLIN wrote:
On Mon, Aug 17, 2015 at 10:01:16AM +0800, Qu Wenruo wrote:
Hi Marc,
Hi Qu, thanks for your answer and looking at this.
Did btrfs-debug-tree also has the crash?
If not, would you please attach the output if it doesn't contain
classified data.
Do you need anything else before I wipe the filesystem and start over?
1) kernel is fixed not to crash
2) btrfs check --repair segfaults
3) btrfs-debug-tree ends with assert
Thanks,
Marc
Would you please take the following output?
1) btrfs check output
With error message if it happens.
2) btrfs check --repair output
Full output until segfault.
3) btrfs-debug-tree output
With assert output.
At least this should help us to figure out what's wrong with on-disk data.
Thanks,
Qu
Sure thing:
btrfs-debug-tree /dev/mapper/crypt_sdd1 > /tmp/tree.out
parent transid verify failed on 2968115101696 wanted 34855 found 39533
parent transid verify failed on 2968115101696 wanted 34855 found 39533
parent transid verify failed on 2968115101696 wanted 34855 found 39533
parent transid verify failed on 2968115101696 wanted 34855 found 39533
Ignoring transid failure
parent transid verify failed on 2968115134464 wanted 34855 found 39533
parent transid verify failed on 2968115134464 wanted 34855 found 39533
parent transid verify failed on 2968115134464 wanted 34855 found 39533
parent transid verify failed on 2968115134464 wanted 34855 found 39533
Ignoring transid failure
parent transid verify failed on 2968115150848 wanted 34855 found 39533
parent transid verify failed on 2968115150848 wanted 34855 found 39533
parent transid verify failed on 2968115150848 wanted 34855 found 39533
parent transid verify failed on 2968115150848 wanted 34855 found 39533
Ignoring transid failure
parent transid verify failed on 2968115691520 wanted 34855 found 39533
parent transid verify failed on 2968115691520 wanted 34855 found 39533
parent transid verify failed on 2968115691520 wanted 34855 found 39533
parent transid verify failed on 2968115691520 wanted 34855 found 39533
Ignoring transid failure
parent transid verify failed on 1291597152256 wanted 35830 found 39530
parent transid verify failed on 1291597152256 wanted 35830 found 39530
parent transid verify failed on 1291597152256 wanted 35830 found 39530
parent transid verify failed on 1291597152256 wanted 35830 found 39530
Ignoring transid failure
parent transid verify failed on 2968116592640 wanted 34855 found 39533
parent transid verify failed on 2968116592640 wanted 34855 found 39533
parent transid verify failed on 2968116592640 wanted 34855 found 39533
parent transid verify failed on 2968116592640 wanted 34855 found 39533
Ignoring transid failure
parent transid verify failed on 2968116609024 wanted 34855 found 39533
parent transid verify failed on 2968116609024 wanted 34855 found 39533
parent transid verify failed on 2968116609024 wanted 34855 found 39533
parent transid verify failed on 2968116609024 wanted 34855 found 39533
Ignoring transid failure
print-tree.c:1094: btrfs_print_tree: Assertion failed.
btrfs-debug-tree[0x805ce93]
btrfs-debug-tree(btrfs_print_tree+0x26d)[0x805eb51]
btrfs-debug-tree(btrfs_print_tree+0x279)[0x805eb5d]
btrfs-debug-tree(main+0x8b5)[0x804dfb7]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb757c4d3]
btrfs-debug-tree[0x804e221]
Do you want the actual output?
(it's 1.1GB uncompressed)
Marc
Thanks,
Qu
Marc MERLIN wrote on 2015/08/12 10:19 -0700:
On Wed, Aug 12, 2015 at 12:18:45PM -0400, Josef Bacik wrote:
Going to need more info to figure this one out
Thanks for the patch, here's the output:
enabling repair mode
Checking filesystem on /dev/mapper/crypt_sdd1
UUID: 024ba4d0-dacb-438d-9f1b-eeb34083fe49
checking extents
wtf, parent 575708413952 <<
cmds-check.c:4488: add_data_backref: Assertion `back->bytes != max_size` failed.
/tmp/btrfs[0x8066a83]
/tmp/btrfs[0x8066ab4]
/tmp/btrfs[0x80679d8]
/tmp/btrfs[0x806b4f2]
/tmp/btrfs[0x806b9ea]
/tmp/btrfs[0x806c5f9]
/tmp/btrfs(cmd_check+0x1088)[0x806ee26]
/tmp/btrfs(main+0x153)[0x80557d6]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb75a54d3]
/tmp/btrfs[0x80557fc]
Marc
--
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
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems
what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
--
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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a messa
[PATCH] btrfs: async_thread: Fix workqueue 'max_active' value when initializing
At initializing time, for threshold-able workqueue, it's max_active
of kernel workqueue should be 1 and grow if it hits threshold.
But due to the bad naming, there is both 'max_active' for kernel
workqueue and btrfs workqueue.
So wrong value is given at workqueue initialization.
This patch fixes it, and to avoid further misunderstanding, change the
member name of btrfs_workqueue to 'current_active' and 'limit_active'.
Also corresponding comment is added for readability.
Reported-by: Alex Lyakas
Signed-off-by: Qu Wenruo
---
fs/btrfs/async-thread.c | 57 +
fs/btrfs/async-thread.h | 2 +-
2 files changed, 35 insertions(+), 24 deletions(-)
diff --git a/fs/btrfs/async-thread.c b/fs/btrfs/async-thread.c
index 1ce06c84..3e36e4a 100644
--- a/fs/btrfs/async-thread.c
+++ b/fs/btrfs/async-thread.c
@@ -42,8 +42,14 @@ struct __btrfs_workqueue {
/* Thresholding related variants */
atomic_t pending;
- int max_active;
- int current_max;
+
+ /* Up limit of concurrency workers */
+ int limit_active;
+
+ /* Current number of concurrency workers */
+ int current_active;
+
+ /* Threshold to change current_active */
int thresh;
unsigned int count;
spinlock_t thres_lock;
@@ -88,7 +94,7 @@ BTRFS_WORK_HELPER(scrubnc_helper);
BTRFS_WORK_HELPER(scrubparity_helper);
static struct __btrfs_workqueue *
-__btrfs_alloc_workqueue(const char *name, unsigned int flags, int max_active,
+__btrfs_alloc_workqueue(const char *name, unsigned int flags, int limit_active,
int thresh)
{
struct __btrfs_workqueue *ret = kzalloc(sizeof(*ret), GFP_NOFS);
@@ -96,26 +102,31 @@ __btrfs_alloc_workqueue(const char *name, unsigned int
flags, int max_active,
if (!ret)
return NULL;
- ret->max_active = max_active;
+ ret->limit_active = limit_active;
atomic_set(&ret->pending, 0);
if (thresh == 0)
thresh = DFT_THRESHOLD;
/* For low threshold, disabling threshold is a better choice */
if (thresh < DFT_THRESHOLD) {
- ret->current_max = max_active;
+ ret->current_active = limit_active;
ret->thresh = NO_THRESHOLD;
} else {
- ret->current_max = 1;
+ /*
+* For threshold-able wq, let its concurrency grow on demand.
+* Use minimal max_active at alloc time to reduce resource
+* usage.
+*/
+ ret->current_active = 1;
ret->thresh = thresh;
}
if (flags & WQ_HIGHPRI)
ret->normal_wq = alloc_workqueue("%s-%s-high", flags,
-ret->max_active,
-"btrfs", name);
+ret->current_active, "btrfs",
+name);
else
ret->normal_wq = alloc_workqueue("%s-%s", flags,
-ret->max_active, "btrfs",
+ret->current_active, "btrfs",
name);
if (!ret->normal_wq) {
kfree(ret);
@@ -134,7 +145,7 @@ __btrfs_destroy_workqueue(struct __btrfs_workqueue *wq);
struct btrfs_workqueue *btrfs_alloc_workqueue(const char *name,
unsigned int flags,
- int max_active,
+ int limit_active,
int thresh)
{
struct btrfs_workqueue *ret = kzalloc(sizeof(*ret), GFP_NOFS);
@@ -143,14 +154,14 @@ struct btrfs_workqueue *btrfs_alloc_workqueue(const char
*name,
return NULL;
ret->normal = __btrfs_alloc_workqueue(name, flags & ~WQ_HIGHPRI,
- max_active, thresh);
+ limit_active, thresh);
if (!ret->normal) {
kfree(ret);
return NULL;
}
if (flags & WQ_HIGHPRI) {
- ret->high = __btrfs_alloc_workqueue(name, flags, max_active,
+ ret->high = __btrfs_alloc_workqueue(name, flags, limit_active,
thresh);
if (!ret->high) {
__btrfs_destroy_workqueue(ret->normal);
@@ -180,7 +191,7 @@ static inline void thresh_queue_hook(struct
__btrfs_workqueue *wq)
*/
static inline void thresh_exec_hook(struct __btrfs_workqueue *wq)
{
- int new_max_active;
+ int new_current_active;
long pending;
int need_change = 0;
@@ -197,7 +208,7 @@ static inline void thresh_exec_hook(struct
__btrfs_workqueue *wq)
wq->count %=
[SOLVED] Re: Deleted files cause btrfs-send to fail
Am Fri, 14 Aug 2015 23:37:37 +0200 schrieb Marc Joliet : > If I notice anything amiss, I'll report back. I haven't noticed anything amiss, so I'm marking this thread as SOLVED. -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup pgpFiGtxa4hTf.pgp Description: Digitale Signatur von OpenPGP
[PATCH] btrfs: Fixed dsize and last_off declarations
The return values of btrfs_item_offset_nr and btrfs_item_size_nr are of
type u32. To avoid mixing signed and unsigned integers we should also
declare dsize and last_off to be of type u32.
Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com>
---
fs/btrfs/ctree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 54114b4..4ff739e 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -4938,8 +4938,8 @@ int btrfs_del_items(struct btrfs_trans_handle *trans,
struct btrfs_root *root,
{
struct extent_buffer *leaf;
struct btrfs_item *item;
- int last_off;
- int dsize = 0;
+ u32 last_off;
+ u32 dsize = 0;
int ret = 0;
int wret;
int i;
--
2.5.0
--
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
