similar to: Win2K/XP, oplocks, and readahead.

The readahead filter is a self-configuring filter that makes sequential reads faster when the plugin is slow (and all of the plugins we use here are always slow). I observed the behaviour of the readahead filter with our qcow2 overlay when converting a guest from a vCenter source. Even when doing random reads, qemu issues 64K reads which happen to also be the minimum request size of the

This filter deliberately tries to coalesce reads into larger requests. Unfortunately VMware has low limits on the size of requests it can serve to a VDDK client and the larger requests would break with errors like this: nbdkit: vddk[3]: error: [NFC ERROR] NfcFssrvrProcessErrorMsg: received NFC error 5 from server: Failed to allocate the requested 33554456 bytes We already increase the maximum

This appears to be the cause of timeouts during the conversion step where VMware VCenter server's Tomcat HTTPS server stops responding to requests (or rather, responds only with 503 errors). The server later recovers and in fact because of the retry filter the conversion usually succeeds, but I found that we can avoid the problem by disabling readahead. --- v2v/nbdkit_sources.ml | 8 ++++----

Hi all, I think I've spotted a few stupidities (bugs) in the current version of kernel-utils (kernel-utils-2.4-13.1.80). I'm sure these are all propagated from upstream, but I hope someone could have a quick look to verify this and see if we either can push complaints upwards, or provide local fixes. The kernel-utils package provides several 'kernel-type' functions -

This adds a binding for 'blockdev --setra', allowing you to adjust the readahead parameter for filesystems and devices. --- daemon/blockdev.c | 30 ++++++++++++++++++++---------- generator/actions.ml | 14 ++++++++++++++ 2 files changed, 34 insertions(+), 10 deletions(-) diff --git a/daemon/blockdev.c b/daemon/blockdev.c index 8a7b1a8..6e8821d 100644 --- a/daemon/blockdev.c +++

I'm trying to replicate the features of the qemu curl plugin in nbdkit's curl plugin, in order that we can use nbdkit in virt-v2v to access VMware servers. I've implemented everything else so far [not posted yet] except for readahead. To my surprise actually, qemu's curl driver implements readahead itself. I thought it was a curl feature. I'm not completely clear _how_ it

On Thu, Apr 11, 2019 at 06:55:55PM +0100, Richard W.M. Jones wrote: >As I've spent really too long today investigating this, I want to >document this in a public email, even though there's nothing really >that interesting here. One thing you find from search for VDD 6.7 / >VixDiskLib_QueryAllocatedBlocks issues with Google is that we must be >one of the very few users out

On 9/20/19 9:04 AM, Martin Kletzander wrote: > On Fri, Sep 20, 2019 at 10:28:18AM +0100, Richard W.M. Jones wrote: >> The readahead filter is a self-configuring filter that makes >> sequential reads faster when the plugin is slow (and all of the >> plugins we use here are always slow). >> >> @@ -133,9 +142,17 @@ let common_create plugin_name plugin_args >>

Reduce ioprio class of scrub readahead threads to idle priority. This setting is fixed. This priority has shown the best performance during all measurements. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de> --- fs/btrfs/ctree.h | 3 +++ fs/btrfs/reada.c | 5 +++++ 2 files changed, 8 insertions(+) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index ec42a24..e6f772d 100644

Martin Steigerwald reported a BUG_ON() where we were given a bogus bytenr to map. Turns out he is using > PAGESIZE leafsizes. The readahead stuff is called every time we do a completion, but we may not have finished reading in all the pages, so the bytenr we read off the node could be completely bogus. Fix this by only calling the readahead hook once all pages have been read in. Thanks,

On Fri, Sep 20, 2019 at 10:28:18AM +0100, Richard W.M. Jones wrote: >The readahead filter is a self-configuring filter that makes >sequential reads faster when the plugin is slow (and all of the >plugins we use here are always slow). > >I observed the behaviour of the readahead filter with our qcow2 >overlay when converting a guest from a vCenter source. Even when >doing

On 6/19/20 7:47 AM, Richard W.M. Jones wrote: > This appears to be the cause of timeouts during the conversion step > where VMware VCenter server's Tomcat HTTPS server stops responding to > requests (or rather, responds only with 503 errors). The server later > recovers and in fact because of the retry filter the conversion > usually succeeds, but I found that we can avoid the

I'm still testing this fix, so let's hold off the review for the moment. Also it may be better to specifically identify problematic servers rather than disabling this for every curl source. eg. I suspect that the problem is the Java server used by VCenter, so we might think about only disabling readahead for that single case. Rich.

Quick question... The docs for vfs readahead mention Windows Vista, but what about modern Windows versions? Windows Server 2016 or Windows Server 2019? Thank you, -- BOB BUCK SENIOR PLATFORM SOFTWARE ENGINEER SKIDMORE, OWINGS & MERRILL 7 WORLD TRADE CENTER 250 GREENWICH STREET NEW YORK, NY 10007 T (212) 298-9624 ROBERT.BUCK at SOM.COM

This is the simplest solution to this problem. There are two other possible fixes I considered: Increase the documented limit (see http://libguestfs.org/virt-v2v-input-vmware.1.html#vddk:-esxi-nfc-service-memory-limits). However at the moment we know the current limit works through extensive testing (without readahead), plus I have no idea nor any way to test if larger limits are supported by

As I've spent really too long today investigating this, I want to document this in a public email, even though there's nothing really that interesting here. One thing you find from search for VDD 6.7 / VixDiskLib_QueryAllocatedBlocks issues with Google is that we must be one of the very few users out there. And the other thing is that it's quite broken. All testing was done using

Hi Jeremy, thank you for your very helpful response. We're looking at a few more options. Would you have the time to provide some guidance on these, how helpful they may be? - *aio ** -> https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#AIOREADSIZE - *write cache* -> https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#WRITECACHESIZE -

A suggested readahead filter. I've only lightly tested this, but it seems to work fine with qemu-img convert. The commit needs proper tests. Rich.

On Wed, 15 Aug 2018 12:59:06 +0430 richard russell <russellrichard160 at gmail.com> wrote: > my smb.conf > > [global] > workgroup = WORKGROUP > netbios name = hpds > security = user > map to guest = Bad User > dns proxy = no > server string = %h server > log level = 0 > max log size = 10000 > load printers = no > passdb backend = tdbsam >

Hi, We have file readahead to do asyn file read, but has no metadata readahead. For a list of files, their metadata is stored in fragmented disk space and metadata read is a sync operation, which impacts the efficiency of readahead much. The patches try to add meatadata readahead for btrfs. In btrfs, metadata is stored in btree_inode. Ideally, if we could hook the inode to a fd so we could use