headers
bugzilla-daemon | 1 Aug 2010 16:14

[Bug 16233] Fwd: [2.6.34] INFO: task rsync:20019 blocked for more than 120 seconds.

https://bugzilla.kernel.org/show_bug.cgi?id=16233

Rafael J. Wysocki <rjw <at> sisk.pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INSUFFICIENT_DATA

--

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Aug 2010 16:14

[Bug 16233] Fwd: [2.6.34] INFO: task rsync:20019 blocked for more than 120 seconds.

https://bugzilla.kernel.org/show_bug.cgi?id=16233

Rafael J. Wysocki <rjw <at> sisk.pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Aug 2010 21:40

[Bug 16312] WARNING: at fs/fs-writeback.c:1127 __mark_inode_dirty

https://bugzilla.kernel.org/show_bug.cgi?id=16312

--- Comment #20 from Larry Finger <Larry.Finger <at> lwfinger.net>  2010-08-01 19:40:00 ---
The diagnostics patch from #12 did not change anything.

I am beginning to think that Bug 16312 is not the same as Bug 16122. Even with
the patches from 16312, I still get warnings as below:

[   11.728776] ------------[ cut here ]------------
[   11.728787] WARNING: at fs/fs-writeback.c:964
__mark_inode_dirty+0x10f/0x1a0()
[   11.728790] Hardware name: HP Pavilion dv2700 Notebook PC
[   11.728792] Modules linked in: loop(+) dm_mod ide_cd_mod cdrom
snd_hda_codec_conexant ide_pci_generic arc4 ecb b43 rng_core mac80211
snd_hda_intel r8712u(C) cfg80211 snd_hda_codec amd74xx snd_pcm sg ide_core
rfkill led_class snd_timer ssb mmc_core pcmcia snd joydev k8temp hwmon
i2c_nforce2 pcmcia_core forcedeth serio_raw snd_page_alloc i2c_core battery ac
button ext4 mbcache jbd2 crc16 ohci_hcd sd_mod ehci_hcd usbcore fan processor
ahci libahci libata scsi_mod thermal
[   11.728854] Pid: 2449, comm: udisks-part-id Tainted: G         C 
2.6.35-rc6-realtek+ #15
[   11.728857] Call Trace:
[   11.728865]  [<ffffffff8104608a>] warn_slowpath_common+0x7a/0xb0
[   11.728869]  [<ffffffff810460d5>] warn_slowpath_null+0x15/0x20
[   11.728874]  [<ffffffff81129d5f>] __mark_inode_dirty+0x10f/0x1a0
[   11.728879]  [<ffffffff8111e07d>] touch_atime+0x12d/0x170
[   11.728885]  [<ffffffff810cab91>] generic_file_aio_read+0x5c1/0x720
[   11.728890]  [<ffffffff81107ca2>] do_sync_read+0xd2/0x110
[   11.728896]  [<ffffffff81077e7d>] ? trace_hardirqs_on+0xd/0x10
[   11.728900]  [<ffffffff811083c3>] vfs_read+0xb3/0x170
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ted Ts'o | 1 Aug 2010 23:41
Picon
Picon
Favicon
Gravatar

Re: [PATCH] ext4: fix freeze deadlock under IO

On Wed, Jun 23, 2010 at 02:37:27PM -0500, Eric Sandeen wrote:
> Commit 6b0310fbf087ad6 caused a regression resulting in deadlocks
> when freezing a filesystem which had active IO; the vfs_check_frozen
> level (SB_FREEZE_WRITE) did not let the freeze-related IO syncing
> through.  Duh.
> 
> Changing the test to FREEZE_TRANS should let the normal freeze
> syncing get through the fs, but still block any transactions from
> starting once the fs is completely frozen.
> 
> I tested this by running fsstress in the background while periodically
> snapshotting the fs and running fsck on the result.  I ran into
> occasional deadlocks, but different ones.  I think this is a
> fine fix for the problem at hand, and the other deadlocky things
> will need more investigation.
> 
> Reported-by: Phillip Susi <psusi <at> cfl.rr.com>
> Signed-off-by: Eric Sandeen <sandeen <at> redhat.com>

Applied to the ext4 patch queue.  Sorry for missing this earier.

	       	    	  	  	    - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Ted Ts'o | 2 Aug 2010 01:02
Picon
Picon
Favicon
Gravatar

Re: ext4 performance regression 2.6.27-stable versus 2.6.32 and later

