Subject: Re: [netatalk-admins] 1.4b2 (with Volumesize Patch) or +Asun Patch
From: Mark Donnelly (mark@coe.missouri.edu)
Date: Tue May 19 1998 - 10:59:24 EDT
> > afpd did not hose your file system. most likely, your disk is
> > going bad, or you mounted an unclean version of it. there is
> > also the remote possibility that you've discovered a bug in
> > the filesystem code. that one is the least likely.
>
> The first Disk is new and both are well-tested with NO defects. It's NOT
> the Disks. May anyone please try to verify my discovery on a test
> partition? I'm not programmer enough to say, what's exactly going wrong.
What I think that Adrian is trying to say is that it is impossible for
netatalk itself to hose your disks. Let me explain, since (from your last
comment) you more than likely haven't had an operating systems class.
On any operating system with a good idea of "protection", (which Linux and
Rhapsody have, but MacOS and Win95 don't, which is why Norton's will never
really exist for Linux), any program that isn't the OS Kernel (vmlinux
itself) will not be able to issue instructions to touch the disk.
Instead, the "user programs" request that the kernel access the disk for
them, and then the kernel gets/puts the data, and sends a message (return
value) indicating the success.
So, I think that Adrian said that netatalk could not possibly have
corrupted your disks by itself.
That's not to say that netatalk had no fault in it whatsoever. He pointed
out a couple of possibilities for what might have happened, one of which
you have ruled out (the disk being new). The second is that the disk was
uncleanly mounted. Did you recently have a power outage, or any other
reason that your box would have rebooted without going through all its
shutdown scripts? The shutdown scripts on a UNIX box are very important.
The last possibility is the closest to what your conclusion was: That
netatalk somehow issued a series of commands that caused the kernel to
hose the disk. I realize that this is a matter of symantics (the kernel
hosed the disk on netatalk's behalf), but this is what Adrian meant by
saying that you might have found a kernel bug. If neither of the first
options fit (and the first doesn't), then the proper course is to send a
mail to the kernel developers (I _think_ that Stephen Tweedie is the main
ex2fs person, but I'm not sure...look for e-mail addresses within the
code). It should include the syslogs and as detailed description of your
system as possible.
Basically, there is nothing that netatalk should be able to do (besides
writing to /dev/hda, which I can't even concieve of happening) that should
be able to hose a filesystem. Netatalk (as all UNIX programs) is built
on the assumption that the OS will prevent it from doing any damage,
especially if it just sticks to the standard system calls. If netatalk
_is_ hosing it, then the kernel needs to be modified to not allow that.
Adrian, I hope I didn't put too many words in your mouth...
Patrik, I hope this clarifies a little.
--Mark Donnelly
"I think so Brain, but if they called them sad meals, then nobody
would buy them."
--Pinky
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:32:43 EST