🚀 go-pugleaf

I pulled some of the cross-posts

So we have a Sales droid politician and a techno-jargon type with these
swell sounding arguments about catastrophic failures using the Sales
droids products.

In article <40orfh$5an@panix.com>, Thor Lancelot Simon <tls@panix.com> wrote:
>In article <DDBnou.6nD@world.std.com>,
>Michael E Willett <mew@world.std.com> wrote:
>>Rather than non-technical generalities, would you have a specific
>>technical question you could post?
>
>No.  I don't have any technical question for you.  Nor did I post any form of
>question whatsoever, as would be blindingly obvious if you hadn't removed the
>entirety of my text instead of responding to it.

Right bash him for not giving technical specifics and then refuse to ask
a technical question.  Your arguments are losing coherency and you sound
hysterical.  Storage Computer offers an enhanced RAID-4 style
implementation THEY CALL RAID-7.  Why does this upset you so much? 
Microsoft calls Windows an operating system, but I don't happen to agree
with that, neither do I claim that using it will cause you to go blind
or grow hair on your palms.

>
>>[NVRAM]
>
>I'm glad to hear that.  Your basic system, with volatile cache on the other
>end of a SCSI bus from the host's buffer cache, still _can not_ correctly
>preserve data upon power loss, and will still lead to filesystem corruption.

So it appears that SC has addressed your power loss issue with a fairly
inexpensive easily swappable NVRAM memory card if you feel your system
needs it.  But if you use their products your gonna lose data because
your so stupid you won't buy that or a UPS.  Uh huh. 

>Correctly implemented disk storage systems don't have this problem -- only
>those which circumvent the normal UNIX buffer cache semantics so that they
>appear to offer better performance in simple benchmarks.  

So their implemention, since it does not match with _your_ idea of
'correctness' is therefore wrong, and stupid.  Uh huh.

Disk caches are _always_ a performance win, no matter _where_ you put
them with any kind of database work.  When SC claims these phenomenal
thruput numbers I don't doubt it too much, though I'm sure the numbers
are derived from ideal conditions.  I've experimented with REAL LIVE
SYSTEMS using DPT, DTC, Buslogic, and Adaptec, controllers, the former
two with varying degree's of onboard cache from 4 to 16MB.  When doing
VERY HEAVY database work (dumping sorting, filling) for a weekend job
the additional controller cache reduced the time to complete the task by
as much as 40%.  This was not my imagination, and was not affected by
increasing the OPERATING SYSTEM buffer cache.

After all everyone knows heavier objects fall faster than lighter ones
right? (riiiiggggghhhhhttt!)

>People who want this kind of performance increase from correctly-implemented
>RAID systems can simply mount their filesystems with asynchronous metadata
>writes enabled -- but note that this can lead to filesystem corruption on
>power loss!  Of course, so does using a "RAID 7" box without NVM *at all*.

If you get bitten by a power failure you should be FIRED! This is
negligence on your part, period.  My machines stand a better chance of
getting TOTALLY stroked by lighting, fire or hurricane (flooding), than
by a power failure.  In fact I can honestly say I have _never_ taken a
filesystem hit from a power failure in the last 5 years or so on about
30 24Hr/day sites, I have however, had a complete melt (fire), Total
destruction by lightning (The modem exploded, the inside of the computer
cabinet looked like someone took an arc welder to it).  and a flood
(Real tough to salvage the disk under 6 feet of salty water on the outer
banks of NC.  All that fancy syncronous writing, and journaling is about
worthless when your disk drives are all melted, or full of salt water,
or have the spindle welded to the bearings.  That's what backups are
for.

>>BTW, how does Auspex with its optional NVM approach this?
>
>Auspex (my usual example of cached RAID which _doesn't_ suffer from filesystem
>corruption on a power hit, unlike "RAID 7") correctly handles the UNIX buffer
>cache semantics, by synchronously writing filesystem metadata to disk.  This

Christ, over and over about the power hit, preventable with a $500 UPS. 
And this 'correctly handled' shit.  You bitch about this SC clown, and
it sorta seems to me he's REALLY toned it down since about a year ago,
not to mention the fact that he has ALREADY ADDRESSED your damn totally
stupid power loss corruption issue with NVRAM.  Correct is when the boss
walks in and says, "WOW, the system is REALLY screaming, what did you
do?".

>results in some degree of performance degradation when one's creating large
>numbers of small files, but *is necessary* if you stick a cache between the
>kernel's idea of "written to disk" and the actual disk platters.  They have
>specific kernel support which guarantees that this is done correctly, so that
>the structure of the filesystem itself won't be corrupted on power loss.

Whoopie Doo.  I just change the batteries in my el-cheapo switching 2KV
or 1200VA UPS's every year.  If you are REALLY paranoid APC sells that
new stuff with hot swappable EVERYTHING to protect your valuable data. 
Christ buy a tape drive will ya.  If you have enough brains to set up
your system CORRECTLY (you seem to like that word a lot) a power failure
will shut your system down if the power stays out.

Now answer this.  What happens if the power drops suddenly while your
jargoneous 'metadata syncronous write' Let's call it a 'superblock', or
'directory block' update for us total idiots with simple minds, is
spewing data out of the write head on your disk and the accompanying
surge spewy's a whole track of the directory block into oblivion?  Hmmm?

>RAID systems which contain a cache and sit at the other end of a SCSI bus from
>the host computer *can't* handle this correctly.  Therefore, instead of

This is OPINION, _yours_.  I don't think Mr Willet denies that his
systems circumvent this syncronized writing, and in fact has stated that
this is for performance reasons.  While comparing the performance of
"RAID-7" on a 200Mhz DEC alpha running VMS, vs a PDP-11 with standard
DEC drives is pretty sleazy, you don't have to stoop to the same level
with this damn cache power loss corruption issue.

Jeezus, if your hard disk heads go digging into the media and start
peeling it off the platter journaling and syncing writes ain't gonna
help you all that much in any case.

>running the risk of losing some data in files, with such a RAID system (like
>the StorComp "RAID 7" RAID 4 implementation), you run the risk of losing *the
>entire filesystem*.  Yet for several years, this was the only kind of RAID
>system that StorComp marketed at all.  Can you say "irresponsible", kids?  I
>knew you could.

This is so full of it.  You spew techo-jargon about 'syncronously
writing metadata' Like this "RAID-7" thingy is gonna puke all over you
if you use it or something.

I clearly don't see this as an issue, and neither do most of the people
I know who do REAL work.  The people I work with want maximal
performance, with minimal risk.  I frankly don't see _any_ risk in a
straight power loss situation.  None, zippo.  You are 10 times more
likely to have the building burn down around your equipment, Unless you
don't have half your brain.  I had to go into my main site about 3
months ago on a saturday to bring the computer back up.  Someone hit the
damn power pole in front of the building with a truck, knocked out the
whole block for about 10 hours.  I have the system set to time delay
down after 60 minutes, it's on a cheapo 2KVA with an extra pair of auto
batteries (For more time).  The system shut itself down cleanly after a
half hour, and lo and behold, had automagically powered back on and
re-booted when the power came down.  I wasted a trip, but it was pretty
neat.  That is the _only_ time the system was ever off long enough to
trip in the auto-power down sequence.

If you want to argue against this "RAID-7" stuff come up with a new idea
besides data corruption on a power loss.  It is a non-issue.
--
Keith Smith <keith@ksmith.com>                  Free Usenet News/Newsfeeds
Digital Designs                                   (910) 423-4216/7389/7391
PO Box 85                                                   V.34/V.34/V.32
Hope Mills, NC 28348-0085  ... Somewhere in the Styx of North Carolina ...