Re: Plan: journalling fixes for WAPBL

> On Sep 23, 2016, at 10:51 AM, Warner Losh wrote: > > On Fri, Sep 23, 2016 at 7:38 AM, Thor Lancelot Simon wrote: >> On Fri, Sep 23, 2016 at 11:47:24AM +0200, Manuel Bouyer wrote: >>> On Thu, Sep 22, 2016 at 09:33:18PM -0400, Thor Lancelot Simon wrote: >

Re: FUA and TCQ (was: Plan: journalling fixes for WAPBL)

> On Sep 23, 2016, at 5:49 AM, Edgar Fuß wrote: > >> The whole point of tagged queueing is to let you *not* set [the write >> cache] bit in the mode pages and still get good performance. > I don't get that. My understanding was that TCQ allowed the drive to re-order >

Re: CVS commit: src/sys/arch

On Fri, Sep 23, 2016 at 09:33:36PM +0200, Jaromír Dole?ek wrote: > Hey Maxime, > > Seems the KASSERTs() are too aggressive, or there is some other bug. > > I can trigger the kassert by simply attaching to rump_ffs, setting a > breakpoint and continuing, i.e: > > > rump_ffs -o log ./ffs ./mnt >

Re: CVS commit: src/sys/arch

Hey Maxime, Seems the KASSERTs() are too aggressive, or there is some other bug. I can trigger the kassert by simply attaching to rump_ffs, setting a breakpoint and continuing, i.e: > rump_ffs -o log ./ffs ./mnt > gdb rump_ffs ... (gdb) attach RUMP_PID (gdb) break ffs_truncate Breakpoint 1 at

Re: Plan: journalling fixes for WAPBL

On Fri, Sep 23, 2016 at 11:54 AM, Warner Losh wrote: > On Fri, Sep 23, 2016 at 11:20 AM, Thor Lancelot Simon wrote: >> On Fri, Sep 23, 2016 at 05:15:16PM +, Eric Haszlakiewicz wrote: >>> On September 23, 2016 10:51:30 AM EDT, Warner Losh

Re: Plan: journalling fixes for WAPBL

On Fri, Sep 23, 2016 at 11:20 AM, Thor Lancelot Simon wrote: > On Fri, Sep 23, 2016 at 05:15:16PM +, Eric Haszlakiewicz wrote: >> On September 23, 2016 10:51:30 AM EDT, Warner Losh wrote: >> >All NCQ gives you is the ability to schedule multiple requests and

Re: Plan: journalling fixes for WAPBL

On Fri, Sep 23, 2016 at 01:46:09PM -0400, Thor Lancelot Simon wrote: > > > This seems like the key thing needed to avoid FUA: to implement fsync() > > > you just wait for notifications of completion to be received, and once > > > you have those for all requests pending when fsync was called, or

Re: Plan: journalling fixes for WAPBL

On Fri, Sep 23, 2016 at 07:45:00PM +0200, Manuel Bouyer wrote: > On Fri, Sep 23, 2016 at 05:15:16PM +, Eric Haszlakiewicz wrote: > > On September 23, 2016 10:51:30 AM EDT, Warner Losh wrote: > > >All NCQ gives you is the ability to schedule multiple requests and > > >to get

Re: Plan: journalling fixes for WAPBL

On Fri, Sep 23, 2016 at 01:20:09PM -0400, Thor Lancelot Simon wrote: > On Fri, Sep 23, 2016 at 05:15:16PM +, Eric Haszlakiewicz wrote: > > On September 23, 2016 10:51:30 AM EDT, Warner Losh wrote: > > >All NCQ gives you is the ability to schedule multiple requests and > > >to

Re: Plan: journalling fixes for WAPBL

On Fri, Sep 23, 2016 at 05:15:16PM +, Eric Haszlakiewicz wrote: > On September 23, 2016 10:51:30 AM EDT, Warner Losh wrote: > >All NCQ gives you is the ability to schedule multiple requests and > >to get notification of their completion (perhaps out of order). There's > >no

Re: Plan: journalling fixes for WAPBL

On September 23, 2016 10:51:30 AM EDT, Warner Losh wrote: >All NCQ gives you is the ability to schedule multiple requests and >to get notification of their completion (perhaps out of order). There's >no coherency features are all in NCQ. This seems like the key thing needed to

Re: Plan: journalling fixes for WAPBL

