Re: write barrier patches for 2.4.21

Re: write barrier patches for 2.4.21

[Tom Vier]

On Fri, Aug 29, 2003 at 03:56:08AM +0200, Matthias Andree wrote:
> They don't? That's not what I've seen on some of the recent drives I
> bought. The OEM manuals should have details.

all the seagate's i've gotten have always had it disabled. including the
15k.3's i bought a little while back. old quantum's, too. i don't remember
any scsi drive i've had that defaulted to enabled. most highend scsi drives
are suppost to be highly reliable, and default to such settings, so they can
just be plugged into a hotswap raid w/o having to change mode pages.

-- 
Tom Vier <tmv@comcast.net>
DSA Key ID 0xE6CB97DA

write barrier patches for 2.4.21

[Gergely Tamas]

Hi!

Where can I get Jens Axboe's + Chris Mason's (reiserfs) ide write
barrier patches for kernel 2.4.21 ?

I'd like to test a 3ware based raid setup (8xide) with write cache
enabled.

Thanks in advance,
Gergely

Re: write barrier patches for 2.4.21

[Oleg Drokin]

Hello!

On Mon, Aug 25, 2003 at 07:08:49PM +0200, Gergely Tamas wrote:

> Where can I get Jens Axboe's + Chris Mason's (reiserfs) ide write
> barrier patches for kernel 2.4.21 ?
> I'd like to test a 3ware based raid setup (8xide) with write cache
> enabled.

I think that the patch does not have 3ware support. Only conventional IDE
controllers are supported by the patch.

Bye,
    Oleg

Re: write barrier patches for 2.4.21

[Gergely Tamas]

Hi!

 > > Where can I get Jens Axboe's + Chris Mason's (reiserfs) ide write
 > > barrier patches for kernel 2.4.21 ?
 > > I'd like to test a 3ware based raid setup (8xide) with write cache
 > > enabled.
 > 
 > I think that the patch does not have 3ware support. Only conventional IDE
 > controllers are supported by the patch.

Thanks.

So the only way for production servers is still with write cache
disabled.

Gergely

Re: write barrier patches for 2.4.21

[Oleg Drokin]

Hello!

On Tue, Aug 26, 2003 at 11:03:48AM +0200, Gergely Tamas wrote:
>  > > Where can I get Jens Axboe's + Chris Mason's (reiserfs) ide write
>  > > barrier patches for kernel 2.4.21 ?
>  > > I'd like to test a 3ware based raid setup (8xide) with write cache
>  > > enabled.
>  > I think that the patch does not have 3ware support. Only conventional IDE
>  > controllers are supported by the patch.
> Thanks.
> So the only way for production servers is still with write cache
> disabled.

Actually if you have some sort of uninterruptible power supply that never fails (and
you have correct shutdown scripts to shut the box down when its about to run out), you
are safe to use write cache.

Bye,
    Oleg

Re: write barrier patches for 2.4.21

[Gergely Tamas]

Hi!

 > Actually if you have some sort of uninterruptible power supply that never fails (and
 > you have correct shutdown scripts to shut the box down when its about to run out), you
 > are safe to use write cache.

Thank you.
Gergely

Re: write barrier patches for 2.4.21

[Tom Vier]

anyone working on scsi wb's? there was a long thread on l-k about wb's, but
i wasn't aware what came of it.

-- 
Tom Vier <tmv@comcast.net>
DSA Key ID 0xE6CB97DA

Re: write barrier patches for 2.4.21

[Oleg Drokin]

Hello!

On Tue, Aug 26, 2003 at 05:46:24PM -0400, Tom Vier wrote:

> anyone working on scsi wb's? there was a long thread on l-k about wb's, but
> i wasn't aware what came of it.

There was a discussion about that on Kernel Summit 2003 and general opinion was that SCSI
does not need the WB stuff at all as it does the correct thing anyway.
But since the the barrier flags are visible in io requests, actual device drivers
are free to do something when met with barrier requests or to ignore it.
The only concern is probably raid cards that show bunch of IDE drives as a SCSI device.

Bye,
    Oleg

Re: write barrier patches for 2.4.21

[Tom Vier]

