search for: ll_rw_block

...17, stackpage=c7bed000) Stack: c02591c6 c025943a 00000462 00001000 00000002 c3d3a9c0 c01327fa c3d3a9c0 c01a6a87 c3d3a9c0 c3e05ec0 c3e36d20 c3d2720c c7bedfc8 00001000 00000002 c7bec000 00000003 c7bedfc8 c0105ba6 c0105d88 c017ed2c 00000001 00000040 Call Trace: [refile_buffer+10/16] [ll_rw_block+423/624] [__up+22/32] [__up_wakeup+8/16] [journal_commit_transaction+4412/9456] [kjournald+267/464] [commit_timeout+0/16] [kernel_thread+40/64] Code: 0f 0b 83 c4 0c 31 f6 f6 43 1b 40 0f 84 bc 01 00 00 83 7b 40 VFS: Disk change detected on device fd(2,0) Assertion failure in __refile_buff...

Currently, some new storage devices have the ability to do performance optimizations according to the type of data payload - say, file system metadata, time-stamps, sequential write in some granularity, random write and so on. For example, the latest eMMC 4.5 device can support the so-called ''Context Management'' and ''Data Tag Mechanism'' features. By receiving

...ang wang <wen.gang.wang at 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; }

...t;wen.gang.wang at oracle.com> -- 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; }

...blk_slow+24/224] __getblk_slow+0x18/0xe0 Dec 11 04:03:56 fendrian kernel: [__getblk+42/48] __getblk+0x2a/0x30 Dec 11 04:03:56 fendrian kernel: [ext3_getblk+123/528] ext3_getblk+0x7b/0x210 Dec 11 04:03:56 fendrian kernel: [submit_bio+61/112] submit_bio+0x3d/0x70 Dec 11 04:03:56 fendrian kernel: [ll_rw_block+88/128] ll_rw_block+0x58/0x80 Dec 11 04:03:56 fendrian kernel: [ext3_find_entry+288/976] ext3_find_entry+0x120/0x3d0 Dec 11 04:03:56 fendrian kernel: [ext3_lookup+41/160] ext3_lookup+0x29/0xa0 Dec 11 04:03:56 fendrian kernel: [__lookup_hash+108/160] __lookup_hash+0x6c/0xa0 Dec 11 04:03:56 fendri...

...ang wang <wen.gang.wang at 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; }

Hi, ext3-0.0.6a has been uploaded to ftp.uk.linux.org:/pub/linux/sct/fs/jfs/ext3-0.0.6a.tar.gz and ftp.*.kernel.org:/pub/linux/kernel/people/sct/ext3/ext3-0.0.6a.tar.gz This version changes the way dirty buffers are marked to protect against device drivers which might block in the ll_rw_block() function. (Loop and lvm are examples.) It should also fix a rare but persistent report of "buffer already locked" failures. Other, more minor fixes include fixing the typo which reversed the behaviour of ordered and writeback data modes in 0.0.5e, and a couple of fixes for truncates...

...tion+4b/80> Trace; c011b9b1 <tasklet_hi_action+61/a0> Trace; c011b73b <do_softirq+6b/d0> Trace; c0108b6d <do_IRQ+dd/f0> Trace; c01bed9a <generic_make_request+10a/120> Trace; c013a636 <__refile_buffer+56/60> Trace; c01bedfd <submit_bh+4d/70> Trace; c01bef97 <ll_rw_block+177/1c0> Trace; c016e4fd <journal_brelse_array+1d/30> Trace; c016d65b <journal_commit_transaction+3ab/10f2> Trace; c02227c9 <netif_rx+a9/1d0> Trace; c021eb2f <alloc_skb+ef/1c0> Trace; c01c5cd7 <receive_packet+2c7/3e0> Trace; c0170236 <kjournald+136/200> Trace;...

