similar to: [PATCH] Btrfs: check for duplicate iov_base's when doing dio reads

This idea is from ext4. By this patch, we can make the dio write parallel, and improve the performance. We needn''t worry about the race between dio write and truncate, because the truncate need wait untill all the dio write end. And we also needn''t worry about the race between dio write and punch hole, because we have extent lock to protect our operation. I ran fio to test the

V1->V2: Check to see if our current ppos is >= i_size after a short DIO read, just in case it was actually a short read and we need to just return. This is similar to what already happens in the write case. If we have a short read while doing O_DIRECT, instead of just returning, fallthrough and try to read the rest via buffered IO. BTRFS needs this because if we encounter a compressed or

V1->V2: -Changed dio_end_io to EXPORT_SYMBOL_GPL -Removed the own_submit blockdev dio helper -Removed the boundary change V2->V3 -Made it so we keep track of what the current logical offset in the file we have a BIO setup for so we can pass it into the submit_io hook. Because BTRFS can do RAID and such, we need our own submit hook so we can setup the bio''s in the correct fashion,

V1->V2: Check to see if our current ppos is >= i_size after a short DIO read, just in case it was actually a short read and we need to just return. This is similar to what already happens in the write case. If we have a short read while doing O_DIRECT, instead of just returning, fallthrough and try to read the rest via buffered IO. BTRFS needs this because if we encounter a compressed or

Hi, this is about an issue newer kernels show, bysplitting direct I/O requests into 4k pieces to directly merge them in the Block Device Layer afterwards. If anyone is interested in own tests just use a simple command like dd if=/mnt/test/test-dd1 of=/dev/null iflag=direct bs=64k count=1 in combination with blktrace. The following patch is more a proposal for discussion than a solution, well

This is my still-working-on-it code for btrfs directIO read. I''m posting it so people can see the progress being made on the project and can take an early shot at telling me this is just a bad idea and I''m crazy if they want to, or point out where I made some stupid mistake with btrfs core functions. The code is not complete and *NOT* ready for review or testing. I looked at

Signed-off-by: Dave Kleikamp <dave.kleikamp at oracle.com> Acked-by: Joel Becker <jlbec at evilplan.org> Cc: Zach Brown <zab at zabbo.net> Cc: Mark Fasheh <mfasheh at suse.com> Cc: ocfs2-devel at oss.oracle.com --- fs/ocfs2/aops.h | 2 +- fs/ocfs2/file.c | 55 ++++++++++++++++++++++---------------------------- fs/ocfs2/ocfs2_trace.h | 6 +++--- 3 files

From: Zach Brown <zab@zabbo.net> ocfs2''s .aio_read and .aio_write methods are changed to take iov_iter and pass it to generic functions. Wrappers are made to pack the iovecs into iters and call these new functions. Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com> Cc: Zach Brown <zab@zabbo.net> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker

V1->V2: Check to see if our current ppos is >= i_size after a short DIO read, just in case it was actually a short read and we need to just return. This is similar to what already happens in the write case. If we have a short read while doing O_DIRECT, instead of just returning, fallthrough and try to read the rest via buffered IO. BTRFS needs this because if we encounter a compressed or

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

On Mon, Feb 06, 2023 at 07:00:35AM +0000, Arseniy Krasnov wrote: >This adds main logic of MSG_ZEROCOPY flag processing for packet >creation. When this flag is set and user's iov iterator fits for >zerocopy transmission, call 'get_user_pages()' and add returned >pages to the newly created skb. > >Signed-off-by: Arseniy Krasnov <AVKrasnov at sberdevices.ru>

when we fall back to buffered write from direct write, we call __generic_file_aio_write but that will end up doing direct write even we are only prepared to do buffered write because the file has O_DIRECT flag set. This is a fix for https://bugzilla.novell.com/show_bug.cgi?id=591039 revised with Joel's comments. --- fs/ocfs2/file.c | 23 ++++++++++++----------- 1 files changed, 12

We have been unconditionally allocating a new bio and re-adding all pages from our original bio to the new bio. This is needed if our original bio is larger than our stripe size, but if it is smaller than the stripe size then there is no need to do this. So check the map length and if we are under that then go ahead and submit the original bio. Thanks, Signed-off-by: Josef Bacik

i_alloc_sem has always been a bit of an odd "lock". It''s the only remaining rw_semaphore that can be released by a different thread than the one that locked it, and it''s use case in the core direct I/O code is more like a counter given that the writers already have external serialization. This series removes it in favour of a simpler counter scheme, thus getting rid

V4 changes: add Acked-by: Joel Becker <jlbec at evilplan.org> V3 changes: - add Cc: stable at vger.kernel.org in the patch header to align with stable rules - add Acked-by: Jeff Moyer <jmoyer at redhat.com> V2 changes: - update the patch header of the first patch to make it more clear. This patch list fixes an issue about ocfs2 aio/dio write process hang. The call trace is like

Hi Vitaly, Thank you for the patch! Yet something to improve: [auto build test ERROR on vhost/linux-next] [also build test ERROR on v4.19 next-20181102] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Vitaly-Mayatskikh/vhost-add-vhost_blk-driver/20181103-084141 base:

On Fri, Nov 02, 2018 at 06:21:23PM +0000, Vitaly Mayatskikh wrote: > This driver accelerates host side of virtio-blk. > > Signed-off-by: Vitaly Mayatskikh <v.mayatskih at gmail.com> > --- > drivers/vhost/Kconfig | 13 ++ > drivers/vhost/Makefile | 3 + > drivers/vhost/blk.c | 510 +++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 526 insertions(+)

I noticed that if the free space cache has an error writing out it''s data it won''t actually error out, it will just carry on. This is because it doesn''t check the return value of btrfs_wait_ordered_range, which didn''t actually return anything. So fix this in order to keep us from making free space cache look valid when it really isnt. Thanks, Signed-off-by:

On Fri, Nov 02, 2018 at 06:21:23PM +0000, Vitaly Mayatskikh wrote: > This driver accelerates host side of virtio-blk. Did you look at vhost-user-blk? It does things slightly differently: more of the virtio-blk device model is handled by the vhost-user device (e.g. config space). That might be necessary to implement virtio_blk_config.writeback properly. > +#define VHOST_BLK_SET_BACKEND

On Mon, Feb 26, 2018 at 11:52:56AM +0100, Jan Kara wrote: > On Fri 23-02-18 15:47:36, Mark Rutland wrote: > > Hi all, > > > > While fuzzing arm64/v4.16-rc2 with syzkaller, I simultaneously hit a > > number of splats in the block layer: > > > > * inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-R} usage in > > jbd2_trans_will_send_data_barrier > >