statfs f_bfree vs. f_bavail
Hi all, I just noticed a mismatch between statfs.f_bfree and statfs.f_bavail, i.e. (squeeze)fslab2:~# ./statfs /data/fhgfs/storage1/ /data/fhgfs/storage1/: avail: 3162112 free: 801586610176 (with uint64_t avail = statbuf.f_bavail * statbuf.f_bsize; uint64_t free = statbuf.f_bfree * statbuf.f_bsize; ) Given the fact that I write much data to this file system anymore, f_bavail seems to be give the number I'm interested in. According to 'man 2 statfs' fsblkcnt_t f_bfree; /* free blocks in fs */ fsblkcnt_t f_bavail; /* free blocks available to unprivileged user */ f_bfree and f_bavail shouldn't differ too much. But btrfs uses two entirely different calculations for that (btrfs_statfs). f_bavail = disk_with_block_groups_total_ - disk_used - block_group_space + free_data_space f_bfree = all_disk_blocks - total_used Now for any raid level (I'm using raid6) using the sum of all data disk blocks without substracting redundancy blocks doesn't seem to be something the user is interested in. In our particular case we are using f_bavail if fhgfs-storage was started as root and f_bfree when it started from non-root (extN root user space reservation). Now with btrfs this entirely fails and even confuses our low target pool detection. I could add a workaround for btrfs for that into our code based on f_type, but I wonder if it wouldn't be better to improve btrfs_statfs. What is the actual intention for the current f_bfree value? Thanks, Bernd -- 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: raid6: rmw writes all the time?
Hello Chris, On 05/23/2013 10:33 PM, Chris Mason wrote: But I was using 8 drives. I'll try with 12. My benchmarks were on flash, so the rmw I was seeing may not have had as big an impact. I just further played with it and simply introduced a requeue in raid56_rmw_stripe() if the rbio is 'younger' than 50 jiffies. I can still see reads, but by a factor 10 lower than before. And this is sufficient to bring performance almost to that of direc-io. This is certainly no upstream code, I hope I find some time over the weekend to come up with something better. Btw, I also noticed the cache logic copies pages from those rmw-threads. Well, this a numa system and memory bandwith is terribly bad from the remote cpu. These worker threads probably should numa aware and only handle rbios from their own cpu. Cheers, Bernd -- 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
raid6: rmw writes all the time?
Hi all, we got a new test system here and I just also tested btrfs raid6 on that. Write performance is slightly lower than hw-raid (LSI megasas) and md-raid6, but it probably would be much better than any of these two, if it wouldn't read all the during the writes. Is this a known issue? This is with linux-3.9.2. Thanks, Bernd -- 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: raid6: rmw writes all the time?
On 05/23/2013 03:11 PM, Chris Mason wrote: Quoting Bernd Schubert (2013-05-23 08:55:47) Hi all, we got a new test system here and I just also tested btrfs raid6 on that. Write performance is slightly lower than hw-raid (LSI megasas) and md-raid6, but it probably would be much better than any of these two, if it wouldn't read all the during the writes. Is this a known issue? This is with linux-3.9.2. Hi Bernd, Any time you do a write smaller than a full stripe, we'll have to do a read/modify/write cycle to satisfy it. This is true of md raid6 and the hw-raid as well, but their reads don't show up in vmstat (try iostat instead). Yeah, I know and I'm using iostat already. md raid6 does not do rmw, but does not fill the device queue, afaik it flushes the underlying devices quickly as it does not have barrier support - that is another topic, but was the reason why I started to test btrfs. So the bigger question is where are your small writes coming from. If they are metadata, you can use raid1 for the metadata. I used this command /tmp/mkfs.btrfs -L test2 -f -d raid6 -m raid10 /dev/sd[m-x] so meta-data should be raid10. And I'm using this iozone command: iozone -e -i0 -i1 -r1m -l 5 -u 5 -s20g -+n \ -F /data/fhgfs/storage/md126/testfile1 /data/fhgfs/storage/md126/testfile2 /data/fhgfs/storage/md126/testfile3 \ /data/fhgfs/storage/md127/testfile1 /data/fhgfs/storage/md127/testfile2 /data/fhgfs/storage/md127/testfile3 Higher IO sizes (e.g. -r16m) don't make a difference, it goes through the page cache anyway. I'm not familiar with btrfs code at all, but maybe writepages() submits too small IOs? Hrmm, just wanted to try direct IO, but then just noticed it went into RO mode before already: May 23 14:59:33 c8220a kernel: WARNING: at fs/btrfs/super.c:255 __btrfs_abort_transaction+0xdf/0x100 [btrfs]() ay 23 14:59:33 c8220a kernel: [8105db76] warn_slowpath_fmt+0x46/0x50 May 23 14:59:33 c8220a kernel: [a0b5428a] ? btrfs_free_path+0x2a/0x40 [btrfs] May 23 14:59:33 c8220a kernel: [a0b4e18f] __btrfs_abort_transaction+0xdf/0x100 [btrfs] May 23 14:59:33 c8220a kernel: [a0b70b2f] btrfs_save_ino_cache+0x22f/0x310 [btrfs] May 23 14:59:33 c8220a kernel: [a0b793e2] commit_fs_roots+0xd2/0x1c0 [btrfs] May 23 14:59:33 c8220a kernel: [815eb3fe] ? mutex_lock+0x1e/0x50 May 23 14:59:33 c8220a kernel: [a0b7a555] btrfs_commit_transaction+0x495/0xa40 [btrfs] May 23 14:59:33 c8220a kernel: [a0b7af7b] ? start_transaction+0xab/0x4d0 [btrfs] May 23 14:59:33 c8220a kernel: [81082f30] ? wake_up_bit+0x40/0x40 May 23 14:59:33 c8220a kernel: [a0b72b96] transaction_kthread+0x1a6/0x220 [btrfs] May 23 14:59:33 c8220a kernel: ---[ end trace 3d91874abeab5984 ]--- May 23 14:59:33 c8220a kernel: BTRFS error (device sdx) in btrfs_save_ino_cache:471: error 28 May 23 14:59:33 c8220a kernel: btrfs is forced readonly May 23 14:59:33 c8220a kernel: BTRFS warning (device sdx): Skipping commit of aborted transaction. May 23 14:59:33 c8220a kernel: BTRFS error (device sdx) in cleanup_transaction:1455: error 28 errno 28 - out of disk space? Going to recreate it and will play with it later on again. Thanks, Bernd -- 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: raid6: rmw writes all the time?
On 05/23/2013 03:41 PM, Bob Marley wrote: On 23/05/2013 15:22, Bernd Schubert wrote: Yeah, I know and I'm using iostat already. md raid6 does not do rmw, but does not fill the device queue, afaik it flushes the underlying devices quickly as it does not have barrier support - that is another topic, but was the reason why I started to test btrfs. MD raid6 DOES have barrier support! For underlying devices yes, but it does not further use it for additional buffering. -- 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: raid6: rmw writes all the time?
On 05/23/2013 03:34 PM, Chris Mason wrote: Quoting Bernd Schubert (2013-05-23 09:22:41) On 05/23/2013 03:11 PM, Chris Mason wrote: Quoting Bernd Schubert (2013-05-23 08:55:47) Hi all, we got a new test system here and I just also tested btrfs raid6 on that. Write performance is slightly lower than hw-raid (LSI megasas) and md-raid6, but it probably would be much better than any of these two, if it wouldn't read all the during the writes. Is this a known issue? This is with linux-3.9.2. Hi Bernd, Any time you do a write smaller than a full stripe, we'll have to do a read/modify/write cycle to satisfy it. This is true of md raid6 and the hw-raid as well, but their reads don't show up in vmstat (try iostat instead). Yeah, I know and I'm using iostat already. md raid6 does not do rmw, but does not fill the device queue, afaik it flushes the underlying devices quickly as it does not have barrier support - that is another topic, but was the reason why I started to test btrfs. md should support barriers with recent kernels. You might want to verify with blktrace that md raid6 isn't doing r/m/w. So the bigger question is where are your small writes coming from. If they are metadata, you can use raid1 for the metadata. I used this command /tmp/mkfs.btrfs -L test2 -f -d raid6 -m raid10 /dev/sd[m-x] Ok, the stripe size is 64KB, so you want to do IO in multiples of 64KB times the number of devices on the FS. If you have 13 devices, that's 832K. Actually I have 12 devices, but we have to subtract 2 parity disks. In the mean time I also patched btrfsprogs to use a chunksize of 256K. So that should be 2560kiB now if I found the right places. Btw, any chance to generally use chunksize/chunklen instead of stripe, such as the md layer does it? IMHO it is less confusing to use n-datadisks * chunksize = stripesize. Using buffered writes makes it much more likely the VM will break up the IOs as they go down. The btrfs writepages code does try to do full stripe IO, and it also caches stripes as the IO goes down. But for buffered IO it is surprisingly hard to get a 100% hit rate on full stripe IO at larger stripe sizes. I have not found that part yet, somehow it looks like as if writepages would submit single pages to another layer. I'm going to look into it again during the weekend. I can reserve the hardware that long, but I think we first need to fix striped writes in general. so meta-data should be raid10. And I'm using this iozone command: iozone -e -i0 -i1 -r1m -l 5 -u 5 -s20g -+n \ -F /data/fhgfs/storage/md126/testfile1 /data/fhgfs/storage/md126/testfile2 /data/fhgfs/storage/md126/testfile3 \ /data/fhgfs/storage/md127/testfile1 /data/fhgfs/storage/md127/testfile2 /data/fhgfs/storage/md127/testfile3 Higher IO sizes (e.g. -r16m) don't make a difference, it goes through the page cache anyway. I'm not familiar with btrfs code at all, but maybe writepages() submits too small IOs? Hrmm, just wanted to try direct IO, but then just noticed it went into RO mode before already: Direct IO will make it easier to get full stripe writes. I thought I had fixed this abort, but it is just running out of space to write the inode cache. For now, please just don't mount with the inode cache enabled, I'll send in a fix for the next rc. Thanks, I already noticed and disabled the inode cache. Direct-io works as expected and without any RMW cycles. And that provides more than 40% better performance than the Megasas controller or buffered MD writes (I didn't compare with direct-io MD, as that is very slow). Cheers, Bernd -- 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: raid6: rmw writes all the time?
On 05/23/2013 09:37 PM, Chris Mason wrote: Quoting Bernd Schubert (2013-05-23 15:33:24) Btw, any chance to generally use chunksize/chunklen instead of stripe, such as the md layer does it? IMHO it is less confusing to use n-datadisks * chunksize = stripesize. Definitely, it will become much more configurable. Actually I meant in the code. I'm going to write a patch during the weekend. Using buffered writes makes it much more likely the VM will break up the IOs as they go down. The btrfs writepages code does try to do full stripe IO, and it also caches stripes as the IO goes down. But for buffered IO it is surprisingly hard to get a 100% hit rate on full stripe IO at larger stripe sizes. I have not found that part yet, somehow it looks like as if writepages would submit single pages to another layer. I'm going to look into it again during the weekend. I can reserve the hardware that long, but I think we first need to fix striped writes in general. The VM calls writepages and btrfs tries to suck down all the pages that belong to the same extent. And we try to allocate the extents on boundaries. There is definitely some bleeding into rmw when I do it here, but overall it does well. But I was using 8 drives. I'll try with 12. Hmm, I already tried with 10 drives (8+2), doesn't make a difference for RMW. Direct-io works as expected and without any RMW cycles. And that provides more than 40% better performance than the Megasas controller or buffered MD writes (I didn't compare with direct-io MD, as that is very slow). You can improve MD performance quite a lot by increasing the size of the stripe cache. I'm already doing that, without a higher stripe cache the performance is much lower. -- 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: No space left on device although df reports only 55% in use
On 03/27/2013 10:18 AM, Hugo Mills wrote: On Wed, Mar 27, 2013 at 12:28:23AM +0100, Clemens Eisserer wrote: I am using a btrfs loopback mounted file with lzo-compression on Linux-3.7.9, and I ran into No space left on device messages, although df reports only 55% of space is used: # touch testfile touch: cannot touch `testfile': No space left on device # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/loop0 32768000 17383924 14649172 55% /home/ce/anditest # btrfs filesystem df . Data: total=28.22GB, used=14.25GB System, DUP: total=8.00MB, used=12.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.50GB, used=1.16GB Your metadata is close to full -- we need quite a lot of working Almost 400MB are not sufficient to do simple touch? What is it doing? Cheers, Bernd -- 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: abort transaction and RO
On 01/15/2013 02:35 PM, Bernd Schubert wrote: Hrmm, that bug then seems to cause another bug. After the file system went into RO, I simply umounted and mounted again and a few seconds after that my entire system failed. Relevant logs are attached. Further log attachment: btrfsck /dev/vg_fuj2/test /tmp/btrfs.log 21 checking extents ref mismatch on [12689408 262144] extent item 1, found 0 Incorrect local backref count on 12689408 root 1 owner 256 offset 0 found 0 wanted 1 back 0x1869ef0 backpointer mismatch on [12689408 262144] owner ref check failed [12689408 262144] ref mismatch on [12951552 262144] extent item 0, found 1 Backref 12951552 root 1 owner 256 offset 0 num_refs 0 not found in extent tree Incorrect local backref count on 12951552 root 1 owner 256 offset 0 found 1 wanted 0 back 0x185faa0 backpointer mismatch on [12951552 262144] ref mismatch on [13213696 262144] extent item 1, found 0 Incorrect local backref count on 13213696 root 1 owner 273 offset 0 found 0 wanted 1 back 0x1869fd0 backpointer mismatch on [13213696 262144] owner ref check failed [13213696 262144] ref mismatch on [13475840 262144] extent item 1, found 0 Incorrect local backref count on 13475840 root 1 owner 259 offset 0 found 0 wanted 1 back 0x186a0b0 backpointer mismatch on [13475840 262144] owner ref check failed [13475840 262144] ref mismatch on [13737984 262144] extent item 1, found 0 Incorrect local backref count on 13737984 root 1 owner 260 offset 0 found 0 wanted 1 back 0x186a190 backpointer mismatch on [13737984 262144] owner ref check failed [13737984 262144] ref mismatch on [14000128 262144] extent item 1, found 0 Incorrect local backref count on 14000128 root 1 owner 261 offset 0 found 0 wanted 1 back 0x186a270 backpointer mismatch on [14000128 262144] owner ref check failed [14000128 262144] ref mismatch on [14262272 262144] extent item 1, found 0 Incorrect local backref count on 14262272 root 1 owner 257 offset 0 found 0 wanted 1 back 0x186a350 backpointer mismatch on [14262272 262144] owner ref check failed [14262272 262144] ref mismatch on [14524416 262144] extent item 1, found 0 Incorrect local backref count on 14524416 root 1 owner 262 offset 0 found 0 wanted 1 back 0x186a430 backpointer mismatch on [14524416 262144] owner ref check failed [14524416 262144] ref mismatch on [14786560 262144] extent item 1, found 0 Incorrect local backref count on 14786560 root 1 owner 263 offset 0 found 0 wanted 1 back 0x186a510 backpointer mismatch on [14786560 262144] owner ref check failed [14786560 262144] ref mismatch on [15048704 262144] extent item 1, found 0 Incorrect local backref count on 15048704 root 1 owner 264 offset 0 found 0 wanted 1 back 0x186a5f0 backpointer mismatch on [15048704 262144] owner ref check failed [15048704 262144] ref mismatch on [15310848 262144] extent item 1, found 0 Incorrect local backref count on 15310848 root 1 owner 265 offset 0 found 0 wanted 1 back 0x186a6d0 backpointer mismatch on [15310848 262144] owner ref check failed [15310848 262144] ref mismatch on [15572992 262144] extent item 1, found 0 Incorrect local backref count on 15572992 root 1 owner 266 offset 0 found 0 wanted 1 back 0x186a7b0 backpointer mismatch on [15572992 262144] owner ref check failed [15572992 262144] ref mismatch on [15835136 262144] extent item 1, found 0 Incorrect local backref count on 15835136 root 1 owner 267 offset 0 found 0 wanted 1 back 0x186a890 backpointer mismatch on [15835136 262144] owner ref check failed [15835136 262144] ref mismatch on [16097280 262144] extent item 1, found 0 Incorrect local backref count on 16097280 root 1 owner 268 offset 0 found 0 wanted 1 back 0x186a970 backpointer mismatch on [16097280 262144] owner ref check failed [16097280 262144] ref mismatch on [16359424 262144] extent item 1, found 0 Incorrect local backref count on 16359424 root 1 owner 269 offset 0 found 0 wanted 1 back 0x186aa50 backpointer mismatch on [16359424 262144] owner ref check failed [16359424 262144] ref mismatch on [16621568 262144] extent item 1, found 0 Incorrect local backref count on 16621568 root 1 owner 270 offset 0 found 0 wanted 1 back 0x186ab30 backpointer mismatch on [16621568 262144] owner ref check failed [16621568 262144] ref mismatch on [16883712 262144] extent item 1, found 0 Incorrect local backref count on 16883712 root 1 owner 271 offset 0 found 0 wanted 1 back 0x186ac10 backpointer mismatch on [16883712 262144] owner ref check failed [16883712 262144] ref mismatch on [17145856 262144] extent item 1, found 0 Incorrect local backref count on 17145856 root 1 owner 272 offset 0 found 0 wanted 1 back 0x186acf0 backpointer mismatch on [17145856 262144] owner ref check failed [17145856 262144] ref mismatch on [17408000 262144] extent item 1, found 0 Incorrect local backref count on 17408000 root 1 owner 281 offset 0 found 0 wanted 1 back 0x186add0 backpointer mismatch on [17408000 262144] owner ref check failed [17408000 262144] ref mismatch on [17670144 262144] extent item 1, found 0
Re: bonnie triggers and endless numbers of stack traces
On 08/19/2011 09:36 PM, Josef Bacik wrote:
On 08/19/2011 12:45 PM, Bernd Schubert wrote:
Just for performance tests I run:
./bonnie++ -d /mnt/btrfs -s0 -n 1:256:256:1 -r 0
and this causes and endless number of stack traces. Those seem to
come from:
use_block_rsv()
ret = block_rsv_use_bytes(block_rsv, blocksize);
if (!ret)
return block_rsv;
if (ret) {
WARN_ON(1);
ret = reserve_metadata_bytes(trans, root, block_rsv, blocksize,
Why is there a WARN_ON(1)? Running the bonnie benchmark is basically impossible
that.
This is being worked on, if you really don't like it pull my git tree
and test it out and see if the errors go away
git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-work.git
Do you plan to fix it for 3.1? If not, any chance to at least update it
to WARN_ON_ONCE?
Thanks,
Bernd
--
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
bonnie triggers and endless numbers of stack traces
Just for performance tests I run:
./bonnie++ -d /mnt/btrfs -s0 -n 1:256:256:1 -r 0
and this causes and endless number of stack traces. Those seem to
come from:
use_block_rsv()
ret = block_rsv_use_bytes(block_rsv, blocksize);
if (!ret)
return block_rsv;
if (ret) {
WARN_ON(1);
ret = reserve_metadata_bytes(trans, root, block_rsv, blocksize,
Why is there a WARN_ON(1)? Running the bonnie benchmark is basically impossible
that.
Thanks,
Bernd
Aug 19 18:30:56 fslab2 kernel: [ 265.255644] Loglevel set to 9
Aug 19 18:31:26 fslab2 kernel: [ 295.490858] [ cut here
]
Aug 19 18:31:26 fslab2 kernel: [ 295.495589] WARNING: at
fs/btrfs/extent-tree.c:5711 btrfs_alloc_free_block+0x200/0x360 [btrfs]()
Aug 19 18:31:26 fslab2 kernel: [ 295.504472] Hardware name: H8DCE
Aug 19 18:31:26 fslab2 kernel: [ 295.507750] Modules linked in: nfsd ib_umad
rdma_ucm rdma_cm iw_cm ib_addr ib_uverbs sg ib_ipoib ib_cm ib_sa ip
v6 sd_mod crc_t10dif loop arcmsr md_mod ib_mthca ib_mad pcspkr ib_core
8250_pnp fuse af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc btrfs
lzo_decompress lzo_compress zlib_deflate crc32c libcrc32c crypto_hash
crypto_algapi ata_generic pata_acpi e1000 pata_amd sata_nv libata scsi_mod
unix [last unloaded: scsi_wait_scan]
Aug 19 18:31:26 fslab2 kernel: [ 295.548618] Pid: 2074, comm: bonnie++ Not
tainted 3.1.0-rc2+ #34
Aug 19 18:31:26 fslab2 kernel: [ 295.554695] Call Trace:
Aug 19 18:31:26 fslab2 kernel: [ 295.557209] [8105c677] ?
console_unlock+0x227/0x290
Aug 19 18:31:26 fslab2 kernel: [ 295.563111] [8105bb7f]
warn_slowpath_common+0x7f/0xc0
Aug 19 18:31:26 fslab2 kernel: [ 295.569186] [8105bbda]
warn_slowpath_null+0x1a/0x20
Aug 19 18:31:26 fslab2 kernel: [ 295.575096] [a013d0d0]
btrfs_alloc_free_block+0x200/0x360 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.582230] [a0165d10] ?
lock_delalloc_pages+0x1f0/0x1f0 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.589280] [a0127b6b]
__btrfs_cow_block+0x14b/0x6e0 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.595978] [a0179144] ?
btrfs_try_tree_write_lock+0x44/0x80 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.603394] [a0128217]
btrfs_cow_block+0x117/0x260 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.609920] [a012e455]
btrfs_search_slot+0x385/0xaa0 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.616621] [a0140f3f]
btrfs_lookup_inode+0x2f/0xa0 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.623236] [a0190eb3]
btrfs_update_delayed_inode+0x73/0x160 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.630644] [8137163e] ?
mutex_unlock+0xe/0x10
Aug 19 18:31:26 fslab2 kernel: [ 295.636125] [a0192088]
btrfs_run_delayed_items+0xe8/0x120 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.643254] [a014a240]
btrfs_commit_transaction+0x230/0x870 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.650585] [a0149de9] ?
join_transaction+0x69/0x290 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.657274] [8107f410] ?
wake_up_bit+0x40/0x40
Aug 19 18:31:26 fslab2 kernel: [ 295.662783] [81171700] ?
__sync_filesystem+0x90/0x90
Aug 19 18:31:26 fslab2 kernel: [ 295.668783] [a0124ace]
btrfs_sync_fs+0x5e/0xd0 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.674951] [811716ce]
__sync_filesystem+0x5e/0x90
Aug 19 18:31:26 fslab2 kernel: [ 295.680764] [8117171f]
sync_one_sb+0x1f/0x30
Aug 19 18:31:26 fslab2 kernel: [ 295.686061] [8114751f]
iterate_supers+0x7f/0xe0
Aug 19 18:31:26 fslab2 kernel: [ 295.691613] [81171775]
sys_sync+0x45/0x70
Aug 19 18:31:26 fslab2 kernel: [ 295.696648] [8137b4c2]
system_call_fastpath+0x16/0x1b
Aug 19 18:31:26 fslab2 kernel: [ 295.702726] ---[ end trace 5328a9730b4cdff4
]---
Aug 19 18:31:26 fslab2 kernel: [ 295.707533] [ cut here
]
Aug 19 18:31:26 fslab2 kernel: [ 295.712230] WARNING: at
fs/btrfs/extent-tree.c:5711 btrfs_alloc_free_block+0x200/0x360 [btrfs]()
Aug 19 18:31:26 fslab2 kernel: [ 295.721114] Hardware name: H8DCE
Aug 19 18:31:26 fslab2 kernel: [ 295.724410] Modules linked in: nfsd ib_umad
rdma_ucm rdma_cm iw_cm ib_addr ib_uverbs sg ib_ipoib ib_cm ib_sa ip
v6 sd_mod crc_t10dif loop arcmsr md_mod ib_mthca ib_mad pcspkr ib_core
8250_pnp fuse af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc btrfs
lzo_decompress lzo_compress zlib_deflate crc32c libcrc32c crypto_hash
crypto_algapi ata_generic pata_acpi e1000 pata_amd sata_nv libata scsi_mod
[...]
repeats at least a few thousand times and fills the logs...
--
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: bonnie triggers and endless numbers of stack traces
I think we either should remove it or replace by WARN_ON_ONCE()
Remove WARN_ON(1) in a common code path
From: Bernd Schubert bernd.schub...@itwm.fraunhofer.de
Something like bonnie++ -d /mnt/btrfs -s0 -n 1:256:256:1 -r 0
will trigger lots of those WARN_ON(1), so lets remove it.
Signed-off-by: Bernd Schubert bernd.schub...@itwm.fraunhofer.de
---
fs/btrfs/extent-tree.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 80d6148..1d1a8d0 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -5708,7 +5708,6 @@ use_block_rsv(struct btrfs_trans_handle *trans,
if (!ret)
return block_rsv;
if (ret) {
- WARN_ON(1);
ret = reserve_metadata_bytes(trans, root, block_rsv, blocksize,
0);
if (!ret) {
--
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
