search for: generic_write_sync

Adding linux-btrfs to Cc. Am Freitag, 27. Januar 2012 schrieb Jeff Moyer: > Hi, Hi, > As it stands, generic_file_aio_write will call into generic_write_sync > when -EIOCBQUEUED is returned from __generic_file_aio_write. > EIOCBQUEUED indicates that an I/O was submitted but NOT completed. > Thus, we will flush the disk cache, potentially before the write(s) > even make it to the disk! Up until now, this has been the best we > could do,...

...ff81389e7e>] write_ctree_super+0xe/0x10 [370517.206119]  [<ffffffff813c24b4>] btrfs_sync_log+0x424/0x5c0 [370517.206190]  [<ffffffff8139e9cb>] btrfs_sync_file+0x17b/0x1e0 [370517.206260]  [<ffffffff81160703>] vfs_fsync_range+0x23/0x30 [370517.206329]  [<ffffffff8116076c>] generic_write_sync+0x3c/0x40 [370517.206399]  [<ffffffff8139f4a7>] btrfs_file_aio_write+0x317/0x530 [370517.206472]  [<ffffffff8113556a>] do_sync_write+0xda/0x120 [370517.206544]  [<ffffffff8110037f>] ? handle_mm_fault+0x1af/0x320 [370517.206614]  [<ffffffff81135ab8>] vfs_write+0xc8/0x190 [370...

...e+0x29/0x70 > [11279.501390] [<ffffffffc060e388>] _xfs_log_force_lsn+0x2e8/0x340 [xfs] > [11279.501396] [<ffffffffb92cf1b0>] ? wake_up_state+0x20/0x20 > [11279.501428] [<ffffffffc05eeb97>] xfs_file_fsync+0x107/0x1e0 [xfs] > [11279.501432] [<ffffffffb944ef3f>] generic_write_sync+0x4f/0x70 > [11279.501461] [<ffffffffc05f0545>] xfs_file_aio_write+0x155/0x1b0 [xfs] > [11279.501466] [<ffffffffb941a533>] do_sync_write+0x93/0xe0 > [11279.501471] [<ffffffffb941b010>] vfs_write+0xc0/0x1f0 > [11279.501475] [<ffffffffb941c002>] SyS_pwrite64+0x...

...501390] [<ffffffffc060e388>] _xfs_log_force_lsn+0x2e8/0x340 [xfs] >>> [11279.501396] [<ffffffffb92cf1b0>] ? wake_up_state+0x20/0x20 >>> [11279.501428] [<ffffffffc05eeb97>] xfs_file_fsync+0x107/0x1e0 [xfs] >>> [11279.501432] [<ffffffffb944ef3f>] generic_write_sync+0x4f/0x70 >>> [11279.501461] [<ffffffffc05f0545>] xfs_file_aio_write+0x155/0x1b0 [xfs] >>> [11279.501466] [<ffffffffb941a533>] do_sync_write+0x93/0xe0 >>> [11279.501471] [<ffffffffb941b010>] vfs_write+0xc0/0x1f0 >>> [11279.501475] [<fffff...

...force_lsn+0x2e8/0x340 >>>>> [xfs] >>>>> [11279.501396] [<ffffffffb92cf1b0>] ? wake_up_state+0x20/0x20 >>>>> [11279.501428] [<ffffffffc05eeb97>] xfs_file_fsync+0x107/0x1e0 [xfs] >>>>> [11279.501432] [<ffffffffb944ef3f>] generic_write_sync+0x4f/0x70 >>>>> [11279.501461] [<ffffffffc05f0545>] xfs_file_aio_write+0x155/0x1b0 >>>>> [xfs] >>>>> [11279.501466] [<ffffffffb941a533>] do_sync_write+0x93/0xe0 >>>>> [11279.501471] [<ffffffffb941b010>] vfs_write+0xc0/...

...8>] _xfs_log_force_lsn+0x2e8/0x340 >>>> [xfs] >>>> [11279.501396] [<ffffffffb92cf1b0>] ? wake_up_state+0x20/0x20 >>>> [11279.501428] [<ffffffffc05eeb97>] xfs_file_fsync+0x107/0x1e0 [xfs] >>>> [11279.501432] [<ffffffffb944ef3f>] generic_write_sync+0x4f/0x70 >>>> [11279.501461] [<ffffffffc05f0545>] xfs_file_aio_write+0x155/0x1b0 >>>> [xfs] >>>> [11279.501466] [<ffffffffb941a533>] do_sync_write+0x93/0xe0 >>>> [11279.501471] [<ffffffffb941b010>] vfs_write+0xc0/0x1f0 >>&g...

...force_lsn+0x2e8/0x340 >>>>> [xfs] >>>>> [11279.501396] [<ffffffffb92cf1b0>] ? wake_up_state+0x20/0x20 >>>>> [11279.501428] [<ffffffffc05eeb97>] xfs_file_fsync+0x107/0x1e0 [xfs] >>>>> [11279.501432] [<ffffffffb944ef3f>] generic_write_sync+0x4f/0x70 >>>>> [11279.501461] [<ffffffffc05f0545>] xfs_file_aio_write+0x155/0x1b0 >>>>> [xfs] >>>>> [11279.501466] [<ffffffffb941a533>] do_sync_write+0x93/0xe0 >>>>> [11279.501471] [<ffffffffb941b010>] vfs_write+0xc0/...

...0x340 >>>>>> [xfs] >>>>>> [11279.501396] [<ffffffffb92cf1b0>] ? wake_up_state+0x20/0x20 >>>>>> [11279.501428] [<ffffffffc05eeb97>] xfs_file_fsync+0x107/0x1e0 [xfs] >>>>>> [11279.501432] [<ffffffffb944ef3f>] generic_write_sync+0x4f/0x70 >>>>>> [11279.501461] [<ffffffffc05f0545>] xfs_file_aio_write+0x155/0x1b0 >>>>>> [xfs] >>>>>> [11279.501466] [<ffffffffb941a533>] do_sync_write+0x93/0xe0 >>>>>> [11279.501471] [<ffffffffb941b010>]...

I''ve been working to try to improve the write-ahead log''s performance, and I found that the bottleneck addresses in the checksum items, especially when we want to make a random write on a large file, e.g a 4G file. Then a idea for this suggested by Chris is to use sub transaction ids and just to log the part of inode that had changed since either the last log commit or the last