search for: wait_on_buffer

...2.000000000 +0900 @@ -92,7 +92,7 @@ struct buffer_head *wbuf[64]; int bufs; int flags; - int err; + int err = 0; unsigned long blocknr; char *tagp = NULL; journal_header_t *header; @@ -299,6 +299,8 @@ spin_unlock(&journal_datalist_lock); unlock_journal(journal); wait_on_buffer(bh); + if (unlikely(!buffer_uptodate(bh))) + err = -EIO; /* the journal_head may have been removed now */ lock_journal(journal); goto write_out_data; @@ -326,6 +328,8 @@ spin_unlock(&journal_datalist_lock); unlock_journal(journal); wait_on_buffer(bh); + if (...

...t oracle.com> -- Index: fs/ocfs2/super.c =================================================================== --- fs/ocfs2/super.c (revision 128) +++ fs/ocfs2/super.c (working copy) @@ -1203,6 +1203,12 @@ static int ocfs2_get_sector(struct super unlock_buffer(*bh); ll_rw_block(READ, 1, bh); wait_on_buffer(*bh); + if (!buffer_uptodate(*bh)) { + mlog_errno(-EIO); + brelse(*bh); + return -EIO; + } + return 0; }

...m> -- diff -up ./fs/ocfs2/super.c.orig ./fs/ocfs2/super.c --- ./fs/ocfs2/super.c.orig 2009-02-12 18:05:19.023685000 -0800 +++ ./fs/ocfs2/super.c 2009-02-12 18:07:13.995623000 -0800 @@ -1537,6 +1537,13 @@ static int ocfs2_get_sector(struct super unlock_buffer(*bh); ll_rw_block(READ, 1, bh); wait_on_buffer(*bh); + if (!buffer_uptodate(*bh)) { + mlog_errno(-EIO); + brelse(*bh); + *bh = NULL; + return -EIO; + } + return 0; }

...t oracle.com> -- Index: fs/ocfs2/super.c =================================================================== --- fs/ocfs2/super.c (revision 128) +++ fs/ocfs2/super.c (working copy) @@ -1203,6 +1203,11 @@ static int ocfs2_get_sector(struct super unlock_buffer(*bh); ll_rw_block(READ, 1, bh); wait_on_buffer(*bh); + if (!buffer_uptodate(*bh)) { + mlog_errno(-EIO); + return -EIO; + } + return 0; }

..., they seem to bottleneck at log_wait_common (according to ps alnx). That is, one process is uninterruptible in log_wait_common, the rest are uninterruptible in down. kjournald itself seems to be oftern blocked at 'wait_o', which I unfortunately didn't get as numeric, but I assume is wait_on_buffer or something like that. Is there a reason the data writes should be waiting on the log in ordered mode? I thought that log commits were postponed until the completion of data, but not vice-versa. I assume that data=writeback would alleviate this bottleneck, right? David -- /================...

An update of the ext3 journalling filesystem for 2.4 kernels is available at http://www.uow.edu.au/~andrewm/linux/ext3/ Patches are against 2.4.6-ac1 and 2.4.6. Changes since 0.0.8 include: - Multiplied the version numbering by ten to cater for bugfix releases against the 0.9.0 stream. - The main thrust has been the removal of a number of changes in the core kernel which were required

Hi, With kernel 2.4.10, when I do $ mkdir foo; cd foo; rmdir ../foo; ls then ls becomes zombie. $ ps xau|grep ls liu 596 0.0 0.0 148 88 ? D 12:03 0:00 ls This does not happen with 2.4.10 on an ext2 filesystem, nor with 2.4.9/ext3. The command cd instead of ls is OK. Distribution is Slackware 8.0 and the kernels are stock ones. Liu

Hi. I got following BUG trace. This is violation of BUG_ON(!buffer_locked(bh)) check on submit_bh() function. In write_dev_supers(), if wait parameter is set and buffer_uptodate() check is negative, submit_bh() is executed and hit above BUG_ON. So I fixed this issue. Thanks. Jun 9 00:41:32 dl580 kernel: ------------[ cut here ]------------ Jun 9 00:41:32 dl580 kernel: kernel BUG at

...n 10 14:50:23 mithrandir kernel: [40871.705579] [<ffffffff810781cc>] ? __delayacct_blkio_end+0x39/0x3b Jun 10 14:50:23 mithrandir kernel: [40871.705616] [<ffffffff81025a4e>] ? delayacct_blkio_end+0x1c/0x3c Jun 10 14:50:23 mithrandir kernel: [40871.705652] [<ffffffff810d2a0e>] ? wait_on_buffer+0x12/0x12 Jun 10 14:50:23 mithrandir kernel: [40871.705692] [<ffffffffa0d77d22>] run_clustered_refs+0x616/0x660 [btrfs] Jun 10 14:50:23 mithrandir kernel: [40871.705733] [<ffffffff81025042>] ? set_next_entity+0x3b/0x60 Jun 10 14:50:23 mithrandir kernel: [40871.705776] [<ffffffffa0...

The following 6 patches cleanup the jbd code and kill about 200 lines. First of 4 patches can apply to 2.6.13-git8 and 2.6.13-mm2. The rest of them can apply to 2.6.13-mm2. fs/jbd/checkpoint.c | 179 +++++++++++-------------------------------- fs/jbd/commit.c | 101 ++++++++++-------------- fs/jbd/journal.c | 11 +- fs/jbd/revoke.c | 158

...;(%lu, .., %llu, %u, %u, %d)\n", + page->index, OCFS2_I(inode)->ip_blkno, from, to, new); + if (!page_has_buffers(page)) create_empty_buffers(page, bsize, 0); @@ -842,12 +906,14 @@ int ocfs2_map_page_blocks(struct page *page, u64 *p_blkno, */ while(wait_bh > wait) { wait_on_buffer(*--wait_bh); - if (!buffer_uptodate(*wait_bh)) + if (!buffer_uptodate(*wait_bh)) { ret = -EIO; + mlog_errno(ret); + } } if (ret == 0 || !new) - return ret; + goto bail; /* * If we get -EIO above, zero out any newly allocated blocks @@ -871,6 +937,8 @@ next_bh: bh = bh-&gt...

...d)\n", + page->index, (unsigned long long)OCFS2_I(inode)->ip_blkno, + from, to, new); + if (!page_has_buffers(page)) create_empty_buffers(page, bsize, 0); @@ -842,12 +912,14 @@ int ocfs2_map_page_blocks(struct page *page, u64 *p_blkno, */ while(wait_bh > wait) { wait_on_buffer(*--wait_bh); - if (!buffer_uptodate(*wait_bh)) + if (!buffer_uptodate(*wait_bh)) { ret = -EIO; + mlog_errno(ret); + } } if (ret == 0 || !new) - return ret; + goto bail; /* * If we get -EIO above, zero out any newly allocated blocks @@ -871,6 +943,8 @@ next_bh: bh = bh-&gt...

...d)\n", + page->index, (unsigned long long)OCFS2_I(inode)->ip_blkno, + from, to, new); + if (!page_has_buffers(page)) create_empty_buffers(page, bsize, 0); @@ -842,12 +912,14 @@ int ocfs2_map_page_blocks(struct page *page, u64 *p_blkno, */ while(wait_bh > wait) { wait_on_buffer(*--wait_bh); - if (!buffer_uptodate(*wait_bh)) + if (!buffer_uptodate(*wait_bh)) { ret = -EIO; + mlog_errno(ret); + } } if (ret == 0 || !new) - return ret; + goto bail; /* * If we get -EIO above, zero out any newly allocated blocks @@ -871,6 +943,8 @@ next_bh: bh = bh-&gt...

Please review the list of patches being applied to the ocfs2 1.4 tree. All patches list the mainline commit hash. Thanks Sunil

The following series of patches attempts to detach metadata I/O from struct inode. They are currently tied together pretty tightly. Metadata reads happen via the ocfs2_read_blocks() functions, writes via both jbd2 and ocfs2_write_blocks(). - Each inode has a cache of associated metadata blocks stored on its ip_metadata_cache member. The ocfs2_read/write_blocks() functions take a struct