..._bit+0x41/0x70 [ 4660.188529] [<ffffffff810cc6ba>] ? unmap_underlying_metadata+0x29/0x29 [ 4660.188533] [<ffffffff81333adc>] ? out_of_line_wait_on_bit+0x6b/0x77 [ 4660.188537] [<ffffffff81043413>] ? autoremove_wake_function+0x2e/0x2e [ 4660.188541] [<ffffffff810cc788>] ? ll_rw_block+0x65/0x82 [ 4660.188545] [<ffffffff81105592>] ? ext3_bread+0x49/0x68 [ 4660.188548] [<ffffffff8110a302>] ? htree_dirblock_to_tree+0x33/0x126 [ 4660.188552] [<ffffffff8110a46e>] ? ext3_htree_fill_tree+0x79/0x1d3 [ 4660.188557] [<ffffffff810b5cb7>] ? do_last+0x527/0x59e [...

...hich I couldn't find a use for in 2.4. In 2.2, these were set in ext3_new_block() when we do a getblk() on the new block. In 2.4, we don't do the getblk() any more... - Some tightening of the way commit feeds buffers into the request queues. At present, 256 buffers are fed into ll_rw_block() before we run tq_disk. I *was* pushing thousands down. It doesn't seem to make much difference. Overall throughput with some benchmarks in ordered data mode has been significantly improved by this change. ext3 in general seems faster in 2.4 than in 2.2, presumably because of bette...

Red Hat 2.2.19-6.2.12 + 0.0.7a + https://listman.redhat.com/pipermail/ext3-users/2001-November/002258.html (not tuned in /proc yet) + journal 4MB on each fs + 6 ext3 fs on raid1 (hda+hdc) + 1 ext3 fs on another disk not on raid1 (hdd) While untarring (tar zxf) a file that was on a ext3/raid1 onto hdd I got: ksymoops 2.3.4 on i686 2.2.19-6.2.12.g1. Options used -V (default) -k

...et_str = "WRITE_BARRIER"; + break; + default: + ret_str = "0"; + } + return ret_str; +} + static int dispatch_rw_block_io(blkif_t *blkif, blkif_request_t *req, - pending_req_t *pending_req) + pending_req_t *pending_req, + int *done_nr_sects) { extern void ll_rw_block(int rw, int nr, struct buffer_head * bhs[]); struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST]; @@ -426,6 +495,9 @@ static int dispatch_rw_block_io(blkif_t struct bio *bio = NULL; int ret, i; int operation; + struct timeval cur_time; + + *done_nr_sects = 0; switch (req-&gt...

...et_str = "WRITE_BARRIER"; + break; + default: + ret_str = "0"; + } + return ret_str; +} + static int dispatch_rw_block_io(blkif_t *blkif, blkif_request_t *req, - pending_req_t *pending_req) + pending_req_t *pending_req, + int *done_nr_sects) { extern void ll_rw_block(int rw, int nr, struct buffer_head * bhs[]); struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST]; @@ -426,6 +495,9 @@ static int dispatch_rw_block_io(blkif_t struct bio *bio = NULL; int ret, i; int operation; + struct timeval cur_time; + + *done_nr_sects = 0; switch (req-&gt...

...Trace; fffffc00004ab950 <md_make_request+90/120> Trace; fffffc0000355ba0 <end_buffer_io_sync+0/80> Trace; fffffc0000392abc <ext3_bread+1c/e0> Trace; fffffc000043fba4 <generic_make_request+204/240> Trace; fffffc000043fcac <submit_bh+cc/1e0> Trace; fffffc000044000c <ll_rw_block+24c/320> Trace; fffffc0000355ba0 <end_buffer_io_sync+0/80> Trace; fffffc0000392b04 <ext3_bread+64/e0> Trace; fffffc000036b5e0 <filldir64+0/1c0> Trace; fffffc000038ee28 <ext3_readdir+a8/4c0> Trace; fffffc000036ac28 <vfs_readdir+e8/1c0> Trace; fffffc000036b5e0 <fil...

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