Subject: Linux-Development Digest #822
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Sun, 12 Jun 94 10:13:07 EDT

Linux-Development Digest #822, Volume #1         Sun, 12 Jun 94 10:13:07 EDT

Contents:
  Re: Filesystem semantics protecting meta data ... and users data (Totally Lost)
  Re: Linux ext2fs vs. ufs vs. presto [was Re: Fast File System?] (Kevin Brown)
  Re: WordPerfect printing (Brandon S. Allbery)
  Re: Filesystem semantics protecting meta data ... and users data (Totally Lost)
  g++ for Linux... broken? (David Young)
  All add-ons for the Kernal (Lutz Behnke HiWi)
  Re: Filesystem semantics protecting meta data ... and users data (Kevin Brown)

----------------------------------------------------------------------------

Crossposted-To: comp.benchmarks,comp.sys.sun.admin
From: idletime@netcom.com (Totally Lost)
Subject: Re: Filesystem semantics protecting meta data ... and users data
Date: Sat, 11 Jun 1994 00:16:41 GMT

In article <Cr3Fz6.CJt@ucdavis.edu>,
Kevin Brown <kevin@frobozz.sccsi.com> wrote:
>The suggestions that you have will help, but they're not quite good
>enough, particularly on a complex system.  Ultimately, there is no
>substitute for a good system administrator.

99% of the unix facilities in the world run without a knowlegable
system administrators ... in nearly every city I know of there
is a unix system hosting a Point of Sale system in a major store.
But what really scares me are the number of critical mission
implementations that use unix ... including processing prescriptions
at many of the key hospitals and drug stores.

Unless unix can be reduced in complexity and increased in reliablity
the DOS/NT market will kill it ... Programmer workstations are
very nice ... the other 99.99% of the market is hosting production
applications on servers and desktops.

>Your point is well taken, but if the hostile user is at the power switch,
>then I'd suggest you have significantly worse security problems then the
>one you present above.

This clearly is not the main threat, but only a few percent of the work
stations are on UPS's ... and while the machine door may be locked nearly
any hacker can figure out how to cut part or all the building power from
the utility closet or distribution system outside the building.

Every major OS has atleast one well known kernel panic bug that will
work just as good.

>
>>I've raised this point a dozen times, even at the usenix meeting where the
>>Berkeley guys first presented their concept of sync written meta data ...
>>and they didn't have a clue since they were one-tracked on making the
>>system clean from fsck point of view ... not from the users or data base
>>managers point of view. If the users/production data is corrupt, the
>>filesystem is corrupt!! PERIOD!!
>
>True.  However, in that particular case the damage is likely much more
>localized.  The system administrator may have to restore some files from
>backup, but much less than restoring the entire filesystem.

The files we are talking about are receintly created, and have no backup.
Furthermore in a production environment they are most likely cataloged
or have a strict relationshiop with other data in a production database.
Few production databases have the equivlent of FSCK to clean both the
data base meta data AND the production data it contains. Most often
records are not checksumed and bad/corrupt records can not be determined.
To proceed after a crash requires reloading from a known checkpoint
and processing the journal/transaction log prior to the crash, or
a payer and blind faith the error doesn't put you out of business.

If the error is in your financials you might just have your bank balance
high by 10-20% of monthly cash flow ... and be out of cash and out
of business when your payroll bounces at the end of the year and quarterly
tax deposits are due. WC Grant stores and warehouses closed in the early
70's when they ran out of cash during expansion and switchover from the
1440's to the 360 finacial systems they were unable to balnace the
books for several months due to some very stupid decisions about how
to manage the cutover as I heard the story many years ago..

>You ultimately can't compensate for stupid system administrators.  While
>more orderly filesystem updates will help, the *real* solution is to get
>a good system administrator.

The best systems admin is helpless when blinded to problems by the
tools he must trust.

>>      1) require that all data be written prior to the referencing
>>         meta data. File data blocks first, followed by Nth level
>>         indirect blocks, ...., 1st level indirect blocks, inode.
>
>This makes sense as long as you don't care too much about file data
>integrity.  You mention a possible solution to this problem (write
>new data blocks), but that has its own set of problems (e.g., low-
>space situations).

Get a clue ... this entire thread is about CARING about the data!
geez. Stop and re-read it, you are in too big a hurry to look dumb.