On Fri, Jul 30, 2010 at 11:01:36PM +0200, Kay Diederichs wrote:
> whereas for 2.6.32.16 the result is typically
> Filesystem type is: ef53
> File size of
> /mnt/md5/scratch/nfs-test/tmp/xds/frames/h2g28_1_00000.cbf is
> 6229688 (1521 blocks, blocksize 4096)
>  ext logical physical expected length flags
>    0       0 826376200            1521 eof
> /mnt/md5/scratch/nfs-test/tmp/xds/frames/h2g28_1_00000.cbf: 1 extent found

OK, so 2.6.32 is actually doing a better job laying out the files....

The blktrace will be interesting, but at this point I'm wondering if
this is a generic kernel-wide writeback regression.  At $WORK we've
noticed some performance regressions between 2.6.26-based kernels and
2.6.33- and 2.6.34-based kernels with both ext2 and ext4 (in no
journal mode) that we've been trying to track down.  We have a pretty
large number of patches applied to both 2.6.26 and 2.6.33/34 which is
why I haven't mentioned it up until now, but at this point it seems
pretty clear there are some writeback issues in the mainline kernel.

There are half a dozen or so patch series on LKML that are addressing
writeback in one way or another, and writeback is a major topic at the
upcoming Linux Storage and Filesystem workshop.  So if this is the
cause, hopefully there will be some improvements in this area in the
near future.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Theodore Ts'o | 2 Aug 2010 05:15
Picon
Picon
Favicon
Gravatar

[PATCH] ext4: Add mount options in superblock

Allow mount options to be stored in the superblock.  Also add default
mount option bits for nobarrier, block_validity, discard, and nodelalloc.

Signed-off-by: "Theodore Ts'o" <tytso <at> mit.edu>
---
 fs/ext4/ext4.h  |    9 +++++++--
 fs/ext4/super.c |   29 +++++++++++++++++++++++------
 2 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 9ca3637..ed14e1d 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
 <at>  <at>  -1025,8 +1025,9  <at>  <at>  struct ext4_super_block {
 	__le32	s_last_error_line;	/* line number where error happened */
 	__le64	s_last_error_block;	/* block involved of last error */
 	__u8	s_last_error_func[32];	/* function where the error happened */
-#define EXT4_S_ERR_END offsetof(struct ext4_super_block, s_reserved)
-	__le32   s_reserved[128];        /* Padding to the end of the block */
+#define EXT4_S_ERR_END offsetof(struct ext4_super_block, s_mount_opts)
+	__u8	s_mount_opts[64];
+	__le32	s_reserved[112];        /* Padding to the end of the block */
 };

 #define EXT4_S_ERR_LEN (EXT4_S_ERR_END - EXT4_S_ERR_START)
 <at>  <at>  -1341,6 +1342,10  <at>  <at>  EXT4_INODE_BIT_FNS(state, state_flags)
 #define EXT4_DEFM_JMODE_DATA	0x0020
 #define EXT4_DEFM_JMODE_ORDERED	0x0040
 #define EXT4_DEFM_JMODE_WBACK	0x0060
+#define EXT4_DEFM_NOBARRIER	0x0100
(Continue reading)

Permalink | Reply | 2 comments |
headers
Akira Fujita | 2 Aug 2010 07:10
Picon

Re: BUG? ext3: Allocate blocks over quota limit with mmap

Hi ext3 maintainers,

Could you look into this?
If this is not a problem, it is good though.

Regards,
Akira Fujita

(2010/07/29 11:08), Akira Fujita wrote:
> Hi,
> 
> I found a problem that user can allocate blocks over quota limitation
> on ext3 (and ext2) with mmap.
> You can reproduce this with the following steps:
> 
> 1. Enable user quota on ext3
>   [akira <at> bsd086 mnt]$ uname -r
>   2.6.35-rc6
> 
>   [root <at> bsd086 mnt]# cat /proc/mounts  | grep  /dev/sda9
>   /dev/sda9 /mnt/mp1 ext3 rw,relatime,errors=continue,barrier=0,data=ordered,usrquota 0 0
> 
>   [root <at> bsd086 mnt]# quotaon -p /mnt/mp1
>   group quota on /mnt/mp1 (/dev/sda9) is off
>   user quota on /mnt/mp1 (/dev/sda9) is on
> 
>   [root <at> bsd086 mnt]# repquota -v /mnt/mp1
>   *** Report for user quotas on device /dev/sda9
>   Block grace time: 7days; Inode grace time: 7days
>                           Block limits                File limits
(Continue reading)

Permalink | Reply | 5 comments |
headers
Dmitry Monakhov | 2 Aug 2010 07:22
Favicon
Gravatar

Re: BUG? ext3: Allocate blocks over quota limit with mmap

Akira Fujita <a-fujita <at> rs.jp.nec.com> writes:

