Re: Better handling of short reads

Mike Belopuhov wrote: > On Wed, Jun 14, 2017 at 11:43 -0400, Ted Unangst wrote: > > Mike Belopuhov wrote: > > > still looking forward to replies to the original set of changes. > > > > i'm a little in between. on the one hand, yes, ok, it's good that we don't > > leave corrupted buffers around

Re: Better handling of short reads

On Wed, Jun 14, 2017 at 11:43 -0400, Ted Unangst wrote: > Mike Belopuhov wrote: > > still looking forward to replies to the original set of changes. > > i'm a little in between. on the one hand, yes, ok, it's good that we don't > leave corrupted buffers around with bad data. on the other hand,

Re: Better handling of short reads

Mike Belopuhov wrote: > still looking forward to replies to the original set of changes. i'm a little in between. on the one hand, yes, ok, it's good that we don't leave corrupted buffers around with bad data. on the other hand, don't we want to learn about these problems and fix them? i don't

Re: Better handling of short reads

On Wed, Jun 14, 2017 at 09:12 -0600, Bob Beck wrote: > > > As you all might have gathered by now Amit has jumped the gun > > but was wrong to do so. His setup is not affected by this change. > > That was expected so please don't get distracted by this as I'm > > still looking forward to replies

Re: Better handling of short reads

> As you all might have gathered by now Amit has jumped the gun > but was wrong to do so. His setup is not affected by this change. > That was expected so please don't get distracted by this as I'm > still looking forward to replies to the original set of changes. > beck@? > > > diff --git

Re: Better handling of short reads

- ok mike, I'm looking at it.. Allow me a short while to beat my head against a wall for a bit to get it into readahead mode... On Wed, Jun 14, 2017 at 3:56 AM, Mike Belopuhov wrote: > On Thu, Jun 08, 2017 at 11:55 +0200, Mike Belopuhov wrote: > > On Wed, Jun 07, 2017 at

Re: Better handling of short reads

On Wed, Jun 14, 2017 at 4:56 AM, Mike Belopuhov wrote: > On Thu, Jun 08, 2017 at 11:55 +0200, Mike Belopuhov wrote: >> On Wed, Jun 07, 2017 at 23:04 -0500, Amit Kulkarni wrote: >> > On Wed, 7 Jun 2017 21:27:27 -0500 >> > Amit Kulkarni wrote: >> > >> > >

Re: Better handling of short reads

On Thu, Jun 08, 2017 at 11:55 +0200, Mike Belopuhov wrote: > On Wed, Jun 07, 2017 at 23:04 -0500, Amit Kulkarni wrote: > > On Wed, 7 Jun 2017 21:27:27 -0500 > > Amit Kulkarni wrote: > > > > > On Thu, 8 Jun 2017 01:57:25 +0200 > > > Mike Belopuhov wrote:

Re: Better handling of short reads

On Wed, Jun 07, 2017 at 23:04 -0500, Amit Kulkarni wrote: > On Wed, 7 Jun 2017 21:27:27 -0500 > Amit Kulkarni wrote: > > > On Thu, 8 Jun 2017 01:57:25 +0200 > > Mike Belopuhov wrote: > > > > > On Wed, Jun 07, 2017 at 18:35 -0500, Amit Kulkarni wrote: >

Re: Better handling of short reads

On Wed, 7 Jun 2017 21:27:27 -0500 Amit Kulkarni wrote: > On Thu, 8 Jun 2017 01:57:25 +0200 > Mike Belopuhov wrote: > > > On Wed, Jun 07, 2017 at 18:35 -0500, Amit Kulkarni wrote: > > > Wow, please get this in!!! > > > > > > This fixes cvs update on

Re: Better handling of short reads

On Thu, 8 Jun 2017 01:57:25 +0200 Mike Belopuhov wrote: > On Wed, Jun 07, 2017 at 18:35 -0500, Amit Kulkarni wrote: > > Wow, please get this in!!! > > > > This fixes cvs update on hard disks, to go much much faster. When I am > > updating the entire set of cvs trees: www,

Re: Better handling of short reads

On Wed, Jun 07, 2017 at 18:35 -0500, Amit Kulkarni wrote: > Wow, please get this in!!! > > This fixes cvs update on hard disks, to go much much faster. When I am > updating the entire set of cvs trees: www, src, xenocara, ports, I can > still use firefox and have it perfectly usable. There's a

Re: Better handling of short reads

Wow, please get this in!!! This fixes cvs update on hard disks, to go much much faster. When I am updating the entire set of cvs trees: www, src, xenocara, ports, I can still use firefox and have it perfectly usable. There's a night and day improvement, before and after. Thanks for debugging and

Better handling of short reads

Hi, I've discovered that short reads (nonzero b_resid) aren't handled very well in our kernel and I've proposed a diff like this to handle short reads of buffercache read-ahead buffers: diff --git sys/kern/vfs_bio.c sys/kern/vfs_bio.c index 95bc80bc0e6..1cc1943d752 100644 --- sys/kern/vfs_bio.c