gmane.comp.file-systems.ext4

BUG: scheduling while atomic: kswapd0/273/0x00000002

Aneesh Kumar K.V — 2008-12-01T15:26:56

Hi, With the latest patch queue i am getting the below error -aneesh BUG: scheduling while atomic: kswapd0/273/0x00000002 1 lock held by kswapd0/273: #0: (&ei->client_lock){----}, at: [] blkdev_releasepage+0x27/0x5a Modules linked in: autofs4 hidp rfkill input_polldev sbs sbshc battery ac parport_pc lp parport i6300esb i2c_i801 i2c_core tg3 libphy e752x_edac edac_core qla2xxx scsi_transport_fc dm_multipath dm_mirror dm_region_hash dm_log dm_mod loop xt_tcpudp ip6t_REJECT ipv6 ipt_REJECT x_tables sunrpc rfcomm bnep l2cap bluetooth bridge stp sg rtc_cmos rtc_core rtc_lib pcspkr button ata_piix libata mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd [last unloaded: ip_tables] Pid: 273, comm: kswapd0 Not tainted 2.6.28-rc6-autotest #1 Call Trace: [] __schedule_bug+0x5e/0x65 [] schedule+0x85/0x7db [] ? mark_held_locks+0x49/0x64 [] ? trace_hardirqs_on_caller+0xe0/0x101 [] ? trace_hardirqs_on+0xb/0xd

[PATCH -V5 RESEND] ext4: Use EXT4_GROUP_INFO_NEED_INIT_BIT during resize

Aneesh Kumar K.V — 2008-12-01T13:43:29

The new groups added during resize are flagged as need_init group. Make sure we properly initialize these groups. When we have block size < page size and we are adding new groups the page may still be marked uptodate even though we haven't initialized the group. While forcing the init of buddy cache we need to make sure other groups part of the same page of buddy cache is not using the cache. group_info->alloc_sem is added to ensure the same. FILENAME: aneesh-3-use_EXT4_GROUP_INFO_NEED_INIT_BIT-during-resize V5 changes: The change in this version is to make sure we we are adding new groups we don't have a parllel ext4_mb_init_cache happening on other groups which are part of the same page in buddy cache. We do that by taking write lock on the group_info alloc_sem semaphore. Signed-off-by: Aneesh Kumar K.V linux.vnet.ibm.com> Signed-off-by: "Theodore Ts'o" mit.edu> --- fs/ext4/balloc.c | 21 +++-- fs/ext4/ext4.h | 7 +- fs/ext4/mballoc.c | 261 ++++++++++++++++++++++++++++++++

[PATCH -V2 1/4] ext4: Use new buffer_head flag to check uninit group bitmaps initialization

Aneesh Kumar K.V — 2008-12-01T13:43:43

