Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:16977 comp.os.linux.advocacy:2697 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!constellation!news.ysu.edu!usenet.ins.cwru.edu!howland.reston.ans.net!news.sprintlink.net!sundog.tiac.net!tencats.tiac.net!rmk From: rmk@tiac.net (Rick Kelly) Newsgroups: comp.os.386bsd.questions,comp.os.linux.advocacy Subject: Re: Best platform for INN server? Followup-To: comp.os.386bsd.questions,comp.os.linux.advocacy Date: 5 Mar 1995 19:33:59 GMT Organization: The Internet Access Company Lines: 36 Message-ID: <3jd3n7$q9@sundog.tiac.net> References: <199503020229.SAA11325@kitana.org> <MICHAELV.95Mar1233040@MindBender.HeadCandy.com> <3j657b$j2d@sundog.tiac.net> <1995Mar3.140152.14952@wavehh.hanse.de> <MICHAELV.95Mar3212204@MindBender.HeadCandy.com> <1995Mar5.161801.26168@wavehh.hanse.de> NNTP-Posting-Host: tencats.tiac.net X-Newsreader: TIN [version 1.2 PL2] Martin Cracauer (cracauer@wavehh.hanse.de) wrote: : > Remember: fsck can clean up the filesystem metadata if you crashed (and : > metadata is the only thing the FFS tries to do synchronously), so why : > pay the overhead of doing the same thing at runtime? Yes, you can get : > such corruption that fsck gives up in horror but if you had that bad a : > crash, you'd probably have been screwed anyway even with synchronous : > write. How many of you have gotten that kind of filesystem corruption : > under linux without it being a device driver of hardware problem (which : > a filesystem couldn't fix anyway)? : > : > Final question: what's the use of "safe filesystems" if the hardware : > itself isn't safe? Who do you think you're kidding? If the harddisk : > crashes on you (or even gets just one bad sector) you won't be safe even : > if you write *everything* synchronously. So why take the performance : > hit? (yes, I know about RAID etc, and I don't care. I don't have that : > kind of hardware, and I don't think most people here wanting a "safe" : > filesystem do either). Somewhere there is a wonderful world with electricity that never fails. I guess it must be Finland. We have a fairly large newsfeed where I work. Owing to the availability of hardware, I am forced to keep the newspool, /usr/local/news, and all other news related data on one large hard disk. With asynchronous writes I would be forced to recreate the news system every time the power went out, or if there were a spike or brownout. The news server is running SunOS 4.1.3, and I have never lost data under any of the above events. More to the point, Progress would not be ported to an OS that exhibits this behavior as its default. People who use databases want integrity, as well as speed. -- Rick Kelly rmk@tencats.tiac.net rmk@rmkhome.com rmk@progress.com