Re: Inefficient storing of ISO images with compress=lzo
07:06, Maciej Marcin Piechotka wrote: > On Mon, 2011-09-19 at 10:53 +0800, Li Zefan wrote: >> Maciej Marcin Piechotka wrote: >>> I've noticed that: >>> >>> - with x86-64 Fedora 15 DVD install images: >>>- du -sh was 36 GB >>>- btrfs df | grep -i data have shown over 40 GB used >>> - without >>>- du -sh is 34 GB >>>- btrfs df | grep -i data have shown less then 34 GB used >>> >>> It seems that iso files are considered compressable while they may not be >>> (and penalty is severe - 3x). >>> >> >> With compress option specified, btrfs will try to compress the file, at most >> 128K at one time, and if the compressed result is not smaller, the file will >> be marked as uncompressable. >> >> I just tried with Fedora-14-i386-DVD.iso, and the first 896K is compressed, >> with a compress ratio about 71.7%, and the remaining data is not compressed. >> >> -- >> Li Zefan > > Just a question from person who don't know how btrfs operates - what if > the beginning of file is well compressable and the rest is not? > It's explained in the previous mail - the beginning part will be compressed, and the rest will not. > In any case the compression was my uneducated guess where is missing > 4GB. > It probably has nothing to do with compression. You can try without compress=lzo, and see if the issue still exists. -- 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
Hi everyone, The for-linus branch of the btrfs tree on github: Head commit: a66e7cc626f42de6c745963fe0d807518fa49d39 git://github.com/chrismason/linux.git for-linus Has the following fixes. for-linus is against rc6, since some of these are regression fixes for earlier 3.1 btrfs commits. The most important of the bunch is Josef's dentry fix, which avoids enoents if we race with multiple procs hitting on the same inode. This bug is btrfs-specific, it came in with his optimization to cache the inode location during readdir. Li Zefan (3) commits (+9/-5): Btrfs: don't make a file partly checksummed through file clone (+5/-0) Btrfs: don't change inode flag of the dest clone file (+0/-1) Btrfs: fix pages truncation in btrfs_ioctl_clone() (+4/-4) Josef Bacik (1) commits (+11/-2): Btrfs: only clear the need lookup flag after the dentry is setup Jeff Liu (1) commits (+7/-2): BTRFS: Fix lseek return value for error Hidetoshi Seto (1) commits (+3/-2): btrfs: fix d_off in the first dirent Total: (6) commits (+30/-11) fs/btrfs/file.c |9 +++-- fs/btrfs/inode.c | 18 ++ fs/btrfs/ioctl.c | 14 +- 3 files changed, 30 insertions(+), 11 deletions(-) -- 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: Inefficient storing of ISO images with compress=lzo
On Mon, 2011-09-19 at 10:53 +0800, Li Zefan wrote: > Maciej Marcin Piechotka wrote: > > I've noticed that: > > > > - with x86-64 Fedora 15 DVD install images: > >- du -sh was 36 GB > >- btrfs df | grep -i data have shown over 40 GB used > > - without > >- du -sh is 34 GB > >- btrfs df | grep -i data have shown less then 34 GB used > > > > It seems that iso files are considered compressable while they may not be > > (and penalty is severe - 3x). > > > > With compress option specified, btrfs will try to compress the file, at most > 128K at one time, and if the compressed result is not smaller, the file will > be marked as uncompressable. > > I just tried with Fedora-14-i386-DVD.iso, and the first 896K is compressed, > with a compress ratio about 71.7%, and the remaining data is not compressed. > > -- > Li Zefan Just a question from person who don't know how btrfs operates - what if the beginning of file is well compressable and the rest is not? In any case the compression was my uneducated guess where is missing 4GB. Regards -- 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: [PATCH 1/7] BTRFS: Fix lseek return value for error
Excerpts from Andi Kleen's message of 2011-09-19 15:59:52 -0400: > On Mon, Sep 19, 2011 at 03:30:02PM -0400, Chris Mason wrote: > > Excerpts from Andi Kleen's message of 2011-09-19 13:52:03 -0400: > > > > Thanks everyone, I've put Jeff's last version of this in my queue. > > > > > > Can you post the version you merged? The previous ones all had issues. > > > > https://github.com/chrismason/linux/commit/48802c8ae2a9d618ec734a61283d645ad527e06c > > > > This was the last one sent, I thought it combined all the fixes. > > Ok looks good, but it will be all obsolete once my patchkit lseek > get in (except for the SEEK_DATA/HOLE hunk) Yeah, it's similar to yours except for the hole hunk. Your gotos are fine by me, whatever makes your patch cleaner. -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: [PATCH 1/7] BTRFS: Fix lseek return value for error
On Mon, Sep 19, 2011 at 03:30:02PM -0400, Chris Mason wrote: > Excerpts from Andi Kleen's message of 2011-09-19 13:52:03 -0400: > > > Thanks everyone, I've put Jeff's last version of this in my queue. > > > > Can you post the version you merged? The previous ones all had issues. > > https://github.com/chrismason/linux/commit/48802c8ae2a9d618ec734a61283d645ad527e06c > > This was the last one sent, I thought it combined all the fixes. Ok looks good, but it will be all obsolete once my patchkit lseek get in (except for the SEEK_DATA/HOLE hunk) -Andi -- 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: [PATCH 1/7] BTRFS: Fix lseek return value for error
Excerpts from Andi Kleen's message of 2011-09-19 13:52:03 -0400:
> > Thanks everyone, I've put Jeff's last version of this in my queue.
>
> Can you post the version you merged? The previous ones all had issues.
https://github.com/chrismason/linux/commit/48802c8ae2a9d618ec734a61283d645ad527e06c
This was the last one sent, I thought it combined all the fixes.
commit 48802c8ae2a9d618ec734a61283d645ad527e06c
Author: Jeff Liu
Date: Sun Sep 18 10:34:02 2011 -0400
BTRFS: Fix lseek return value for error
The recent reworking of btrfs' lseek lead to incorrect
values being returned. This adds checks for seeking
beyond EOF in SEEK_HOLE and makes sure the error
values come back correct.
Andi Kleen also sent in similar patches.
Signed-off-by: Jie Liu
Reported-by: Andi Kleen
Signed-off-by: Chris Mason
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 3c3abff..a381cd2 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1817,6 +1817,11 @@ static loff_t btrfs_file_llseek(struct file *file,
loff_t offset, int origin)
goto out;
case SEEK_DATA:
case SEEK_HOLE:
+ if (offset >= i_size_read(inode)) {
+ mutex_unlock(&inode->i_mutex);
+ return -ENXIO;
+ }
+
ret = find_desired_extent(inode, &offset, origin);
if (ret) {
mutex_unlock(&inode->i_mutex);
@@ -1825,11 +1830,11 @@ static loff_t btrfs_file_llseek(struct file *file,
loff_t offset, int origin)
}
if (offset < 0 && !(file->f_mode & FMODE_UNSIGNED_OFFSET)) {
- ret = -EINVAL;
+ offset = -EINVAL;
goto out;
}
if (offset > inode->i_sb->s_maxbytes) {
- ret = -EINVAL;
+ offset = -EINVAL;
goto out;
}
--
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: [PATCH 1/7] BTRFS: Fix lseek return value for error
> Thanks everyone, I've put Jeff's last version of this in my queue. Can you post the version you merged? The previous ones all had issues. -Andi -- 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: delay iput when deleting a block group
I kept getting warnings from evict because we were calling btrfs_start_transaction() with a transaction already started when doing a balance. This is because we remove a block group which requires a transaction, and the put the last reference on the cache inode. Instead of doing this we need to delay the iput so it is done not within a transaction having started. This gets rid of our warnings. Thanks, Signed-off-by: Josef Bacik --- fs/btrfs/extent-tree.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 9bb7159..5498bda 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -7266,7 +7266,7 @@ int btrfs_remove_block_group(struct btrfs_trans_handle *trans, spin_unlock(&block_group->lock); } /* One for our lookup ref */ - iput(inode); + btrfs_add_delayed_iput(inode); } key.objectid = BTRFS_FREE_SPACE_OBJECTID; -- 1.7.5.2 -- 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: make sure to unset trans->block_rsv before running delayed refs
Checksums are charged in 2 different ways. The first case is when we're writing
to the disk, we account for the new checksums with the delalloc block rsv. In
order for this to work we check if we're allocating a block for the csum root
and if trans->block_rsv == the delalloc block rsv. But when we're deleting the
csums because of cow, this is charged to the global block rsv, and is done when
we run the delayed refs. So we need to make sure that trans->block_rsv == NULL
when running the delayed refs. So set it to NULL and reset it in
should_end_transaction, and set it to NULL in commit_transaction. This got rid
of the ridiculous amount of warnings I was seeing when trying to do a balance.
Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/transaction.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index 54be080..cadc3c8 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -427,17 +427,26 @@ int btrfs_should_end_transaction(struct
btrfs_trans_handle *trans,
struct btrfs_root *root)
{
struct btrfs_transaction *cur_trans = trans->transaction;
+ struct btrfs_block_rsv *rsv = trans->block_rsv;
int updates;
smp_mb();
if (cur_trans->blocked || cur_trans->delayed_refs.flushing)
return 1;
+ /*
+* We need to do this in case we're deleting csums so the global block
+* rsv get's used instead of the csum block rsv.
+*/
+ trans->block_rsv = NULL;
+
updates = trans->delayed_ref_updates;
trans->delayed_ref_updates = 0;
if (updates)
btrfs_run_delayed_refs(trans, root, updates);
+ trans->block_rsv = rsv;
+
return should_end_transaction(trans, root);
}
@@ -1163,6 +1172,8 @@ int btrfs_commit_transaction(struct btrfs_trans_handle
*trans,
btrfs_run_ordered_operations(root, 0);
+ trans->block_rsv = NULL;
+
/* make a pass through all the delayed refs we have so far
* any runnings procs may add more while we are here
*/
--
1.7.5.2
--
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: WARNING: at fs/btrfs/inode.c:2193 btrfs_orphan_commit_root+0xb0/0xc0 [btrfs]()
On 09/16/2011 12:25 PM, Jim Schutt wrote: > David Sterba wrote: >> On Thu, Sep 15, 2011 at 11:44:09AM -0700, Sage Weil wrote: >>> On Tue, 13 Sep 2011, Liu Bo wrote: On 09/11/2011 05:47 AM, Martin Mailand wrote: > Hi > I am hitting this Warning reproducible, the workload is a ceph osd, > kernel ist 3.1.0-rc5. > Have posted a patch for this: http://marc.info/?l=linux-btrfs&m=131547325515336&w=2 >>> We're still seeing this with -rc6, which includes 98c9942 and 65450aa. >> >> Me too, for the >> WARNING: at fs/btrfs/extent-tree.c:5711 >> btrfs_alloc_free_block+0x180/0x350 [btrfs]() >> > > FWIW, I'm seeing a slightly different case, while testing branch > integration/btrfs-next (commit 2828cbd9620e03) from > git://repo.or.cz/linux-2.6/btrfs-unstable.git merged into branch > master (commit c455ea4f122d21) from git://github.com/torvalds/linux.git > Ah yeah sorry I see what's going on here, I just missed a few places we call run_delayed_refs() where we can still have trans->block_rsv set. I will fix this and send a patch soon. Thanks, Josef -- 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: kerenl bug after btrfs resize (reduce size)
On Mon, Sep 19, 2011 at 14:38, Hugo Mills wrote: > On Mon, Sep 19, 2011 at 02:24:55PM +0200, Roman Kapusta wrote: >> After running 'btrfs fi resize' I got following error, fortunately, it >> looks that filesystem is ok. >> I was changing filesystem size from 256 GB to 192 GB (reducing by >> 64GB), free space was 110GB. > > I would be careful here -- the FS may be OK in that it's all > readable, but it may not have shrunk by as much as you requested. In > other words, don't drop the size of the containing partition until > you've successfully run a resize without it crashing. > I've forgot to mention that Xorg hanged (and all processes accessing btrfs partition), I have tried to reboot from console, not successfully. After hard reset filesystem was not resized and all stored data looks ok. >> My system is Fedora 14. I'm considering upgrade to Fedora 15, is this >> already fixed? > [snip] >> Not tainted 2.6.35.14-96.fc14.i686 #1 30A2/HP Compaq nx7400 > > In btrfs terms, this is a kernel from the Dark Ages. You should > upgrade to something recent *immediately*. There are all kinds of > nasty bugs in 2.6.35 (and later) that have been fixed. I don't know if > this particular one is one of them, but running btrfs on 2.6.35 is > rather like juggling nitrogylcerine: bad things *will* happen, sooner > or later. > > I would strongly recommend running a 3.0 or 3.1-rc kernel (at least > until 3.1 comes out, then keep following the latest kernel releases). Ok I'm going to upgrade and then I will try again to resize. > > Hugo. > > -- > === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === > PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk > --- In the future, terrorists won't be carrying their ID cards. --- > They'll be carrying yours. -- Henry > Porter, Suspect Nation > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iD8DBQFOdze5IKyzvlFcI40RAtgQAJ4p/ufc4VYrxRm97AvJ6jYfGr/GJQCglcN6 > g6pHYvPZgdP+kMPopPOLZvI= > =vN6B > -END PGP SIGNATURE- > > -- 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: kerenl bug after btrfs resize (reduce size)
On Mon, Sep 19, 2011 at 02:24:55PM +0200, Roman Kapusta wrote: > After running 'btrfs fi resize' I got following error, fortunately, it > looks that filesystem is ok. > I was changing filesystem size from 256 GB to 192 GB (reducing by > 64GB), free space was 110GB. I would be careful here -- the FS may be OK in that it's all readable, but it may not have shrunk by as much as you requested. In other words, don't drop the size of the containing partition until you've successfully run a resize without it crashing. > My system is Fedora 14. I'm considering upgrade to Fedora 15, is this > already fixed? [snip] > Not tainted 2.6.35.14-96.fc14.i686 #1 30A2/HP Compaq nx7400 In btrfs terms, this is a kernel from the Dark Ages. You should upgrade to something recent *immediately*. There are all kinds of nasty bugs in 2.6.35 (and later) that have been fixed. I don't know if this particular one is one of them, but running btrfs on 2.6.35 is rather like juggling nitrogylcerine: bad things *will* happen, sooner or later. I would strongly recommend running a 3.0 or 3.1-rc kernel (at least until 3.1 comes out, then keep following the latest kernel releases). Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- In the future, terrorists won't be carrying their ID cards. --- They'll be carrying yours. -- Henry Porter, Suspect Nation signature.asc Description: Digital signature
kerenl bug after btrfs resize (reduce size)
After running 'btrfs fi resize' I got following error, fortunately, it looks that filesystem is ok. I was changing filesystem size from 256 GB to 192 GB (reducing by 64GB), free space was 110GB. My system is Fedora 14. I'm considering upgrade to Fedora 15, is this already fixed? Sep 19 12:58:54 cyro kernel: [13235.702666] new size for /dev/mapper/VolGroup-btrfs is 206158430208 Sep 19 12:58:54 cyro kernel: [13235.760728] btrfs: relocating block group 393236971520 flags 1 Sep 19 12:59:31 cyro kernel: [13273.243895] btrfs: found 17209 extents Sep 19 13:01:05 cyro kernel: [13366.953112] btrfs: unlinked 9 orphans Sep 19 13:01:50 cyro kernel: [13412.117164] [ cut here ] Sep 19 13:01:50 cyro kernel: [13412.117173] kernel BUG at fs/btrfs/relocation.c:837! Sep 19 13:01:50 cyro kernel: [13412.117179] invalid opcode: [#1] SMP Sep 19 13:01:50 cyro kernel: [13412.117186] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq Sep 19 13:01:50 cyro kernel: [13412.117190] Modules linked in: tcp_lp fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat bridge stp llc rfcomm sco bnep l2cap vboxnetadp vboxnetflt vboxdrv cpufreq_ondemand sunrpc ppdev parport_pc parport acpi_cpufreq mperf ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_analog snd_hda_intel arc4 btusb ecb bluetooth iwl3945 snd_hda_codec snd_hwdep snd_seq snd_seq_device iwlcore iTCO_wdt b44 snd_pcm hp_wmi iTCO_vendor_support ssb mac80211 mmc_core snd_timer cfg80211 wmi mii snd soundcore rfkill microcode snd_page_alloc joydev serio_raw btrfs zlib_deflate libcrc32c firewire_ohci firewire_core crc_itu_t yenta_socket i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: cpufreq_ondemand] Sep 19 13:01:50 cyro kernel: [13412.117310] Sep 19 13:01:50 cyro kernel: [13412.117317] Pid: 11791, comm: btrfs Not tainted 2.6.35.14-96.fc14.i686 #1 30A2/HP Compaq nx7400 (RU430EA#AKR) Sep 19 13:01:50 cyro kernel: [13412.117324] EIP: 0060:[] EFLAGS: 00210246 CPU: 1 Sep 19 13:01:50 cyro kernel: [13412.117367] EIP is at build_backref_tree+0x3de/0xac4 [btrfs] Sep 19 13:01:50 cyro kernel: [13412.117373] EAX: cc405420 EBX: f58367e0 ECX: 004b EDX: 4e75f000 Sep 19 13:01:50 cyro kernel: [13412.117379] ESI: cc405420 EDI: ed5b5180 EBP: f521bc94 ESP: f521bc04 Sep 19 13:01:50 cyro kernel: [13412.117384] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Sep 19 13:01:50 cyro kernel: [13412.117391] Process btrfs (pid: 11791, ti=f521a000 task=f5268ca0 task.ti=f521a000) Sep 19 13:01:50 cyro kernel: [13412.117395] Stack: Sep 19 13:01:50 cyro kernel: [13412.117398] 0004064d c09c9cb0 c1a60ce0 f521bc78 f521bc2c c04cf823 cf436f54 Sep 19 13:01:50 cyro kernel: [13412.117410] <0> f1afe010 f583680c f58364e0 f1afe098 f1afe094 cc1f3e60 f58364e0 f5e32690 Sep 19 13:01:50 cyro kernel: [13412.117423] <0> ed5b5560 f5e32c40 f1afe000 d1314000 f5836ba0 00afe010 4b3ed080 Sep 19 13:01:50 cyro kernel: [13412.117438] Call Trace: Sep 19 13:01:50 cyro kernel: [13412.117449] [] ? add_partial+0x2b/0x3b Sep 19 13:01:50 cyro kernel: [13412.117498] [] ? relocate_tree_blocks+0x12e/0x3d8 [btrfs] Sep 19 13:01:50 cyro kernel: [13412.117545] [] ? relocate_block_group+0x1c5/0x441 [btrfs] Sep 19 13:01:50 cyro kernel: [13412.117590] [] ? btrfs_clean_old_snapshots+0x66/0xbd [btrfs] Sep 19 13:01:50 cyro kernel: [13412.117634] [] ? btrfs_relocate_block_group+0xe0/0x208 [btrfs] Sep 19 13:01:50 cyro kernel: [13412.117679] [] ? btrfs_relocate_chunk.clone.34+0x54/0x42d [btrfs] Sep 19 13:01:50 cyro kernel: [13412.117690] [] ? kmap_atomic+0x13/0x15 Sep 19 13:01:50 cyro kernel: [13412.117735] [] ? map_private_extent_buffer+0x94/0xb6 [btrfs] Sep 19 13:01:50 cyro kernel: [13412.117778] [] ? map_extent_buffer+0x4f/0x7f [btrfs] Sep 19 13:01:50 cyro kernel: [13412.117787] [] ? kunmap_atomic+0x5f/0x85 Sep 19 13:01:50 cyro kernel: [13412.117830] [] ? unmap_extent_buffer+0x11/0x13 [btrfs] Sep 19 13:01:50 cyro kernel: [13412.117876] [] ? btrfs_dev_extent_chunk_offset+0xa2/0xae [btrfs] Sep 19 13:01:50 cyro kernel: [13412.117920] [] ? btrfs_shrink_device+0x1dc/0x2f3 [btrfs] Sep 19 13:01:50 cyro kernel: [13412.117964] [] ? btrfs_ioctl_resize+0x274/0x2a9 [btrfs] Sep 19 13:01:50 cyro kernel: [13412.118008] [] ? btrfs_ioctl+0x525/0x7d3 [btrfs] Sep 19 13:01:50 cyro kernel: [13412.118017] [] ? pty_write+0x41/0x4f Sep 19 13:01:50 cyro kernel: [13412.118025] [] ? __raw_local_irq_save+0x19/0x1e Sep 19 13:01:50 cyro kernel: [13412.118035] [] ? file_has_perm+0x8d/0xa7 Sep 19 13:01:50 cyro kernel: [13412.118043] [] ? vfs_ioctl+0x33/0x91 Sep 19 13:01:50 cyro kernel: [13412.118047] [] ? btrfs_ioctl+0x0/0x7d3 [btrfs] Sep 19 13:01:50 cyro kernel: [13412.118047] [] ? do_vfs_ioctl+0x462/0x48d Sep 19 13:01:50 cyro kernel: [13412.118047] [] ? selinux_file_ioctl+0x43/0x46 Sep 19 13:01:50 cyro kernel: [13412.118047] [] ? sys_ioctl+0x46/0x69 Sep 19 13:01:50 cyro kernel: [13412.118047] [] ? syscall_call+0x7/0xb Sep 19 13:01:50 cyro
Re: WARNING: at fs/btrfs/inode.c:2193 btrfs_orphan_commit_root+0xb0/0xc0 [btrfs]()
On Fri, Sep 16, 2011 at 10:25:51AM -0600, Jim Schutt wrote: > >WARNING: at fs/btrfs/extent-tree.c:5711 btrfs_alloc_free_block+0x180/0x350 > >[btrfs]() > > > > FWIW, I'm seeing a slightly different case, while testing branch > integration/btrfs-next (commit 2828cbd9620e03) from > git://repo.or.cz/linux-2.6/btrfs-unstable.git merged into branch > master (commit c455ea4f122d21) from git://github.com/torvalds/linux.git > > Under a heavy ceph write load, I see lots of these: same warning from mainline fs/btrfs/extent-tree.c:5711 matching fs/btrfs/extent-tree.c:5751 in the btrfs-next branch and is ratelimited. It does not seem to be fixed by the patch, but as the branch contains other patches, it could be caused ty them, I didn't have a closer look. You can try with just Josef's branch on top of mainline if you have a good way to trigger the warnings. > [ 2369.797044] [ cut here ] > [ 2369.801759] WARNING: at fs/btrfs/extent-tree.c:5751 > use_block_rsv+0x177/0x180 [btrfs]() > [ 2369.809864] Hardware name: X8DTH-i/6/iF/6F > [ 2369.814062] Modules linked in: loop btrfs zlib_deflate lzo_compress > ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state > nf_conntrack > [ 2369.828671] btrfs: journal_info set but trans not join/nolock: 0x1 > [ 2369.829040] ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables > bridge stp scsi_transport_iscsi rds ib_ipoib rdma_ucm rdma_cm ib_ucm > ib_uverbs ib_umad ib_cm iw_cm ib_addr ipv6 ib_sa dm_mirror dm_region_hash > dm_log dm_multipath scsi_dh dm_mod video sbs sbshc pci_slot battery > acpi_pad ac kvm sg sd_mod mlx4_ib ib_mad ib_core mlx4_en joydev mpt2sas > tpm_tis tpm scsi_transport_sas mlx4_core cxgb4 button serio_raw raid_class > tpm_bios ata_piix libata scsi_mod i2c_i801 ioatdma ehci_hcd iTCO_wdt > uhci_hcd i2c_core i7core_edac iTCO_vendor_support edac_core pcspkr rtc nfs > nfs_acl auth_rpcgss fscache lockd sunrpc tg3 bnx2 igb dca e1000 > [ 2369.889908] Pid: 23744, comm: kworker/19:3 Tainted: GW > 3.1.0-rc6-00265-gf883c8c #33 > [ 2369.898510] Call Trace: > [ 2369.901026] [] warn_slowpath_common+0x7f/0xc0 > [ 2369.907046] [] warn_slowpath_null+0x1a/0x20 > [ 2369.912935] [] use_block_rsv+0x177/0x180 [btrfs] > [ 2369.919422] [] btrfs_alloc_free_block+0x3d/0x220 > [btrfs] > [ 2369.926431] [] ? __set_page_dirty_nobuffers+0xe1/0x150 > [ 2369.933265] [] ? read_extent_buffer+0xc1/0x1a0 [btrfs] > [ 2369.940085] [] __btrfs_cow_block+0x11e/0x4d0 [btrfs] > [ 2369.946737] [] ? btrfs_tree_lock+0x161/0x2c0 [btrfs] > [ 2369.953391] [] btrfs_cow_block+0xea/0x200 [btrfs] > [ 2369.959756] [] btrfs_search_slot+0x31f/0x720 [btrfs] > [ 2369.966362] [] btrfs_del_csums+0x23b/0x320 [btrfs] > [ 2369.972833] [] __btrfs_free_extent+0x49b/0x720 [btrfs] > [ 2369.979660] [] run_delayed_data_ref+0x159/0x160 > [btrfs] > [ 2369.986591] [] run_one_delayed_ref+0xb0/0xd0 [btrfs] > [ 2369.993257] [] run_clustered_refs+0xcf/0x240 [btrfs] > [ 2369.28] [] btrfs_run_delayed_refs+0xd8/0x260 > [btrfs] > [ 2370.006937] [] btrfs_commit_transaction+0x87/0x8b0 > [btrfs] > [ 2370.014238] [] ? wake_up_bit+0x40/0x40 > [ 2370.019710] [] ? btrfs_commit_transaction+0x8b0/0x8b0 > [btrfs] > [ 2370.027180] [] do_async_commit+0x1f/0x30 [btrfs] > [ 2370.033578] [] ? btrfs_commit_transaction+0x8b0/0x8b0 > [btrfs] > [ 2370.041039] [] process_one_work+0x13f/0x490 > [ 2370.046950] [] worker_thread+0x187/0x3e0 > [ 2370.052679] [] ? manage_workers+0x120/0x120 > [ 2370.058682] [] kthread+0x96/0xa0 > [ 2370.063690] [] kernel_thread_helper+0x4/0x10 > [ 2370.069695] [] ? retint_restore_args+0xe/0xe > [ 2370.075720] [] ? kthread_worker_fn+0x1d0/0x1d0 > [ 2370.081919] [] ? gs_change+0xb/0xb > [ 2370.087103] ---[ end trace a6d5cd679d4e46b9 ]--- > > > I don't know if it matters, but I also see lots of this sort of thing: > > [ 2370.131721] btrfs: all snaps cleaned > [ 2370.241382] btrfs: btrfs_clean_old_snapshots to process 1 old snaps > [ 2370.275303] btrfs: btrfs_clean_old_snapshots to process 0 old snaps Harmless debugging of > [ 2370.275306] btrfs: all snaps cleaned > [ 2370.296461] btrfs: all snaps cleaned > [ 2370.639211] btrfs: btrfs_clean_old_snapshots to process 1 old snaps ... slow snapshot deletion reported by BCrook. > [ 2370.688785] btrfs: all snaps cleaned > [ 2370.811568] btrfs: journal_info set but trans not join/nolock: 0x1 ... btrfs/transaction.c:264 in start_transaction, but the patch was not correct and reported not only the WARN_ON case. Thanks for the report, I'll clean the branch a bit and move the debugging or too experimental stuff into a separate branch. david -- 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