For uninit block group, the ondisk bitmap is not initialized. That implies we cannot depend on the uptodate flag on the bitmap buffer_head to find bitmap validity. Use a new buffer_head flag which would be set after we properly initialize the bitmap. This also prevent the initializing the uninit group bitmap initialization every time we do a ext4_read_block_bitmap. Signed-off-by: Aneesh Kumar K.V linux.vnet.ibm.com> --- fs/ext4/balloc.c | 25 +++++++++++++++++++++++-- fs/ext4/ext4.h | 18 ++++++++++++++++++ fs/ext4/ialloc.c | 24 ++++++++++++++++++++++-- fs/ext4/mballoc.c | 24 ++++++++++++++++++++++-- 4 files changed, 85 insertions(+), 6 deletions(-) diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c index 3cae4c6..c00023f 100644 --- a/fs/ext4/balloc.c +++ b/fs/ext4/balloc.c < at >< at > -320,20 +320,41 < at >< at > ext4_read_block_bitmap(struct super_block *sb, ext4_group_t block_group) block_group, bitmap_blk); return NULL; } -if (buffer_uptodate(bh) && - !(desc->bg_flags & cpu_t

[PATCH]ext4: fix s_dirty_blocks_counter if block allocation failed with nodelalloc

Akira Fujita — 2008-12-01T10:21:54

ext4: Fix s_dirty_blocks_counter if block allocation failed with nodelalloc From: Akira Fujita rs.jp.nec.com> If block allocation failed after marking claimed blocks as dirty blocks with nodelalloc, we have to subtract these blocks from s_dirty_blocks_counter in error handling. Otherwise s_dirty_blocks_counter goes wrong so that filesystem's free blocks decreases incorrectly. This issue was reported as ext4 online defrag's bug by Li Zefan. http://marc.info/?l=linux-ext4&m=122697235715170&w=2 Reported-by: Li Zefan cn.fujitsu.com> Signed-off-by: Akira Fujita rs.jp.nec.com> --- mballoc.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff -X linux-2.6.28-rc6-ext4/Documentation/dontdiff -upNr linux-2.6.28-rc6-ext4/fs/ext4/mballoc.c linux-2.6.28-rc6-mballoc-fix/fs/ext4/mballoc.c --- linux-2.6.28-rc6-ext4/fs/ext4/mballoc.c2008-12-01 11:44:28.000000000 +0900 +++ linux-2.6.28-rc6-mballoc-fix/fs/ext4/mballoc.c2008-12-01 12:04:06.000000000 +0900 < at >< at > -4495,12 +4495,18 < at >< at > ext4_fsblk_t

kernel BUG at fs/ext4/extents.c:ext4_ext_search_right()

Zhang Xiliang — 2008-12-01T02:10:40

My test kernel is: 2.6.27 Hardware Environment: x86 or EM64T I put stress on ext4 device by using the script. After waiting some times, kernel brings up I/O error as follows: RHEL5 kernel: EXT4-fs error (device hda3): ext4_ext_search_right: bad header in inode #575041: unexpected eh_depth - magic f30a, entries 15, max 84(0), depth 1(2) If using "sync" command at the time, the command will not be finished. The kernel message as follows: INFO: task sync:16199 blocked for more than 120 seconds.et: Discarding datagram "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. d5bb2dc0 00000046 00000001 00000000 c04363d5 d5a6a360 d5a6a5b8 c2498080 00000001 c223c8e0 c223c8d0 00000246 ffffffff 00000046 00000000 00000000 00000000 f6598f10 00000000 f6598f18 c223c8d0 c048c021 c06544e8 c048c01c Call Trace: [] prepare_to_wait+0x12/0x42 [] inode_wait+0x5/0x8 [] __wait_on_bit+0x33/0x58 [] inode_wait+0x0/0x8 [] __writ

EXT4 ENOSPC Bug

Andres Freund — 2008-11-29T13:18:19

Hi Ted, Hi Andreas, hi all, On a testsystem (spare laptop) with ext4 as root filesystem sometimes the system starts to return ENOSPC to all write/create syscalls. Sometimes the system runs without problems, at other times it starts having problems soon after boot. A reboot resolves the problem temporarily. I don't see a specific usage triggering the problem. Deleting some files sometimes allows the creation (just touch $unused_filename) of some files, but not many. Anything I can do to help you to debug the problem? Andres Kernel is: 2.6.28-rc6-andres-00007-ged31348 # df / Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/root_crypt 302855628 110032848 192822780 37% / # df -i / Filesystem Inodes IUsed IFree IUse% Mounted on /dev/mapper/root_crypt 19234816 786691 18448125 5% / # tune2fs -l /dev/mapper/root_crypt tune2fs 1.41.3 (12-Oct-2008) Filesystem volume name: root Last mounted on:

[RFC][PATCH] "tune2fs -I 256" speedup

Andreas Schultz — 2008-11-29T10:54:19

Hi, After some on and off list discussion about the 'tune2fs -I' performance, Theodore Tso pointed out that the blk_move_list used by transalate_block() was less then optimal. This is my attempt at fixing that. Have fun Andreas

[PATCH] ext3: also fix loop in do_split()

roel kluin — 2008-11-29T09:40:42

unsigned i >= 0 is always true Signed-off-by: Roel Kluin gmail.com> --- diff --git a/fs/ext3/namei.c b/fs/ext3/namei.c index 3e5edc9..8f5e15d 100644 --- a/fs/ext3/namei.c +++ b/fs/ext3/namei.c < at >< at > -1188,7 +1188,7 < at >< at > static struct ext3_dir_entry_2 *do_split(handle_t *handle, struct inode *dir, /* Split the existing block in the middle, size-wise */ size = 0; move = 0; -for (i = count-1; i >= 0; i--) { +for (i = count-1; i < count; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break; -- 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

[PATCH] ext4: fix loop in do_split()

roel kluin — 2008-11-29T09:36:52

unsigned i >= 0 is always true Signed-off-by: Roel Kluin gmail.com> --- diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index 63adcb7..389cf60 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c < at >< at > -1198,7 +1198,7 < at >< at > static struct ext4_dir_entry_2 *do_split(handle_t *handle, struct inode *dir, /* Split the existing block in the middle, size-wise */ size = 0; move = 0; -for (i = count-1; i >= 0; i--) { +for (i = count-1; i < count; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break; -- 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

- ext3-use-sb_any_quota_loaded-instead-of-sb_any_quota_enabled.patch removed from -mm tree

2008-11-26T20:27:15

The patch titled ext3: use sb_any_quota_loaded() instead of sb_any_quota_enabled() has been removed from the -mm tree. Its filename was ext3-use-sb_any_quota_loaded-instead-of-sb_any_quota_enabled.patch This patch was dropped because an updated version will be merged The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ ------------------------------------------------------ Subject: ext3: use sb_any_quota_loaded() instead of sb_any_quota_enabled() From: Jan Kara suse.cz> Cc: vger.kernel.org> Signed-off-by: Jan Kara suse.cz> Signed-off-by: Andrew Morton linux-foundation.org> --- fs/ext3/super.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff -puN fs/ext3/super.c~ext3-use-sb_any_quota_loaded-instead-of-sb_any_quota_enabled fs/ext3/super.c --- a/fs/ext3/super.c~ext3-use-sb_any_quota_loaded-instead-of-sb_any_quota_enabled +++ a/fs/ext3/super.c < at >< at > -1035,8 +1035,7 < at >< at > static int parse_options (char *options, case Opt

- ext4-use-sb_any_quota_loaded-instead-of-sb_any_quota_enabled.patch removed from -mm tree

2008-11-26T20:27:17

The patch titled ext4: use sb_any_quota_loaded() instead of sb_any_quota_enabled() has been removed from the -mm tree. Its filename was ext4-use-sb_any_quota_loaded-instead-of-sb_any_quota_enabled.patch This patch was dropped because an updated version will be merged The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ ------------------------------------------------------ Subject: ext4: use sb_any_quota_loaded() instead of sb_any_quota_enabled() From: Jan Kara suse.cz> Cc: vger.kernel.org> Signed-off-by: Jan Kara suse.cz> Signed-off-by: Andrew Morton linux-foundation.org> --- fs/ext4/super.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff -puN fs/ext4/super.c~ext4-use-sb_any_quota_loaded-instead-of-sb_any_quota_enabled fs/ext4/super.c --- a/fs/ext4/super.c~ext4-use-sb_any_quota_loaded-instead-of-sb_any_quota_enabled +++ a/fs/ext4/super.c < at >< at > -1142,8 +1142,7 < at >< at > static int parse_options(char *options, case Opt_

[PATCH -V1] ext4: Use new buffer_head flag to check uninit group bitmaps initialization

Aneesh Kumar K.V — 2008-11-26T14:54:10

For uninit block group, the ondisk bitmap is not initialized. That implies we cannot depend on the uptodate flag on the bitmap buffer_head to find bitmap validity. Use a new buffer_head flag which would be set after we properly initialize the bitmap. This also prevent the initializing the uninit group bitmap initialization every time we do a ext4_read_block_bitmap. Signed-off-by: Aneesh Kumar K.V linux.vnet.ibm.com> --- fs/ext4/balloc.c | 16 ++++++++++++++-- fs/ext4/ext4.h | 18 ++++++++++++++++++ fs/ext4/ialloc.c | 15 +++++++++++++-- fs/ext4/mballoc.c | 15 +++++++++++++-- include/linux/jbd2.h | 1 + 5 files changed, 59 insertions(+), 6 deletions(-) diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c index 3cae4c6..b96e49a 100644 --- a/fs/ext4/balloc.c +++ b/fs/ext4/balloc.c < at >< at > -320,20 +320,32 < at >< at > ext4_read_block_bitmap(struct super_block *sb, ext4_group_t block_group) block_group, bitmap_blk); return NULL; } -if (buffer_uptodate(bh) && - !(desc->

[PATCH -V5] ext4: Use EXT4_GROUP_INFO_NEED_INIT_BIT during resize

Aneesh Kumar K.V — 2008-11-26T14:51:10

The new groups added during resize are flagged as need_init group. Make sure we properly initialize these groups. When we have block size < page size and we are adding new groups the page may still be marked uptodate even though we haven't initialized the group. While forcing the init of buddy cache we need to make sure other groups part of the same page of buddy cache is not using the cache. group_info->alloc_sem is added to ensure the same. FILENAME: aneesh-3-use_EXT4_GROUP_INFO_NEED_INIT_BIT-during-resize V5 changes: The change in this version is to make sure we we are adding new groups we don't have a parllel ext4_mb_init_cache happening on other groups which are part of the same page in buddy cache. We do that by taking write lock on the group_info alloc_sem semaphore. Need review on the usage of smp_wmb in ext4_group_add now that we are updating the group count with alloc_sem held. Signed-off-by: Aneesh Kumar K.V linux.vnet.ibm.com> Signed-off-by: "Theodore Ts'o" mit.edu> --- fs

jbd commit data buffers EIO error

Mingming Cao — 2008-11-26T00:18:05

Eric and I are looking at an EIO error in journal_submit_data_buffers() in commit.c If the buffer is unlocked and not dirty, journal_submit_data_buffers() would assume someboday else (pdflush) would already flushed the dirty data to disk. Now it checks the buffer's uptodate bit, try to catch the disk IO if the buffer is submitted by pdflush. This behavior is introduced with http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=cbe5f466f6995e10a10c7ae66d6dc8608f08a6b8 We consistantly hit this EIO on blocksize

[PATCH -V4 1/2] ext4: Use EXT4_GROUP_INFO_NEED_INIT_BIT during resize

Aneesh Kumar K.V — 2008-11-25T19:25:44

The new groups added during resize are flagged as need_init group. Make sure we properly initialize these groups. When we have block size < page size and we are adding new groups the page may still be marked uptodate even though we haven't initialized the group. While forcing the init of buddy cache we need to make sure other groups part of the same page of buddy cache is not using the cache. group_info->alloc_sem is added to ensure the same. FILENAME: aneesh-3-use_EXT4_GROUP_INFO_NEED_INIT_BIT-during-resize Signed-off-by: Aneesh Kumar K.V linux.vnet.ibm.com> Signed-off-by: "Theodore Ts'o" mit.edu> --- fs/ext4/balloc.c | 21 +++-- fs/ext4/ext4.h | 2 +- fs/ext4/mballoc.c | 217 ++++++++++++++++++++++++++++++++++++++-------------- fs/ext4/mballoc.h | 3 + fs/ext4/resize.c | 41 +---------- 5 files changed, 176 insertions(+), 108 deletions(-) diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c index fa69cb3..39df492 100644 --- a/fs/ext4/balloc.c +++ b/fs/ext4/balloc.c < at >< at > -

[PATCH -V3] ext4: Fix race between read_block_bitmap() and mark_diskspace_used()

Aneesh Kumar K.V — 2008-11-25T16:32:18

We need to make sure we update the block bitmap and clear EXT4_BG_BLOCK_UNINIT flag with sb_bgl_lock held. We look at EXT4_BG_BLOCK_UNINIT and reinit the block bitmap each time in ext4_read_block_bitmap (introduced by commit c806e68f), and this can race with block allocations in ext4_mb_mark_diskspace_used(). ext4_read_block_bitmap does: spin_lock(sb_bgl_lock(EXT4_SB(sb), block_group)); if (desc->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) { ext4_init_block_bitmap(sb, bh, block_group, desc); Now on the block allocation side we do mb_set_bits(sb_bgl_lock(sbi, ac->ac_b_ex.fe_group), bitmap_bh->b_data, ac->ac_b_ex.fe_start, ac->ac_b_ex.fe_len); .... spin_lock(sb_bgl_lock(sbi, ac->ac_b_ex.fe_group)); if (gdp->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) { gdp->bg_flags &= cpu_to_le16(~EXT4_BG_BLOCK_UNINIT); ie on allocation we update the bitmap then we take the sb_bgl_lock and clear the EXT4_BG_BLOCK_UNINIT flag. What can happen is a parallel ext4_read_block_bitmap can zero out the bitmap in betwee

[PATCH -V3] ext4: Fix the race between read_inode_bitmap() and ext4_new_inode()

Aneesh Kumar K.V — 2008-11-25T16:33:41

We need to make sure we update the inode bitmap and clear EXT4_BG_INODE_UNINIT flag with sb_bgl_lock held. We look at EXT4_BG_INODE_UNINIT and reinit the inode bitmap each time in ext4_read_inode_bitmap (introduced by c806e68f5647109350ec546fee5b526962970fd2 ) ext4_read_inode_bitmap does: spin_lock(sb_bgl_lock(EXT4_SB(sb), block_group)); if (desc->bg_flags & cpu_to_le16(EXT4_BG_INODE_UNINIT)) { ext4_init_inode_bitmap(sb, bh, block_group, desc); and ext4_new_inode does if (!ext4_set_bit_atomic(sb_bgl_lock(sbi, group), ino, inode_bitmap_bh->b_data)) ...... ... spin_lock(sb_bgl_lock(sbi, group)); gdp->bg_flags &= cpu_to_le16(~EXT4_BG_INODE_UNINIT); ie,on allocation we update the bitmap then we take the sb_bgl_lock and clear the EXT4_BG_INODE_UNINIT flag. What can happen is a parallel ext4_read_inode_bitmap can zero out the bitmap in between the above ext4_set_bit_atomic and spin_lock(sb_bg_lock..) The race results in below user visible errors EXT4-fs error (device sdb1): ext4_

[PATCH -V3] ext4: code cleanup

Aneesh Kumar K.V — 2008-11-25T16:33:16

rename some variables . We also unlock locks in the reverse order we acquired as a part of cleanup. FILENAME: In between use-high-16-bits-of-bg-free-counts fix-race-between-read_inode_bitmap-and-ext4_new_inode Signed-off-by: Aneesh Kumar K.V linux.vnet.ibm.com> --- fs/ext4/balloc.c | 2 +- fs/ext4/ialloc.c | 63 ++++++++++++++++++++++++++++------------------------ fs/ext4/mballoc.c | 2 +- 3 files changed, 36 insertions(+), 31 deletions(-) diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c index 8dd7b0d..3cae4c6 100644 --- a/fs/ext4/balloc.c +++ b/fs/ext4/balloc.c < at >< at > -329,8 +329,8 < at >< at > ext4_read_block_bitmap(struct super_block *sb, ext4_group_t block_group) if (desc->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) { ext4_init_block_bitmap(sb, bh, block_group, desc); set_buffer_uptodate(bh); -unlock_buffer(bh); spin_unlock(sb_bgl_lock(EXT4_SB(sb), block_group)); +unlock_buffer(bh); return bh; } spin_unlock(sb_bgl_lock(EXT4_SB(sb), block_group)); diff --git a/fs/ext

[PATCH -V3] ext4: Use high 16 bits of the block group descriptor's free counts fields

Aneesh Kumar K.V — 2008-11-25T16:32:59

Rename the lower bits with suffix _lo and add helper to access the values. Also rename bg_itable_unused_hi to bg_pad as in e2fsprogs. FILENAME: use-high-16-bits-of-bg-free-counts Signed-off-by: Aneesh Kumar K.V linux.vnet.ibm.com> --- fs/ext4/balloc.c | 13 ++++---- fs/ext4/ext4.h | 26 +++++++++++++--- fs/ext4/ialloc.c | 83 ++++++++++++++++++++++++++++------------------------- fs/ext4/inode.c | 2 +- fs/ext4/mballoc.c | 15 +++++---- fs/ext4/resize.c | 4 +- fs/ext4/super.c | 68 ++++++++++++++++++++++++++++++++++++++++++- 7 files changed, 149 insertions(+), 62 deletions(-) diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c index 39df492..8dd7b0d 100644 --- a/fs/ext4/balloc.c +++ b/fs/ext4/balloc.c < at >< at > -102,9 +102,9 < at >< at > unsigned ext4_init_block_bitmap(struct super_block *sb, struct buffer_head *bh, if (!ext4_group_desc_csum_verify(sbi, block_group, gdp)) { ext4_error(sb, __func__, "Checksum bad for group %u\n", block_group); -gdp->bg_free_blocks_coun

PART TIME REPRESENTATIVE POSITION NEEDED !!!

James Lee — 2008-11-24T23:48:25

Dear Sir/Ma., Lemmens crane system is an European and African Invented Company,but has a Standardized branch here in Singapore .We Buy, Produce and Distribute Constructing materials such as Crawler Cranes, Mechanical Crane and Marine Equipment Worldwide, you can check out our European branch website (www.lemmens-group.com ). We have reached big sales volume of Constructing Materials in Europe,Africa and the United Kingdom and now are trying to penetrate the USA/Canada market. Quite soon we will open representative offices or authorized sales centers in the USA/Canada and therefore we are currently looking for people who will assist us in establishing a new distribution! Network there. The fact is that despite the USA/Canada market is new for us we already have regular clients also speaks for itself. WHAT YOU NEED TO DO FOR US ? But we have a problem that's setting us back. We have some problem collecting our payments from our USA/Canada clients.. The international money transfer tax for leg

PATCH ext4: fix to call_filldir

Curt Wohlgemuth — 2008-11-24T18:21:05

[ Sorry: I mistakenly sent just the patch, with no explanation... ] I happened to find a bug running bonnie++-1.03a on an ext4 filesystem, when it complained about not being able to remove a file. Further investigation showed a problem with call_filldir(), which is not quite correct with respect to the same function in fs/ext3/dir.c. The patch below fixes this problem. Signed-off-by: Curt Wohlgemuth google.com> --- diff -Naur ext4/fs/ext4/dir.c b/fs/ext4/dir.c --- ext4/fs/ext4/dir.c2008-11-13 14:51:58.000000000 -0800 +++ b/fs/ext4/dir.c2008-11-24 08:23:05.000000000 -0800 < at >< at > -417,7 +417,7 < at >< at > get_dtype(sb, fname->file_type)); if (error) { filp->f_pos = curr_pos; -info->extra_fname = fname; +info->extra_fname = fname->next; return error; } fname = fname->next; -- 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