Re: [Jfs-discussion] benchmark results

2010-01-10 Thread Larry McVoy
On Sun, Jan 10, 2010 at 08:03:04PM -0500, Casey Allen Shobe wrote:
> On Dec 25, 2009, at 11:22 AM, Larry McVoy wrote:
>> Dudes, sync() doesn't flush the fs cache, you have to unmount for  
>> that.
>> Once upon a time Linux had an ioctl() to flush the fs buffers, I used
>> it in lmbench.
>
>
> You do not need to unmount - 2.6.16+ have a mechanism in /proc to flush 
> caches.  See http://linux-mm.org/Drop_Caches

Cool, but I tend to come at problems from a cross platform point of view.
Aix no hable /proc :)
-- 
---
Larry McVoylm at bitmover.com   http://www.bitkeeper.com
--
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: [Jfs-discussion] benchmark results

2010-01-10 Thread Casey Allen Shobe

On Dec 25, 2009, at 11:22 AM, Larry McVoy wrote:
Dudes, sync() doesn't flush the fs cache, you have to unmount for  
that.

Once upon a time Linux had an ioctl() to flush the fs buffers, I used
it in lmbench.



You do not need to unmount - 2.6.16+ have a mechanism in /proc to  
flush caches.  See http://linux-mm.org/Drop_Caches


Cheers,
--
Casey Allen Shobe
ca...@shobe.info

--
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: task imap:2958 blocked for more than 120 seconds

2010-01-10 Thread Chris Mason
On Sun, Jan 10, 2010 at 09:05:46PM +0100, Johannes Hirte wrote:
> I've observed this hanging task now several times. Not sure when this 
> started, 
> but 2.6.32 is affected too, IIRC. I don't have a test pattern for this. 
> Dovecot 
> imap triggers this from time to time. I've enabled CONFIG_DETECT_HUNG_TASK 
> now 
> and got this two tasks which hang:

You're stuck on a read, could you please do a sysrq-w when this happens?
Also, do you eventually recover or are you stuck forever?

-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: snapshot/subvolume removal

2010-01-10 Thread Chris Mason
On Fri, Jan 08, 2010 at 05:28:42PM +0900, TARUISI Hiroaki wrote:
> For now, subvolumes and snapshots look like just directories.
> If you want to distinguish them, there's only an unusual way,
> that is, analyzing with btrfs-debug-tree.
> 
> I posted patches for listing snapshots/subvolumes two months ago,
> and Josef Bacik posted its bugfix patch. This feature may be
> delivered in sooner or later.
> If you want to try it now, check these URLs.
>   http://patchwork.kernel.org/patch/60923/raw/
>   http://patchwork.kernel.org/patch/60920/raw/
>   http://patchwork.kernel.org/patch/67332/raw/
> Patches and requests are welcome.

Thanks again for the subvolume listing patch, it's going to be a great
feature.

I'm afraid I've had to make some small changes.  ioctls have
some very strict rules for the arguments, and pointers and list heads
should not be passed in ioctl structs.

We also need to change the patch to make the ioct args struct the same
size on both 32 bit and 64 bit machines, which usually just means
aligning and padding the fields as required.

I have started on this and hope to finish it on Tuesday.  But if you
have any additions to the patch please let me know.

-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


task imap:2958 blocked for more than 120 seconds

2010-01-10 Thread Johannes Hirte
I've observed this hanging task now several times. Not sure when this started, 
but 2.6.32 is affected too, IIRC. I don't have a test pattern for this. Dovecot 
imap triggers this from time to time. I've enabled CONFIG_DETECT_HUNG_TASK now 
and got this two tasks which hang:

INFO: task imap:2958 blocked for more than 120 seconds. 
   
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.   
   
imap  D  0  2958   2653 0x  
   
 88008caf5a28 0046  810544cf
   
 88008caf5998 0001 88008caf5fd8 88008caf9530
   
 de78 001d2700 001d2700 88008caf9530
   
Call Trace: 
   
 [] ? trace_hardirqs_off+0xd/0xf  
   
 [] ? trace_hardirqs_on_caller+0x10c/0x130
   
 [] ? sync_page+0x0/0x48  
   
 [] io_schedule+0x38/0x4d 
   
 [] sync_page+0x44/0x48   
   
 [] __wait_on_bit_lock+0x41/0x8a  
   
 [] __lock_page+0x61/0x68 
   
 [] ? wake_bit_function+0x0/0x2e  
   
 [] filemap_fault+0xea/0x345  
   
 [] __do_fault+0x50/0x3d3 
   
 [] handle_mm_fault+0x32f/0x65d   
   
 [] ? do_page_fault+0xf4/0x26f
   
 [] ? __down_read_trylock+0x46/0x4e   
   
 [] ? down_read_trylock+0x3f/0x49 
   
 [] ? do_page_fault+0xf4/0x26f
   
 [] do_page_fault+0x257/0x26f 
   
 [] page_fault+0x1f/0x30  
   
 [] ? might_fault+0x57/0xa7   
   
 [] ? btrfs_copy_from_user+0x4f/0x113 
   
 [] ? btrfs_copy_from_user+0xde/0x113 
   
 [] btrfs_file_write+0x439/0x6fe  
   
 [] vfs_write+0xad/0x14e  
   
 [] ? trace_hardirqs_on_caller+0x10c/0x130
   
 [] sys_pwrite64+0x55/0x74
   
 [] system_call_fastpath+0x16/0x1b
   
2 locks held by imap/2958:  
   
 #0:  (&sb->s_type->i_mutex_key#4){+.+.+.}, at: [] 
btrfs_file_write+0x169/0x6fe  
 #1:  (&mm->mmap_sem){++}, at: [] 
do_page_fault+0xf4/0x26f
   
INFO: task flush-btrfs-2:2783 blocked for more than 120 seconds.
   
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.