Date: Mon, 17 Apr 2000 08:45:52 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Rahul Siddharthan <rsidd@physics.iisc.ernet.in>, Rasmus Skaarup <rasmus@gal.dk>, freebsd-questions@FreeBSD.ORG Subject: Re: disc io - sync and async Message-ID: <20000417084552.E4381@fw.wintelcom.net> In-Reply-To: <20000417185653.A7455@theory6.physics.iisc.ernet.in>; from rsidd@physics.iisc.ernet.in on Mon, Apr 17, 2000 at 06:56:53PM %2B0530 References: <20000416120315.W4381@fw.wintelcom.net> <Pine.BSF.4.21.0004171300150.10236-100000@skaarup.org> <20000417185653.A7455@theory6.physics.iisc.ernet.in>
next in thread | previous in thread | raw e-mail | index | archive | help
* Rahul Siddharthan <rsidd@physics.iisc.ernet.in> [000417 06:55] wrote: > * Rasmus Skaarup <rasmus@gal.dk> wrote: > > If async operations are performed anyhow, why don't we just mount the > > drives async from the beginning. If FreeBSD chooses to mount drives in > > sync or 'non-async' mode as you say, to increase integrity, and async > > operations are performed anyway this doesn't help one bit. You still have > > problems with integrity, and the drives will just be slower.. > > > > Surely we should avoid any kind of breach in integrity, but I mean, a > > server breakdown is what it is, and having 200 inodes instead of 300 > > inodes corrupted doesn't sound like a worthy result of a much slower hard > > drive when the server is up. And even if FreeBSD only performed sync > > operations, there would still be some parts of the filesystem that are > > corrupted? > > FWIW, it seems like a machine with low load / few users is not much > hit by the performance loss of sync operations, so I've left our > FreeBSD machine with its default sync setting, and also changed a > linux machine to sync. However, we've had the power fail unexpectedly > on plenty of linux machines with async mounts, and never suffered data > loss and rarely had even to run fsck manually -- most of the time it > does an fsck with automatic corrections and continues happily from > there. No "corruption" whatever. So using sync mounts on some > machines was only because I've heard that it's safer. > > For an important server you'd be having stable power, reliable > hardware and regular backups anyway -- so it seems to me that async > would be preferable in that case, for better performance... Both of you guys obviously haven't understood what the problems with async mounts are. First of all afaik Linux's fsck concept of "corruption" is a lot less stringant than FreeBSD's or Solaris's. Linux does this to cheat FS benchmarks to the detriment of users. With 'non-async' cross linked files/directories "can't happen" under FreeBSD. A "cross-link" is when after a crash two filesystem entities "own" the same blocks on the disk. Last I checked Linux fsck will just clone the data. Let's take the worst case scenario and assume that you just rebuilt the password file database under Linux and at the same time a user just created a somewhat large file: Now since meta-data isn't consistant under async it's quite possible that the password file's inode hasn't been truncated to free it's blocks while the user's file's inode has been given ownership of the blocks on disk. *power goes out* *machine comes back up* *user suprised to find bits of your password file in his tempfile* *administrator suprised to find instance of 'crack' running on system* oh joy. Ok, considering that which do you think is a more reasonable default? Also note that last I checked in Solaris (version 7) you needed a special third-party program to turn on 'async' because I don't think they liked the concept either. Remeber, FreeBSD's default is 'non-async', not 'sync' so normal filesystem data _is_ cached, just not the meta-data (allocations/directories). As far as making softupdates the default, again you haven't read everything you're supposed to: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/ufs/ffs/README.softupdates?rev=1.7 thanks, -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000417084552.E4381>