>>         If a file is open for writing, and written other than at
>>         EOF, the disk inode is updated with a a dirty flag, which
>>         is cleared when the file is closed or specifically "sync'ed".
>
>Suppose a file is marked as "dirty", the system crashes, and the
>operator has to bring the system back up.  When it comes up, the
>file is still "dirty", but what is the operator to do about it?
>Restore it from backup?  This is not at all a proper solution if
>the "dirty" file is part of a multi-file database.  Restoring the
>file from backup while not restoring the other (presumably clean)
>files will yield an inconsitent database.

How to recover from a dirty file can vary widely, but that is not the
issue ... how to recover when you don't know which files might be
dirty is even a tougher problem that MUST be solved. The file might
not even be dirty, just have it's dirty bit set,  but atleast the
sysadmin, production managers, users and programer's have a hint
where to look ... and an incentive to write tools to deal with the
problem rather than ignore it ... or not even know.

In my mind anny application that doesn't keep a journal/transaction
log is in trouble to start with. If the journal is built  with before/after
records it can be used to verify in reverse the database until
a recient checkpoint.

>Situations like this simply underscore the fact that there is no
>substitute for a system administrator that knows what he's doing
>(and knows what his users are doing.  The file above may be part
>of a user's *personal* database, rather than a systemwide one).

Are pushing some sysadmin union to control the world? machines should
be designed to seldom have unreconcilable problems. As I said before
till unix machines require the same level of maint/support as a dos
or mac system ... we might as well just give up and go home rather
than prolong the dos/nt/novelware/mac takeover.

>>         All filesystem file data and meta data will be clean at any
>>         interruption of service, with the detectable exception that
>>         a file/database may be internally inconsistant.
>
>This cannot be guaranteed, particularly if the interruption occurs
>in the middle of a write operation to the middle of a file.
>Requiring that new blocks be written will help enormously here,
>though.

the only guaranteed outcome in life is our death and that somebody
else will be doing our job afterward ... if it was worth doing.

To use algorithms that are fundamentally wrong is only useful for
job security of the person inisting they shall be wrong. Too everyone
else it creates one more fire and one more disaster waiting to threaten
their job/company/life.

>
>>      2) any other write policy requires a filesystem to be reload
>>         from backup media if service is interrupted while mounted.
>
>This may well be required anyway, even *with* the ideas you suggest.

only for a poorly constructed  complex application. Normal desktop
services and most server environments can be made to be clean.

>
>>Item one can be extended to require updates to existing filedata be done with
>>new data blocks, and new meta data, which only is reflected to the
>>disk inode when the file is closed or a commit operation performed.
>
>Yup.  But this can be a really significant problem in low-space
>situations, particularly if the files being updated are large.

actually the only size the matters is if the trasaction exceeds free space
on the disk ... if you are that close to running out of space in an
environment that uses huge transactions then the programmer needs the
standard "were are out of memory, if you wish to continue we will be unable
to undo this action without relaoding the disk" message.

>
>>When done properly with locking operations this makes a system database
>>safe as well.
>
>Certainly safer than with existing filesystem policies.

you seem not expect much .... Managers and designers with this attitude
need to be replaced with ones that have strict standards AND the ability
to compromise with reason with reality gets in the way.

In this case, IT IS POSSIBLE TO PROVIDE SAFE SERVICES, which include
the tools to make incomplete operations consistant after a crash..
I expect a small number of very complex multi-host networked application
might have reality intruded ... but for standard single host multiple
process environments I see no problem for providing the tools for
applications programmers to build 100% operationally correct systems
which includes handling abnormal events like disk failures.

>
>>This policy is neither difficult to implement, nor a significant performance
>>hit ... and in fact when done with better algorithms than UFS can be
>>3-10X faster.
>
>Do you have any references in the literature to performance analyses
>of such schemes?  I don't imagine the performance hit would be that
>significant, because the only effect I can see off the top of my
>head is the queueing of data in the various passes of the elevator
>algorithm...
>
>You'd have to get rid of the idea of a simple buffer cache, though
>(would a cache with priority levels be sufficient?).
>

geez ... back to follow the herd thinking, Do you know of a system that
has implemented this? If one major vendor had, they would be beating
their chests in the trade press about everyones elses problem. The first
kid on the block here has a major selling angle.

