Re: Blocked tasks on 3.15.1

version. Just the partition with git, svn and rsync trees. Last night's test of 3.17-rc1 showed the problem with the first git pull, getting stuck reading FETCH_HEAD. All repos on that fs failed the same way. But rebooting back to 3.16.0 let everything work perfectly. -JimC -- James Cloo

Re: [3.16-rc1] BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u25:4:5189]

is mounted with noatime,compress. Interestingly, I also use btrfs /var/log, also with noatime,compress, but that one is fine. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of

Re: Likely mem leak in 3.7

I've extensively tested 2844a48706e5 (tip at the time I compiled) for the last few days and have been unable to reproduce. This bug appears to be fixed. Thanks. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To unsubscribe from this list: send the line "unsubscribe linux

Re: Likely mem leak in 3.7

3670008 1298323540176 So the missing ram is un used (2nd row totals 12047072). I tried creating and deleting a large (1G) file on an ext4 and the xfs partition; the ram moved from cached to free in top(1). Doing the same thing on a btrfs partition lost about 200M of ram. -JimC -- James Cloos

Likely mem leak in 3.7

1 is the first known bad. If there is anything that I missed, please let me know! -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- 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 should increase the hard-link in the same directory limit

iour is not limited to gnus. Many workflows use that idiom. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- 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/inode.c:2260!

(I take it balance is for multi-device applications? --help uses the singular 'the device' but the btrfs(8) man page uses the plural 'the devices') -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To unsubscribe from this list: send the line "unsubscribe linux-bt

kernel BUG at fs/btrfs/inode.c:2260!

]--- -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- 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

Df [Was: Re: Issues when volume is full]

the max possible number of inodes. Reporting that and iused would be helpful. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- 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: 2.6.33 high cpu usage

[.] __gconv_transform_utf8_internal 0.01% basename [kernel] [k] bprm_mm_init 0.01% basename [kernel] [k] radix_tree_lookup_slot # # (For a higher level overview, try: perf report --sort comm,dso) # -JimC -- James Cloos

Re: 2.6.33 high cpu usage

rors, checkouts and the like and because I have that backup.) I'll reply again once I have results. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- 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

2.6.33 high cpu usage

[kernel][k] tcp_v4_send_check 0.01% git [kernel][k] tcp_v4_rcv 0.01% git [kernel][k] _cond_resched 0.01% git [kernel][k] mutex_trylock # # (For a higher level overview, try: perf report --sort comm,dso) # -JimC -- James

Re: [Regression] Filesystem I/O is CPU-bound in rc7 and rc8

ssion here. Thanks! It looks like my report is a dup of bug 15328. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- 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: [Regression] Filesystem I/O is CPU-bound in rc7 and rc8

rrors Anyway, no, the p3m does not support PAT: [0.00] PAT not supported by CPU. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- 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: [Regression] Filesystem I/O is CPU-bound in rc7 and rc8

>>>>> "Mike" == Mike Fedyk writes: Mike> On Sat, Feb 13, 2010 at 7:11 PM, James Cloos wrote: >> Sometime between rc6 and rc7 all filesystem I/O started using 100% CPU, >> usually on the order of 60% sys, 40% user. >> >> I've tried thi

Re: [Regression] Filesystem I/O is CPU-bound in rc7 and rc8

>>>>> "Dave" == Dave Airlie writes: Dave> On Thu, Feb 18, 2010 at 6:04 AM, James Cloos wrote: >> While getting re-aquainted with perf, and after upgrading to the current >> version, I see that do_page_fault, unmap_vmas, get_page_from_freelist, >>

Re: [Regression] Filesystem I/O is CPU-bound in rc7 and rc8

don't see any commits in the rc6..rc7 timeframe which stand out as likely suspects. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More ma

Re: [Regression] Filesystem I/O is CPU-bound in rc7 and rc8

I forgot to say: # CONFIG_SMP is not set CONFIG_TREE_PREEMPT_RCU=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y # CONFIG_DEBUG_PREEMPT is not set # CONFIG_PREEMPT_TRACER is not set -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To unsubscribe

[Regression] Filesystem I/O is CPU-bound in rc7 and rc8

addressed this regression, but it persists in rc8. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- 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