[ On Saturday, April 26, 2003 at 10:00:44 (-0700), Jason Thorpe wrote: ]
> Subject: Re: disks write-back cache
>
> On Saturday, April 26, 2003, at 09:05  AM, Manuel Bouyer wrote:
> > 
> > This cause problems for filesystems or applications that take measure to
> > prevent problems in case of unattended reboot (e.g. FFS, or sendmail).
> > Until today I though I was safe when using SCSI disks.
> > I think the kernel should print a warning when it probes a disk with the
> > write cache enabled.

Heh.  Yes, disk manufacturers seem to want to give the impression of
good performance more than they need to give the impression of more
reliable operation, but good server vendors worth their salt will want
to ensure more reliable operation over and above performance tweaks that
will lower reliability.  :-)

> Perhaps the kernel should print the cache enabled status of the drive 
> with the autoconfiguration messages?

Yes please!  This would be very useful.

It would also be very useful to print the AWRE and ARRE settings (as I
may have mentioned at least once before :-).  I keep meaning to hack
on this myself, but have never got around to it.

BTW, is there any plan/desire to make this new dkctl(8) manage such
things as the SCSI A?RE mode page settings, especially when such
settings might be common to other non-SCSI devices?

> Anyway, if the drive isn't going to reorder commands, then your 
> performance can be really bad with the w/b cache disabled.  We should 
> probably have some dkctl(8) settings that allow tuning these other 
> kinds of disk parameters.

s/dkctl/scsictl/?  Or are you saying that dkctl(8) will become the
preferred way to interact with "disks" as opposed to having special

BTW, it would also be nice to have generic mode page editing in
scsictl(8), as well as specific AWRE & ARRE set&clear commands in either
scsictl(8) and/or dkctl(8).  :-)  (I keep building the old FreeBSD
"scsi" command to do this because I'm too lazy to re-jig the code to fit
into scsictl... :-)

> Well... Another idea might be to make the file systems w/b cache-aware. 
>   I've mentioned this idea to a few people before, but no one seems to 
> think it's necessary.  Anyway, the idea is that you make the file 
> system issue cache flushes at its own barrier points (either explicitly 
> with a separate command, or by setting a flag in its I/O request which 
> causes the disk driver to do so at the end of that I/O).

I think such "awareness" would be much more interesting for virtual disk
drivers that provide redundancy/high-avail. features, and/or possibly
their own caching, such as RAIDframe.  Though I've not yet got around to
actually benchmarking it, I suspect that RAID-1 and maybe epecially
RAID-0+1 would benefit significantly from enabling write caching on
drives....

> However, that's a lot of work, so issuing a warning might not be a 
> horrible idea... but it should might be annoying to see them all the 
> time.

I don't think such information would ever be "annoying" on any
production system.

Only kernel hackers reboot their systems so often that such "extra"
information could ever become "annoying" in any way to them.  :-)

Either way it couldn't possibly be more annoying than seeing all the
intricate details about internal host-bus and bus-bridge attachments
that can neither be modified by the admin, nor have any serious impact
on the system.  ;-)

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>