TIP: Click on subject to list as thread! ANSI
echo: lan
to: MIKE BILOW
from: LEE ARONER
date: 1997-12-24 00:46:00
subject: NOVELL & WD 6.4GIG

   LA>    Since I AM running HPFS386, this may be why I was starting 
 LA>    The biggest problem seems to be with a 2 gig drive 
 LA> partitioned 1.7 gig in HPFS386 and the balance in FAT. Gets 
MB> Well, there are probably errors on the FAT partition also, but you don't 
find
  > out about them easily because FAT has no internal consistency checking.  
HPFS
  > uses doubly linked lists and embedded cyclic redundancy checks to 
validate a
  > number of its internal structures, so CHKDSK or similar utilties can 
detect
  > corruption much more reliably.
   Hmm. Methinks I will try running DOS Norton on the FAT partition. 
   (From DOS 7.0).  See what it turns up.
MB> If you are asking whether there is any likelihood that having both a FAT 
and
  > HPFS partition makes it any more probable that corruption will occur on 
the
  > HPFS partition, then the answer is no.
   No, just remarking on this fact. There are two identical drives 
   installed, sequential serial numbers, identical history, and this 
   particular partition, which is the only one sized over 509MB, is 
   the one that gives problems. There is also a Micropolis drive, 
   which has been flawless so far.
   To be fair, the problems first started to surface after I backed 
   out HPFS local security. Started getting crashes when building or 
   rebuilding the ACL. Moved all data to another server, rebuilt the 
   partitions and reformatted clean.
   The errors are now confined to corrupted 386HPFS.LOG and one 
   other related (HPFS associated) file (forget the name). Makes 
   sense now in light of the caching explaination.
MB> Don't overlook the obvious, either.  Any drive which frequently reports 
errors
  > should be examined very carefully, especially with regard to cabling and
  > termination.  Write cache comes into play only in terms of maintaining
  > integrity of the data after the drive has reported some error condition, 
so you
  > need to find out why these error conditions are being reported in the 
first
  > place.  Assuming you have applied all of the relevant FixPacks, HPFS386 
s
  > pretty solid, but you may have SCSI driver or hardware problems.
   Actually, I haven't installed any fixpacks yet. Waiting for some 
   cables to get the DAT drive running on this server before I do 
   that. I've been reserving judgment until that happens...
 
MB> You can get Seagate's official utility to manipulate the write cache
MB> enable bit on the appropriate device mode page, APSI-WCE, at:
 LA>    Got it yesterday. 
MB> Let's see if that has any effect.  I think you will need to run that 
under DOS
  > with ASPI support loaded, which can be a pain.  You might be able to run 
it
  > under OS/2, since VASPI support is provided, but I've never tried it.  I 
would
  > be interested to know if that works.
   I'll try it. I'm running a Symbios 810 chip with only the 
   built-in (Warp & NT) drivers, so I'll only install DOS drivers if 
   the Warp method does not come up. Will have to wait till I get a 
   backup of that drive, probably next week.
MB> I can save you a lot of aggravation that you will encounter 
MB> when trying to make sense of the Seagate docuemtation: for 
MB> OS/2, turn off the write cache.
 LA>    For Warp workstations, as well as Server?
MB> Yes.  The reasoning applies to any filesystem which can do hotfixing, 
including
  > HPFS and HPFS386.  If you run FAT only, then it makes no difference.
LA> And I'll bet that NT on the same machine will turn into a
LA> *real* pig without it.
MB> No, the performance penalty of disabling hardware write cache is 
   fairly
  > minimal, as long as there is efficient cache logic at the filesystem 
level in
  > the operating system.  Most of what hardware write cache does is 
compensate for
  > inefficiencies in the filesystem logic.  NTFS is kind of a pig anyway, 
but it
  > is probably not fair to evaluate it on performance when its stated design 
goal
  > of journaling will have an inherent performance penalty; NTFS is a lot 
slower
  > than HPFS386, but this is because HPFS386 does not do journaling.
   If only the NTFS journaling actually worked! I've heard several 
   horror stories of lost data.
   Do you have any info on the forthcoming IBM journaled system?
                                           LRA
 -- SPEED 2.00 #2720: Barnum was wrong . . . it's more like every 30 seconds.
--- Platinum Xpress/Win/Wildcat5! v2.0
---------------
* Origin: Grey Matter * Seattle, WA * 1:343/210 * (206) 528-1941 (1:343/210)

SOURCE: echomail via exec-pc

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.