🚀 go-pugleaf

In article <2jpvk2$2j5@skypoint.skypoint.com> keng@skypoint.com (Ken Germann) writes:
>Anyone have any good or bad experiences to share about the DPT EISA
>caching controllers and Unixware?
>
>I am setting up a news server running INN. I'd like to get some input
>on peoples experiences with DPT and Unixware.

My understanding (Ref: Novell) is that the DPT works with UnixWare.  However
it does not have full bandwidth abilities for full support of the SCSI
II/FAST interface. i.e. it doesn't grok at 10mbits.  All of which is true
even with other UnixWare SCSI Drivers.  But the DPT does give you HARDWARE
RAID support as UnixWare lacks any RAID support unless you want to purchase
$2000.00 worth of vxfs's missing parts....or should I say extensions. :)

Bustek seems to also be a card recommended by many.  Adaptec would be
carefully avoided at the moment as they lack drivers (or lack good drivers)
for their newer products. (I and others have problems with thier 27xx series
controllers or 7770 based products. 1740's are ok but lack performance. then
again I'm biased against Adaptec after a recent critical problem)

It is always best to contact the SCSI OEM before purchasing.  I would also
contact Novell to get an official word of what they support and don't
support.  A Novell reseller may give you other guarantees beyond Novell or
DPT.
-- 
      Harry Skelton - 1848 Beaver Dam Lane - Marietta, Georgia - 30062
          404-590-7100 or 800-366-8181 Work -- 404-578-8085 Home
		      404-590-0355 - Personal Fax
	      My opinions are my own.  Use at your own risk.

In article <2jpvk2$2j5@skypoint.skypoint.com>, keng@skypoint.com (Ken Germann) writes:
|> Anyone have any good or bad experiences to share about the DPT EISA
|> caching controllers and Unixware?
|> 
|> I am setting up a news server running INN. I'd like to get some input
|> on peoples experiences with DPT and Unixware.

Works great -- lots of people around here use them.  To get good performance make
sure that you have some cache (like at least 4Meg) on the DPT card..  

|> 
|> 
|> -- 
|> Ken Germann		        SkyPoint 		keng@skypoint.com
|> 		     Unix RIP Graphical Interface	Use RIPTERM.
|> 	            Internet Mail, USENET News, More.	Login as 'guest'
|> 		      (612)458-3889 (300-14.4) 8N1.	

These are my own words and not necessarily those of Novell.

Kurt Mahan
kurt_mahan@novell.com

In article <zorbaCL9y7D.1BD@netcom.com> zorba@netcom.com (Harry Skelton) writes:
>...the DPT does give you HARDWARE
>RAID support as UnixWare lacks any RAID support unless you want to purchase
>$2000.00 worth of vxfs's missing parts....or should I say extensions. :)

Mirroring and striping are in no way an appropriate part of a file system.
Purchasing UnixWare Online Data Manager *does* give you "vxfs's missing
parts" -- the Advanced Features set like snapshot backup, online resizing,
online defragmentation, enhanced database i/o performance, etc -- but while
it also gives you mirroring and striping, that's not part of vxfs.  It's part
of VERITAS Volume Manager (VxVM), and there's no reason to expect it as part
of a file system.  Mirroring and striping are characteristics of devices,
not file systems.
-- 

ROGER B.A. KLORESE                                          rogerk@QueerNet.ORG
2215-R Market Street #576         San Francisco, CA 94114       +1 415 ALL-ARFF
"There is only one real blasphemy: the refusal of joy."         -- Paul Rudnick

In article <CLDJ3t.BrC@queernet.org> rogerk@queernet.org (Roger B.A. Klorese) writes:
>Mirroring and striping are in no way an appropriate part of a file system.
>Purchasing UnixWare Online Data Manager *does* give you "vxfs's missing
>parts" -- the Advanced Features set like snapshot backup, online resizing,
>online defragmentation, enhanced database i/o performance, etc -- but while
>it also gives you mirroring and striping, that's not part of vxfs.  It's part
>of VERITAS Volume Manager (VxVM), and there's no reason to expect it as part
>of a file system.  Mirroring and striping are characteristics of devices,
>not file systems.

Au contraire!

The file system is everything below the VFS interface, period.

The Raid II specification specifies striping of the network (instead of
SCSI for the backplane, it uses the net).

Just because Veritas logically divides it doesn't mean their OEM's should
do the same.

There's no reason NOT to expect RAID and striping to be part of someones
product offering.


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.

In article <2jpvk2$2j5@skypoint.skypoint.com> keng@skypoint.com (Ken Germann) writes:
>Anyone have any good or bad experiences to share about the DPT EISA
>caching controllers and Unixware?
>
>I am setting up a news server running INN. I'd like to get some input
>on peoples experiences with DPT and Unixware.

if you're using vxfs, relational data bases, or anything that depends
on synchronous writes being synchronous (like parts of UFS), then make
sure you don't configure the DPT cache as a write-back cache on the 
controller board (which is where you pick up most of your performance).

or, buy a UPS (uninterruptible power supply), put a piece of tape over
the reset button, and realize that you will occasionally suffer data
corruption (which may not be a problem if you're only carrying news).

basically, the biggest problem is that a write back cache changes the
ordering of writes, and a slightly smaller problem is that it makes
synchronous writes asynchronous.  what happens is that when you do a
write, it gets placed in the (volatile) cache and gets written to disk
when the controller is less busy (or the cache gets full), in an order
determined by the controller.  this happens even if the file was opened
with the O_SYNC flag (which is supposed to provide synchronous updates),
if you've done an fsync() on the file, etc.

for databases, or vxfs (which uses a logging technique similar to
databases), where the order of writes is important, you have a big
problem.  if you're using vxfs on a system with a volatile write-back
cache, you'd be well advised to change the invocation of fsck in
/sbin/bcheckrc and /sbin/ckroot to "fsck -F vxfs -o full ..." so that
vxfs does a full fsck when the system reboots (if the file system is
dirty).  be sure that you change the script in such a way that only
the vxfs fsck program is invoked with the "-o full" flag.  if you screw
up /sbin/ckroot, you may not be able to recover your system.

note that ufs and bfs have a similar problem--think about rebooting
the system, where the superblock may go to disk with the clean flag
set before dirty inodes and the like are sync'ed to disk.  ufs and bfs
also depend on the ordering of writes (in certain cases) to avoid file
system corruption, such as when allocating a new indirect block to a
file:  the block is allocated and cleared on disk before the address
of the block is written in the inode.  this insures that if the system
crashes, the inode is not left pointing at an indirect block full of
random addresses.

so, if you're going to use the cache on a DPT controller, either 1) buy
a UPS (to insure the power doesn't go down while the cache is dirty),
take steps to insure no one resets or otherwise molests the machine
while the controller is flushing it's cache, or 2) configure the cache
in write-back mode (which is supposed to be possible).  note that you'll
lose much of the performance benefit of the cache if it is used in
write-back mode.

note that these views are my own personal views and not those of veritas.

>-- 
>Ken Germann		        SkyPoint 		keng@skypoint.com
>		     Unix RIP Graphical Interface	Use RIPTERM.
>	            Internet Mail, USENET News, More.	Login as 'guest'
>		      (612)458-3889 (300-14.4) 8N1.	
-- 
{apple,amdahl}!veritas!craig				craig@veritas.com
(415) 668-3564 (h)					(408) 727-1222 x220 (w)
	[views expressed above aren't Veritas' views, nor should 
	they be mistaken for the views of any responsible person.]