Date: Mon, 12 Mar 2001 21:18:42 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Gordon Tetlow <gordont@bluemtn.net> Cc: "J.Goodleaf" <john@goodleaf.net>, stable@FreeBSD.ORG Subject: Re: Disk I/O problem in 4.3-BETA Message-ID: <20010312211841.D29888@fw.wintelcom.net> In-Reply-To: <Pine.BSF.4.33.0103121731120.2281-100000@sdmail0.sd.bmarts.com>; from gordont@bluemtn.net on Mon, Mar 12, 2001 at 05:50:09PM -0800 References: <20010312232046.D24215C09@clyde.goodleaf.net> <Pine.BSF.4.33.0103121731120.2281-100000@sdmail0.sd.bmarts.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Gordon Tetlow <gordont@bluemtn.net> [010312 17:51] wrote: > On Mon, 12 Mar 2001, J.Goodleaf wrote: > > > I don't adequately understand the difference between what you're talking > > about here and what softupdates does. I have used softupdates for some time, > > but now I'm nervous! Can you point me toward the nearest info source, that I > > might RTFM and refrain from bugging you guys? (Given that I already tried > > man softupdates and man tunefs doesn't tell me anything.) > > For the nitty-gritty. Look in the file: > /usr/src/sys/ufs/ffs/README.softupdates > > We should add a pointer to that file in LINT next to the option. > > Here's what I understand of softupdates. I'm sure I'll be corrected if I'm > wrong (at least I hope so). > > In the traditional UFS/FFS implementation, all meta-data > (inodes/directories) updates are synchronous to try to ensure that your > meta-data doesn't get corrupted in the event of a crash. Now, synchronous > kinda sucks because it's slow. > > Of course, you can run in async mode, but you raise the risk of corrupting > meta-data in the event of a crash. Linux does it this way. > > Enter softupdates. What softupdates does is change the sync calls to be > async, so you get the speed benefits of async, while guarenteeing that > your meta-data will be consistent. It does this be ordering the writes for > your meta-data so it will always be in a consistent state. ie initializing > an inode before pointing a directory entry to it, re-writing the directory > entry before you free the inode it's pointing to, etc. It's not just ordering the writes, what it does is hang a dependancy list off the buffers that say something like: you can't write _this_ out, but if you back out this change you can, so softupdates backs out the changes and flushes the buffers. The really cool part about this is that sometimes dependancies cancel each other out, take for instance really short lived tempfiles, softupdates can detect that the write to disk for the block allocation never occurred so it doesn't have to write out the bitmap twice, in fact it never has to write it once. Even a fully async mount can't do that, for the async mount you _may_ avoid two writes (one for allocation, one for freeing) because the free version (which is really just a backed out version of the allocated version) is marked "dirty" and must still be written out. This is a pretty interesting and benifitial side effect of dependancy tracking, being able to avoid no-op operations. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010312211841.D29888>