On Fri, Sep 23, 2016 at 09:38:44AM -0400, Thor Lancelot Simon wrote: > > But anyway, from what I remember you still need the disk cache flush > > operation for SATA, even with NCQ. It's not equivalent to the SCSI tags. > > I think that's true only if you're running with write cache enabled; but >

Re: FUA and TCQ

On Fri, Sep 23, 2016 at 8:05 AM, Thor Lancelot Simon wrote: > Our storage stack's inability to use tags with SATA targets is a huge > gating factor for performance with real workloads (the residual use of > the kernel lock at and below the bufq layer is another). FreeBSD's

Re: Plan: journalling fixes for WAPBL

On Fri, Sep 23, 2016 at 7:38 AM, Thor Lancelot Simon wrote: > On Fri, Sep 23, 2016 at 11:47:24AM +0200, Manuel Bouyer wrote: >> On Thu, Sep 22, 2016 at 09:33:18PM -0400, Thor Lancelot Simon wrote: >> > > AFAIK ordered tags only guarantees that the write will happen in order, >> >

Re: FUA and TCQ

On Fri, Sep 23, 2016 at 09:38:08AM -0400, Greg Troxel wrote: > > Johnny Billquist writes: > > > With rotating rust, the order of operations can make a huge difference > > in speed. With SSDs you don't have those seek times to begin with, so > > I would expect the gains to be

Re: FUA and TCQ

On 2016-09-23 15:38, Greg Troxel wrote: Johnny Billquist writes: With rotating rust, the order of operations can make a huge difference in speed. With SSDs you don't have those seek times to begin with, so I would expect the gains to be marginal. For reordering, I agree

Re: Plan: journalling fixes for WAPBL

On Fri, Sep 23, 2016 at 11:47:24AM +0200, Manuel Bouyer wrote: > On Thu, Sep 22, 2016 at 09:33:18PM -0400, Thor Lancelot Simon wrote: > > > AFAIK ordered tags only guarantees that the write will happen in order, > > > but not that the writes are actually done to stable storage. > > > > The

Re: FUA and TCQ

Johnny Billquist writes: > With rotating rust, the order of operations can make a huge difference > in speed. With SSDs you don't have those seek times to begin with, so > I would expect the gains to be marginal. For reordering, I agree with you, but the SSD speeds are so high

Re: FUA and TCQ

On 2016-09-23 13:05, David Holland wrote: On Fri, Sep 23, 2016 at 11:49:50AM +0200, Edgar Fu? wrote: > > The whole point of tagged queueing is to let you *not* set [the write > > cache] bit in the mode pages and still get good performance. > > I don't get that. My understanding was that TCQ

Re: FUA and TCQ

On Fri, Sep 23, 2016 at 01:13:09PM +0200, Edgar Fuß wrote: > > You can have more than one in flight at a time. > My SCSI knowledge is probably out-dated. How can I have several commands > in flight concurrently? This is what tagged queueing is for. -- Manuel Bouyer

Re: FUA and TCQ

> You can have more than one in flight at a time. My SCSI knowledge is probably out-dated. How can I have several commands in flight concurrently?

Re: FUA and TCQ

On 2016-09-23 11:49, Edgar Fuß wrote: The whole point of tagged queueing is to let you *not* set [the write cache] bit in the mode pages and still get good performance. I don't get that. My understanding was that TCQ allowed the drive to re-order commands within the bounds described by the

Re: FUA and TCQ (was: Plan: journalling fixes for WAPBL)

On Fri, Sep 23, 2016 at 11:49:50AM +0200, Edgar Fu? wrote: > > The whole point of tagged queueing is to let you *not* set [the write > > cache] bit in the mode pages and still get good performance. > > I don't get that. My understanding was that TCQ allowed the drive > to re-order commands

FUA and TCQ (was: Plan: journalling fixes for WAPBL)

> The whole point of tagged queueing is to let you *not* set [the write > cache] bit in the mode pages and still get good performance. I don't get that. My understanding was that TCQ allowed the drive to re-order commands within the bounds described by the tags. With the write cache disabled,

Re: Plan: journalling fixes for WAPBL

On Thu, Sep 22, 2016 at 09:33:18PM -0400, Thor Lancelot Simon wrote: > > AFAIK ordered tags only guarantees that the write will happen in order, > > but not that the writes are actually done to stable storage. > > The target's not allowed to report the command complete unless the data > are on