On Wed, Aug 27, 2003 at 10:41:03AM +0400, Oleg Drokin wrote:
> There was a discussion about that on Kernel Summit 2003 and general opinion was that SCSI
> does not need the WB stuff at all as it does the correct thing anyway.

i found this, but no real details. do you have a better link? or could you
tell me why scsi drives don't need wb's? afaik, they don't have nvram cache.
so, the danger is still there, even if small (unless i'm wrong).

http://lwn.net/Articles/40850/

> But since the the barrier flags are visible in io requests, actual device drivers
> are free to do something when met with barrier requests or to ignore it.
> The only concern is probably raid cards that show bunch of IDE drives as a SCSI device.

anyone who has more info, please post. 8) i'm very interested. too bad there
aren't video streams of lks, like there were in the past.

-- 
Tom Vier <tmv@comcast.net>
DSA Key ID 0xE6CB97DA

Re: write barrier patches for 2.4.21

[Chris Mason]

On Wed, 2003-08-27 at 18:03, Tom Vier wrote:
> On Wed, Aug 27, 2003 at 10:41:03AM +0400, Oleg Drokin wrote:
> > There was a discussion about that on Kernel Summit 2003 and general opinion was that SCSI
> > does not need the WB stuff at all as it does the correct thing anyway.
> 
> i found this, but no real details. do you have a better link? or could you
> tell me why scsi drives don't need wb's? afaik, they don't have nvram cache.
> so, the danger is still there, even if small (unless i'm wrong).
> 
> http://lwn.net/Articles/40850/
> 

scsi drives don't really need them because most scsi drives don't have
write back caching on by default, and most actually listen when you turn
the cache off.  The scsi tag queuing makes good performance possible
even without writeback caching.

-chris

Re: write barrier patches for 2.4.21

[Mike Fedyk]

On Wed, Aug 27, 2003 at 08:37:40PM -0400, Chris Mason wrote:
> scsi drives don't really need them because most scsi drives don't have
> write back caching on by default, and most actually listen when you turn
> the cache off.  The scsi tag queuing makes good performance possible
> even without writeback caching.

So, in essence, TCQ is exposing what is happening in the cache, and allowing
control/showing state compared to IDE's non-TCQ write cache.  Do I have that
right?

Re: write barrier patches for 2.4.21

[Tom Vier]

On Thu, Aug 28, 2003 at 10:07:25AM -0700, Mike Fedyk wrote:
> On Wed, Aug 27, 2003 at 08:37:40PM -0400, Chris Mason wrote:
> > scsi drives don't really need them because most scsi drives don't have
> > write back caching on by default, and most actually listen when you turn
> > the cache off.  The scsi tag queuing makes good performance possible
> > even without writeback caching.
> 
> So, in essence, TCQ is exposing what is happening in the cache, and allowing
> control/showing state compared to IDE's non-TCQ write cache.  Do I have that
> right?

i'm not sure what you mean. chris is just saying tcq makes performance w/o
write cache better. i WOULD like to see wb's used w/ scsi. it would be nice
to be able to safely enable write cache on my drives.

-- 
Tom Vier <tmv@comcast.net>
DSA Key ID 0xE6CB97DA

Re: write barrier patches for 2.4.21

[Mike Fedyk]

On Thu, Aug 28, 2003 at 08:07:30PM -0400, Tom Vier wrote:
> On Thu, Aug 28, 2003 at 10:07:25AM -0700, Mike Fedyk wrote:
> > On Wed, Aug 27, 2003 at 08:37:40PM -0400, Chris Mason wrote:
> > > scsi drives don't really need them because most scsi drives don't have
> > > write back caching on by default, and most actually listen when you turn
> > > the cache off.  The scsi tag queuing makes good performance possible
> > > even without writeback caching.
> > 
> > So, in essence, TCQ is exposing what is happening in the cache, and allowing
> > control/showing state compared to IDE's non-TCQ write cache.  Do I have that
> > right?
> 
> i'm not sure what you mean. chris is just saying tcq makes performance w/o
> write cache better. i WOULD like to see wb's used w/ scsi. it would be nice
> to be able to safely enable write cache on my drives.

I'm just trying to clairify that it looks like TCQ shows exactly what it
happening in the drive's cache, and that's why with tcq the wb's aren't
explicitly needed.

With ide without tcq and with write caching, it accepts the write request
and says it's complete when it's actually still in the disks cache, not on
the platters yet.

Contrast that to TCQ (IDE or SCSI), where the write request is sent to the
drive, and once it hits the platter, the tcq command completes and notifies
the host OS (Linux in this case) that it's done.  And SCSI with no TCQ is
like IDE with no write cache.

Do I have that right?

Re: write barrier patches for 2.4.21

[Chris Mason]

On Thu, 2003-08-28 at 21:18, Mike Fedyk wrote:
>  
> > i'm not sure what you mean. chris is just saying tcq makes performance w/o
> > write cache better. i WOULD like to see wb's used w/ scsi. it would be nice
> > to be able to safely enable write cache on my drives.
> 
> I'm just trying to clairify that it looks like TCQ shows exactly what it
> happening in the drive's cache, and that's why with tcq the wb's aren't
> explicitly needed.
> 
> With ide without tcq and with write caching, it accepts the write request
> and says it's complete when it's actually still in the disks cache, not on
> the platters yet.
> 
> Contrast that to TCQ (IDE or SCSI), where the write request is sent to the
> drive, and once it hits the platter, the tcq command completes and notifies
> the host OS (Linux in this case) that it's done.  And SCSI with no TCQ is
> like IDE with no write cache.
> 
> Do I have that right?

Pretty much.  If your tag depth is set right, you get the benefits of
writeback caching without the risk.  But your workload has to be right.

Picture one process doing synchronous io writes.  He's only going to
generate one tag and then wait on it.  With writeback cache, the drive
will return immediately, but with just tcq you'll still have to wait.

For the one writer workload with the barrier patches, the writeback
cache disk will be just as slow as the tcq disk.  This is usually what
you want, since if you're taking the time to do synchronous IO it's
because you want to know the data is really on disk (or on battery
backed cache somewhere).

-chris

Re: write barrier patches for 2.4.21

[Matthias Andree]

Chris Mason <mason@suse.com> writes:

> On Wed, 2003-08-27 at 18:03, Tom Vier wrote:
>> On Wed, Aug 27, 2003 at 10:41:03AM +0400, Oleg Drokin wrote:
>> > There was a discussion about that on Kernel Summit 2003 and general opinion was that SCSI
>> > does not need the WB stuff at all as it does the correct thing anyway.
>> 
>> i found this, but no real details. do you have a better link? or could you
>> tell me why scsi drives don't need wb's? afaik, they don't have nvram cache.
>> so, the danger is still there, even if small (unless i'm wrong).
>> 
>> http://lwn.net/Articles/40850/
>> 
>
> scsi drives don't really need them because most scsi drives don't have
> write back caching on by default,

They don't? That's not what I've seen on some of the recent drives I
bought. The OEM manuals should have details.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95

Re: write barrier patches for 2.4.21

[Hans Reiser]

Oleg Drokin wrote:

>Hello!
>
>On Tue, Aug 26, 2003 at 05:46:24PM -0400, Tom Vier wrote:
>
>  
>
>>anyone working on scsi wb's? there was a long thread on l-k about wb's, but
>>i wasn't aware what came of it.
>>    
>>
>
>There was a discussion about that on Kernel Summit 2003 and general opinion was that SCSI
>does not need the WB stuff at all as it does the correct thing anyway.
>
define "correct thing".

>But since the the barrier flags are visible in io requests, actual device drivers
>are free to do something when met with barrier requests or to ignore it.
>The only concern is probably raid cards that show bunch of IDE drives as a SCSI device.
>
>Bye,
>    Oleg
>
>
>  
>


-- 
Hans

Re: write barrier patches for 2.4.21

[Oleg Drokin]

Hello!

On Wed, Sep 03, 2003 at 02:10:03AM +0400, Hans Reiser wrote:
> >There was a discussion about that on Kernel Summit 2003 and general 
> >opinion was that SCSI
> >does not need the WB stuff at all as it does the correct thing anyway.
> define "correct thing".


As I understood it, they do not do reordering or do it in a way
that does not make this reordering visible after crash.

Bye,
    Oleg