Return to BSD News archive
Xref: sserve comp.unix.bsd:7866 comp.benchmarks:2396 comp.arch:28219 comp.arch.storage:696
Newsgroups: comp.unix.bsd,comp.benchmarks,comp.arch,comp.arch.storage
Path: sserve!manuel.anu.edu.au!munnari.oz.au!hp9000.csc.cuhk.hk!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!menudo.uh.edu!nuchat!sugar!ficc!peter
From: peter@ferranti.com (peter da silva)
Subject: Re: Disk performance issues, was IDE vs SCSI-2 using iozone
Message-ID: <id.WFYU.34K@ferranti.com>
Organization: Xenix Support, FICC
References: <36794@cbmvax.commodore.com> <1992Nov10.170022.21624@igor.tamri.com> <36994@cbmvax.commodore.com>
Date: Fri, 13 Nov 1992 17:36:25 GMT
Lines: 59
In article <36994@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes:
> I strongly suspect that this will continue, as the benefits
> of zone recording, sector replacement, etc are too large to ignore (a number
> of filesystems (most?) require that the device drivers present them with a
> perfect media, no unusable blocks.
Yes, we've had this discussion before. This is a very bad idea. The filesystem
is the only system component that understands the semantics of a block being
bad. Since it's impossible to create a virtual error-free surface (what do
you do about lost blocks? Fill 'em in with zeroes? You gotta tell the FS that
it just lost that data somehow) pretending that you can leads to ignorance
about pending disk problems until the bad block table fills and there's no way
to gracefully clean up.
I've been bitten by this on SCSI disks on Unix (Intel 520) and AmigaOS.
The right place to handle bad blocks is the filesystem. Anywhere else and
you're asking for trouble. Even better would be to provide an application
level interface for this, so an application can find out if this block full
of nulls is real or a disk error.
The same is true of network file systems. Forcing statelessness so you can
create an illusion that the network doesn't exist is a bad idea.
> There's a big philosophical argument over who should deal with media
> problems. The consensus seems to be that they should be pushed into the
> lowest level possible (fs->driver->host controller->drive controller).
You forgot "application".
> Having
> written both filesystems and device drivers, I must agree with that (and yes
> I've had to implement bad-block mapping at the driver level, such as for IDE).
It makes some the software easier to write, I'm sure, but it sure makes things
tough on us users. I'd much rather have the goal be end-to-end reliability
instead of setting up a bunch of point-to-point reliable links.
> >What I said was enough ... the UNIX interfaces are more general by DESIGN
> >and a simplistic OS
AmigaOS is *not* a simplistic O/S. It's really quite a beautiful structure,
with a VERY clean method of creating extensions, and a well-defined API and
set of API design rules. I'd love to have something with UNIX semantics on
top of something like AmigaOS.
> Other reasonably modern OS's can also get very good IO numbers, such
> as QNX.
Ah, if only Quantum would go after the low-end market... :->
> To be or not to be = 0xff
Nope, it's -1 unless you're programming in PL/M.
--
Peter da Silva / 77487-5012 USA / +1 713 274 5180
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?