> Hi ext3 maintainers,
>
> Could you look into this?
> If this is not a problem, it is good though.
Actually this is a problem. Because this issue makes quota just a fake
limit. I've done this test for ext4 and was satisfied with result,
but was too lazy to perform it on ext3/2 :(
At least we have to have testcase for that in xfstest-qa.
It seems that private page_mkwrite will be sufficient.
I'm working on that.
>
> Regards,
> Akira Fujita
>
>
> (2010/07/29 11:08), Akira Fujita wrote:
>> Hi,
>> 
>> I found a problem that user can allocate blocks over quota limitation
>> on ext3 (and ext2) with mmap.
>> You can reproduce this with the following steps:
>> 
>> 1. Enable user quota on ext3
>>   [akira <at> bsd086 mnt]$ uname -r
>>   2.6.35-rc6
>> 
>>   [root <at> bsd086 mnt]# cat /proc/mounts  | grep  /dev/sda9
>>   /dev/sda9 /mnt/mp1 ext3 rw,relatime,errors=continue,barrier=0,data=ordered,usrquota 0 0
(Continue reading)

Permalink | Reply | 3 comments |
headers
Akira Fujita | 2 Aug 2010 07:57
Picon

Re: BUG? ext3: Allocate blocks over quota limit with mmap

Hi Dmitry,

> It seems that private page_mkwrite will be sufficient.

Agree. This problem also breaks "reserved blocks count" semantics,
private page_mkwrite for ext2/3 will be necessary.
Thank you for working this on.

Regards,
Akira Fujita

(2010/08/02 14:22), Dmitry Monakhov wrote:
> Akira Fujita<a-fujita <at> rs.jp.nec.com>  writes:
> 
>> Hi ext3 maintainers,
>>
>> Could you look into this?
>> If this is not a problem, it is good though.
> Actually this is a problem. Because this issue makes quota just a fake
> limit. I've done this test for ext4 and was satisfied with result,
> but was too lazy to perform it on ext3/2 :(
> At least we have to have testcase for that in xfstest-qa.
> It seems that private page_mkwrite will be sufficient.
> I'm working on that.
>>
>> Regards,
>> Akira Fujita
>>
>>
>> (2010/07/29 11:08), Akira Fujita wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dieter Ries | 2 Aug 2010 09:02
Favicon

kjournald and flush being blocked for 120 sec

Hi there.

I recently got a new server, 4 x Opteron 6128 on a Supermicro H8QGi+-F
board, AMD SP5100 chipset, 3 S-ATA disks, one 500GB WD RE3 for system 
and 2 identical 2TB Hitachi for data.

Creating a MD Raid 1 on the 2 2TB drives took 4 days, and now when I dd
zeroes to a LVM Partitioni, ext3 fs, on the raid, performance ist good 
for the first ~4 GB, but then it gets horribly slow, sometimes stalls. 
In the end I get write rates of about 20MB/s, and this in dmesg:

[  484.128146] INFO: task kjournald:2496 blocked for more than 120 seconds.
[  484.128286] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  484.128420] kjournald     D 00000000ffffdaac     0  2496      2 0x00000000
[  484.128427]  ffff88022650c420 0000000000000046 ffff880625721800 0000000000000000
[  484.128431]  ffffffff81632020 0000000000015300 0000000000015300 0000000000015300
[  484.128435]  ffff880224431fd8 0000000000015300 ffff88022650c420 ffff880224431fd8
[  484.128439] Call Trace:
[  484.128452]  [<ffffffff8100f52e>] ? read_tsc+0x5/0x16
[  484.128459]  [<ffffffff81106a22>] ? sync_buffer+0x0/0x3f
[  484.128466]  [<ffffffff8136a3e8>] ? io_schedule+0x6b/0xaa
[  484.128469]  [<ffffffff81106a5d>] ? sync_buffer+0x3b/0x3f
[  484.128473]  [<ffffffff8136a931>] ? __wait_on_bit+0x3e/0x6f
[  484.128477]  [<ffffffff8136a9d0>] ? out_of_line_wait_on_bit+0x6e/0x77
[  484.128480]  [<ffffffff81106a22>] ? sync_buffer+0x0/0x3f
[  484.128486]  [<ffffffff8105cdeb>] ? wake_bit_function+0x0/0x2e
[  484.128489]  [<ffffffff811069bb>] ? wait_on_buffer+0xe/0x2d
[  484.128493]  [<ffffffff81106f4e>] ? sync_dirty_buffer+0x58/0x8f
[  484.128498]  [<ffffffff8115a254>] ? journal_commit_transaction+0xa8e/0xdee
[  484.128502]  [<ffffffff8105cdc1>] ? autoremove_wake_function+0x0/0x2a
(Continue reading)

Permalink | Reply | 1 comment |

Gmane