And no a priority scheme dosn't address the deata relationships properly
for reasonable performance. Simply assigning 5 to inodes ... and 1 to
data blocks will cause the cache to fill with non-data blocks and prevent
timily writing. As one other thinking reader deduced it takes threading
requests and a disk sort routine that cooperates with the filesystem.

John

------------------------------

Crossposted-To: comp.sys.sun.admin
From: kevin@frobozz.sccsi.com (Kevin Brown)
Subject: Re: Linux ext2fs vs. ufs vs. presto [was Re: Fast File System?]
Reply-To: kevin@frobozz.sccsi.com (Kevin Brown)
Date: Sat, 11 Jun 1994 00:10:48 GMT

In article <2t9n7r$jc9@sun.cais.com>,
Eric Youngdale <ericy@cais.cais.com> wrote:
>In article <Cr5HEy.1I9@ucdavis.edu>,
>Kevin Brown <kevin@frobozz.sccsi.com> wrote:
>>The fact that I was running the cluster patches is important.
>>Before, the entire filesystem would by sync()ed every 30 seconds
>>or so (I actually had it set for something like 5 minutes to get
>>better performance under the conditions my system runs).  Between
>>these periods, the filesystem on disk was reasonably likely to be
>>in a consistent state.  But the cluster patches changed things such
>>that the system is *continuously* writing to the filesystem, if
>>only because there are periodic processes which access (for read)
>>files on the filesystem, causing the filesystem to update the access
>>times of all accessed files.  Indeed, I can see the hard drive
>>being accessed every 5 seconds, the default update period for
>>bdflush().  This significantly increases the probability that
>>filesystem damage will occur if a crash happens.
>
>       No, it *decreases* the probability.  That was the whole point of 
>that patch, to reduce the degree of corruption if the system goes down 
>for some reason.

Actually, I thought the point was to increase performance.  :-)

What you say is true...when the buffer cache isn't enough to keep
data from being flushed to the disk before a sync() would normally
occur anyway.  This, of course, depends on a number of things like
the system I/O load, the size of the buffer cache, the kind of I/O
that's happening, etc.

My system remains relatively inactive most of the time.  The vast
majority of operations that are performed on it are reads.  Since
I have 16 meg, the buffer cache is generally large enough that
writes can usually be cached until a sync() occurs, at which point
all the dirty buffers are flushed at once.  This is certainly the
case when *only* reads are happening, since only metadata (like
inodes) are being affected (and thus would need to be flushed),
and thus only a few blocks need flushing to disk when the next
sync() happens.

When a crash of my system happens using a kernel without the cluster
diffs, the system is likely *not* writing to the disk, so the
filesystem on disk is likely to be consistent upon rebooting.

Bdflush causes dirty buffers to be flushed more continuously.  For
this reason alone, the filesystem on disk is more likely to be
inconsistent when a crash happens, because a crash in the middle
of a write is much more likely than the case where a single sync()
flushes all the data every 30 seconds or so (I was actually sync()ing
every 5 minutes.  Does this tell you how inactive my system usually
is?).

>>The SCSI device driver has been rock-solid reliable in writing data
>>correctly to my fixed disks, and when it *does* write data to my
>>MO drive it does so correctly.  It's just that it likes to lock up
>>if I beat on my MO drive too much, especially if there's other
>>activity (such as serial port activity) going on.
>
>       This says a lot to me.  If you pound on the drive too much
>and tickle some hardware bug of some kind that causes a drive to go insane, 
>I do not see how you can expect much of anything in the way of filesystem 
>integrity.

Yes, I agree...if the system is trying to write to one or more
mounted devices at the time.

I should be more specific about the problems I have experienced.

I can pound on the drive all I want and not experience any
problems...provided that I do so with a single process and without
any serial activity happening at the same time.

When there are multiple processes accessing the MO drive, the
probability of a SCSI hang goes up significantly.  When I attempt
to access the MO drive during a flurry of serial activity, a SCSI
hang is very likely to occur.

The fact that, from Linux, I can reliably access my MO drive with
a single process without serial activity, indicates to me that the
hardware is likely not at fault here...unless the SCSI driver
behaves differently when there are multiple processes attempting
to access a single device.

Or...and I haven't tested this yet...perhaps this bug only shows
up when multiple processes are trying to access the drive with at
least one of them going through the *raw* device.

