Return to BSD News archive
Xref: sserve comp.os.linux.misc:29260 comp.os.386bsd.misc:4028 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!caen!sol.ctr.columbia.edu!howland.reston.ans.net!cs.utexas.edu!news.cs.utah.edu!news.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (Terry Lambert) Newsgroups: comp.os.linux.misc,comp.os.386bsd.misc Subject: Re: LINUX SUCKS!!!! Date: 9 Nov 1994 01:54:14 GMT Organization: Weber State University, Ogden, UT Lines: 45 Message-ID: <39pa46$f8q@news.cc.utah.edu> References: <385viv$8r4@newsstand.cit.cornell.edu> <CHRISB.94Nov1123540@stork.cssc-syd.tansu.com.au> <39mk0hINN1uab@rs1.rrz.Uni-Koeln.DE> NNTP-Posting-Host: cs.weber.edu In article <39mk0hINN1uab@rs1.rrz.Uni-Koeln.DE> se@fileserv1.MI.Uni-Koeln.DE (Stefan Esser) writes: ] Synchronous means "do things ordered", while asynchronous ] means "don't care in which order things get done". ] The BSD FFS does an fsync() before the (synchronous) metadata ] update. [ ... Some minor nits -- I agree with the majority of this posting ... ] Not quite. In the file system sense, synchronous means "wait until you know it's on the disk" and asynchronous means "wait until it has been scheduled to be put onto the disk". It's not really necessary to preserve the synchronicity of the transaction as long as you preserve the ordering. Many caching SCSI controllers and my new Quantum hard drive take adavantage of this fact. In a log structured file system, this could be considered as transaction order rather than operation order; as long as the order is maintained, synchronicity is largely irrelevent. ] The "get your facts right" was directed at the person ] who just claimed that BSD systems and the BSD FFS didn't ] work reliable at all, and that is total nonsense, as ] prooved by a lot of FTP archive sites all around the ] world. In the BSD FFS rewrite, there *were* a number of instances of overanxious optimization of synchronus to asynchronus operations. Specifically, one sore point is a directory block write in ufs_dir.c that is done async instead of sync. Correcting this small bug closes greatly the window of vunerability in BSD FFS that results in things showing up in lost+found. After making this modification, I have not lost a directory entry to the lost+found directory for in excess of a year despite many crashes while kernel hacking. This beats Veritas' VXFS record by quite some time on the same machine. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.