*BSD News Article 61513


Return to BSD News archive

Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.eng.convex.com!hermes.oc.com!news.unt.edu!cs.utexas.edu!howland.reston.ans.net!ix.netcom.com!netcom.com!jlemon
From: jlemon@netcom.com (Jonathan Lemon)
Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux
Message-ID: <jlemonDMttxH.JyJ@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <4er9hp$5ng@orb.direct.ca> <4fg8fe$j9i@pell.pell.chi.il.us> <311C5EB4.2F1CF0FB@FreeBSD.org> <4for2b$art@park.uvsc.edu>
Date: Thu, 15 Feb 1996 17:00:52 GMT
Lines: 74
Sender: jlemon@netcom22.netcom.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:13858 comp.os.linux.development.system:17425

In article <4for2b$art@park.uvsc.edu>,
Terry Lambert  <terry@lambert.org> wrote:
>"Jordan K. Hubbard" <jkh@FreeBSD.org> wrote:
>] I don't think that the async-vs-sync metadata write issues are worth
>] debating since the whole topic is truly too subjective for meaningful
>] discussion.
>
>Bah Humbug.  See other posts in this thread.
>
>When anyone claims some operating system component is not subject
>to objective, mathematical analysis, they are mistaken.
>
>Objective, not subjective.
>
>] I would suggest instead simply trying sync vs async on your
>] own system, being as (in)cautious as you care to be in the
>] transition, and then post your experiences.  People need
>] concrete evidence here, not abstract debate.
>
>Anecdotal evidence is not evidence:
>
>   "XXX OS has not crashed while I was using it, therefore
>    XXX OS never crashes"
>

Bah Humbug indeed.  Since this was crossposted to c.o.l.d.s, I went over there
to take a peek.  Guess what I found?  Not one, not two, but at least _three_
users who have had problems with ext2fs.  Now, I'm _NOT_ claiming that this is
an inherent problem with ext2fs, and it may not even have anything to do with
the async/sync issue.  But it is "concrete evidence" (Jordan's term) to refute
the "anecdotal evidence" (Terry's term).
--
Jonathan

(clipped article follows)

In article <4ftbnl$5os@news.lth.se>, <swmike@uplift.sparta.lu.se> wrote:
>In article <u6spgfz6hv.fsf@moc>,  <M.Luebbecke@tu-bs.de> wrote:
>>In article <4foemt$mi6@charm.magnus.acs.ohio-state.edu>, 
>>                   <sviznyuk@magnus.acs.ohio-state.edu> wrote:
>>>In article [unknown], <sviznyuk@magnus.acs.ohio-state.edu> wrote:
>>>I get this occasionally when I wipeout a large directory tree.  I also
>>>would like to know what is going on.  It sounds like something is being
>>>overzealous in the destruction of blocks. :(
>>
>>It is a bug. The filesystem after I rebooted appeared to be corrupted
>>and I had to repair it with e2fsck v.0.5a from my non-ELF boot repair
>>disk. For some reason the latest and greatest e2fsck v.1.02
>>didn't want to do the job and "politely" suggested to run it
>>"manually".
>
>The same thing for me. I removed a 30Meg directory tree last night and blew
>away my filesystem... *all* copies of the superblock were corrrupted. The
>manual repair with e2fsck left me off with a unbootable machine. That hurts!

Has happened to me twice that when I woke up in the morning I had loads 
and loads of zombie sendmail, logins and such. Can't do "df", only hangs 
the shell. I do a shutdown, it can't unmount ANY partitions. I boot, it 
says my / is corrupted, please run fsck manually. I boot single user, do 
a manual fsck of / and it complains about root super block corrupt, 
please use 8193. I do so, it goes on and finds files that are linked 
together and stuff. I press "y" on all options and it goes thru. All 
other partitions (6 of them) are ok, no complaints at all apart from the 
unclean umount of them. 

Luckily I save my / every night, so I'm going to keep that archive for 
future use if I fint any corrupt files.

I'm running 1.3.57, with 152x scsi support (no scsi drives), 4 EIDE 
drives, P75 with 32 megs of ram. Upgraded Slack 2.2 to ELF and GCC 2.7.0.

Apart from this problem, 1.3.57 has been very stable for me.

Yeah, I use e2fs V1.02