Date: Mon, 12 Mar 2001 17:50:09 -0800 (PST) From: Gordon Tetlow <gordont@bluemtn.net> To: "J.Goodleaf" <john@goodleaf.net> Cc: <stable@FreeBSD.ORG> Subject: Re: Disk I/O problem in 4.3-BETA Message-ID: <Pine.BSF.4.33.0103121731120.2281-100000@sdmail0.sd.bmarts.com> In-Reply-To: <20010312232046.D24215C09@clyde.goodleaf.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Now with softupdates, you guarentee that you have a consistent set of meta-data. Even if you crash, fsck doesn't need to do a whole lot because you are guarenteed that your filesystem isn't corrupted. Now imagine if your HD lied about whether that meta-data write actually made it to disk or not. Here's a picture. You make a new directory (/usr/obj) and populate it with stuff (buildworld). Suppose everything made it to disk except the /usr/obj dir (after all, the HD is holding it in the cache). Then you crash. When the system comes back up, the /usr/obj dir would be gone. That would be bad. esp compounded by the fact that fsck doesn't actually do a full sweep of the meta-data like it used to. It figures that the fs is in a consistent state and continues on. In short, it is imperative that the hd actually writes out the data upon request for softupdates to work. -gordon 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?Pine.BSF.4.33.0103121731120.2281-100000>