It may be that I wouldn't have tickled the problem at all if I
didn't have a process that periodically (every 4 seconds) opened
the raw device for reading.  I had this process running because
the MO drive doesn't properly report media changes to the kernel
(I have *no* idea why), but transitions between the device being
readable and unreadable cause the kernel to decide that a media
change has taken place.  The periodic process was designed to force
the kernel to recognize media changes when they actually happened.

If I run an fsck and a dd on the MO drive (via the raw device,
/dev/sdb) at the same time, at least one of them will usually wedge
in the kernel (continuous ps status D).  Often both will, at least
for some period of time.  Often they will wedge permanently, such
that I have to kill them.  This is evident by the fact that during
these inactive periods, the drive itself is inactive and neither
process is using CPU, for extended periods of time (e.g., 1 minute).
If I recall correctly, further attempts to use the drive (by another
process), even for brief moments (e.g., reading one block), would
often also wedge.  They were sometimes killable, but not always.

I should note too, that the MO drive gives me zero problems under
DOS, no matter how hard I beat on it (not much of a surprise,
really).  Furthermore, I've never had any problems whatsoever with
the fixed disks under either Linux or DOS, so I think it's unlikely
that there's a hardware fault in the controller (Bustek 542B).  Are
there any known hardware problems with the Bustek 542B?

It may be that I need better cabling to the MO drive, but I hardly
see how I could reliably access the drive at all from either Linux
or DOS if this were the problem.  Where can I get a good external
cable (with the Centronics-style 50 pin connectors) of at least 3
feet?

Lastly, how can I go about further characterizing this problem?
When the SCSI system hangs, the entire disk system is dead in the
water because (aside from the floppies) I don't have any other disk
subsystems.



------------------------------

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: WordPerfect printing
Date: Fri, 10 Jun 1994 21:43:48 GMT

In article <2t9pen$faa@hydrox.cs.umd.edu>, hdesiato@cs.umd.edu (Hui-Hui Hu) says:
+---------------
| Does anyone know the price offhand of upgrading (downgrading?)
| WP51 for DOS to WP51 for SCO? How reliable is SCO WP?
+------------->8

WordPerfect Corp. is generally *very* reasonable about such things.  And the
SCO port seems to be fairly reliable.  At least, I haven't reproduced the bugs
in the SunOS version yet under SCO...

WP6 for SCO should be out within about a month.

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
The FUDs at Microsoft are shouting "Kill The Wabi!"

------------------------------

Crossposted-To: comp.benchmarks,comp.sys.sun.admin
From: idletime@netcom.com (Totally Lost)
Subject: Re: Filesystem semantics protecting meta data ... and users data
Date: Sun, 12 Jun 1994 13:35:42 GMT

In article <2td5jm$1rl@apollo.west.oic.com>,
Matthew Dillon <dillon@apollo.west.oic.com> wrote:
>
>    This whole thread is silly.  You people are talking about security
>    concerns related to a tiny window that may occur during a crash.

First, it is not a tiny window on most UFS implementations. Secondly,
I did not make a point of that it almost always exists in one file or
another due to both sync metadata updates and the fact that since the
metadata is allocated before the data it references it will mostly sort
ahead of the data in the disk queue. The fact that most data is non-human
readable and most people when they find trash don't bother to figure out
what it is obscures the problem. If your point of view is a workstation
with a single user, you are right ... since the I/O system is idle
98% of the day. If you are talking any server or multiuser system that
is really used to update files/databases then the window is open nearly
all the time.

As for the rest of your beef, please take it where it belongs and don't
attach it to other problems for arguement sake. I addressed a valid
major bug that needs to be fixed ... we can take the other design issues
to comp.os.research (a moderated forum) so they can be discussed without
needless useless flaming.

>     ... I, personally, would rather throw my resources into solving the
>    basic problem -- the kernel design. [then goes on about using mach
>    and micro-kernels]

Jump in then think (??) ... In bringing out this other greater problem
you put the cart before the horse ... so to speak, and the resulting
control problems are near impossible ...

"Performance by Design" is my motto ... the basic problem is System Design,
which includes Applications, Kernel API, the Operating System, and the
host hardware platform. Software bloat, creaping featurism, poor partitioning
of the overall design (application, OS and hardware components) and more
contribute to the problem. Your pointing to a little hole in the dam and
saying quick put a rock here (use a micro kernel) ignores the structural
problems behind the hole.

>    process... even if your system 'crashes' to an user-unusable state, the
>    chances of filesystem corruption are drastically reduced.

and this is the shithead point of view I opened this talk with ... accepting
that filesystem corruption is a valid tradeoff is wrong and only leads to
less optimal designs, both from a performance and security view point.

Personally I don't want anyone with this view any where near a kernel.

John

------------------------------

From: dyoung@superdec.uni.uiuc.edu (David Young)
Subject: g++ for Linux... broken?
Date: 11 Jun 1994 01:06:22 GMT

        I'm writing a ray tracer in C portable to any sort of
UNIX: AIX, Linux, ULTRIX, IRIX, UNICOS, SunOS, etc.

        Because my code looks really nasty in C, I'm porting it
to C++.

        I like to do some coding on my Linux box at home as well
as the RS/6000 w/ AIX on campus. Problem: the executables
generated by g++ on Linux don't work. (The same Makefile and
source code makes a perfectly good binary for AIX, though.)
What happens is that a function fresnel() is somehow called.
In the course of execution that the program is expected to
take (and I should know how it's supposed to run 'cause I
wrote it :-), that function should never be called.

        Another program, written by a more expert C++ programmer than
I, will make a crappy executable, too. It works fine for him on
other machines (except for his Linux box), and it makes a working
executable for the RS/6000 I use....

        Has anyone else experienced unusual problems w/ g++ & Linux?
Have I perhaps misconfigured g++? How might I reinstall it so
that it works? Mail me at dyoung@superdec.uni.uiuc.edu if you
can suggest anything or if you've experienced similar problems.

Dave


------------------------------

From: behnke@tu-harburg.d400.de (Lutz Behnke HiWi)
Subject: All add-ons for the Kernal
Date: 8 Jun 1994 14:00:12 GMT

Hello world! (Linuxers in specific)

Is there an document in existance, that list all the Kernal add-ons.
As a newbie I'm sometimes confused what was an add-on, and was has wnadered into
the standard kernal release.
With add-on I'm thinking about ide-patch and other stuff that I've read refferences
to.

If no such list exists, send me _E-MAIL_ about the things you know,
and i'd be all to happy to compile such a list.

mfg

Lutz

| Lutz Behnke | behnke@tu-harburg.d400.de |(Germany) +40 / 630 39 38 |
|  TU Hamburg Harburg, Hamburg, Germany, Europe, Earth, Sol-System   |
|----------When the Evil Spirit armed the Tiger with claws,----------|
|----------------Brahma gave wings to the Dove-----------------------|



------------------------------

Crossposted-To: comp.benchmarks,comp.sys.sun.admin,comp.security.unix
From: kevin@frobozz.sccsi.com (Kevin Brown)
Subject: Re: Filesystem semantics protecting meta data ... and users data
Reply-To: kevin@frobozz.sccsi.com (Kevin Brown)
Date: Sat, 11 Jun 1994 00:23:18 GMT

In article <idletimeCr7F84.8FF@netcom.com>,
Totally Lost <idletime@netcom.com> wrote:
>Every production machine I see is killed by UNIX filesystem I/O
>running at 10-20% of what it should be ... by filesystems designers
>that insist on using a horse and buggy as the prototype for a space
>ship. The receint software bloat caused by X/Motif applications
>continues the pressure on the I/O subsystem, combined with
>increadibly faster processor technology the pressure to
>replace or rearchitect UNIX will continue into the 90's.
>
>As with my comments about Raw I/O in comp.os.rsearch the critical
>problem is people attempting to continue to use outdated decisions
>without re-evaluation of the assumptionas and tradeoffs involved.
>The current UNIX filesystem architecture is critically flawed
>on all major fronts - performance, reliability and security - and
>lacks key features of the main frame market it replaces.
>OS work today is done mostly by follow the herd, critical thinking
>is a lost art.
>
>Either Novell and the key players need to get the clue, or UNIX
>will be replaced in the passing of time (the 90's).

You claim to have the understanding.  You claim (implicitly) to
have the expertise and the ability.

So why don't *you* write an efficient, secure filesystem for Linux
(or one of the free versions of BSD, if that suits you better,
though they may be a bit more entrenched in tradition than the
Linux developers)?  You have the source code, so you can make any
changes you need to in the interfaces, drivers, etc. to make it
happen.  You might even be able to work with the people who wrote
the device drivers.

Am I right that a priority-based buffer cache would be sufficient
to get the characteristics you need for the reliability and security
requirements?



------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************
