Date: Tue, 3 Nov 1998 20:12:08 -0600 From: Dan Nelson <dnelson@emsphone.com> To: Graeme Tait <graeme@echidna.com> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: File system performance Message-ID: <19981103201208.C29791@emsphone.com> In-Reply-To: <363F8F49.EE1DD0EE@echidna.com>; from "Graeme Tait" on Tue Nov 3 18:18:33 GMT 1998 References: <363F7AA3.22254A9C@echidna.com> <19981103162515.A17979@emsphone.com> <363F9963.EFF480F4@echidna.com> <363F7AA3.22254A9C@echidna.com> <19981103162515.A17979@emsphone.com> <363F8F49.EE1DD0EE@echidna.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Nov 03), Graeme Tait said: > Aha! I've learned something. I notice the vendor who configured this > system with FreeBSD had set up fstab to mount usr/obj,ports and src as > follows (/usr/www is a slice I created where the small files reside): > > /dev/da1s1f /usr/www ufs rw 2 2 > /dev/da1s1e /usr/obj ufs rw,noauto,async,noatime 2 2 > /dev/da0s1g /usr/ports ufs rw,noauto,async,noatime 2 2 > /dev/da0s1f /usr/src ufs rw,noauto,async,noatime 2 2 > > So I assume this is advantageous (and any risk acceptable) during a > make. Yes, definitely. > I guess the question is though, in the present situation, whether the > writes are being performed efficiently. There are less than a thousand > cylinders on these disks (and the area occupied by the files being > deleted would encompass far fewer cylinders). So, at least in principle, > you would think only a small number of head movements should be > required. You'll have (AFAIK; I don't really know much about ffs) at least two writes; one to clear the filename out of the directory entry, and one to clear the bits out of the freespace bitmap. Possibly more (does the inode even get touched if the link count hits zero?). The OS syncs the volume after each deletion to ensure that the filesystem is in a consistent state after each operation. > Couldn't CAM/SCSI provide some help here, by allowing the writes to be > performed in a more efficient sequence? Not really. The operations have to be done, and the limit is how fast the head can fly from directory to freespace to inode. > Could you explain (to a beginner) what "softupdates" are? I would prefer > to wait for 3.0 to stabilize, but will switch when practical. > In fact, is there some place where synch/async operation are explained? > Graeme In 2.2, a filesystem has three states, sync, async, and normal. In sync mode, all disk operations are written to disk immediately (no write cache). In normal mode, only directory entries are written immediately (directory data is always consistent). In async mode, no data is written immediately. Softupdates is a write cache that orders the cache based on the data in the cache. If it knows that an inode has been deleted but the change hasn't been committed to disk, it won't overwrite the inode or the file. If you delete subdirectory tree, it'll ensure that the deletions of the leaf directories get written to disk before the parents, etc. http://www.ece.cmu.edu/~ganger/papers/CSE-TR-254-95/ has the Ganger and Patt report explaining it in detail. Figure 3 is a graph of your particular case :) <next message> In the last episode (Nov 03), Graeme Tait said: > Wow! - the "production" system is over ***50*** times faster at file > deletion with the file system mounted async. I'd be willing to trade my > first born for that sort of improvement. The disk heads are still very > busy, but obviously in a much more efficient way. > > I do notice that it seems to withhold the final writes for about 2 > seconds (as does the Promise hardware cache). Is this behaviour > controllable? Is the data withheld, if lost (as in a power outage or > crash) just mean the disk data is erroneous, or would there be serious > filesystem damage? It depends. If all you did was deletions, you are probably okay. But imagine if you deleted that tree, then re-extracted another one. Then, halfway through, you powered the machine off. Chances are you would have some directory blocks in the "pre-delete" state, and some in the "post-extract" state. Same thing for file contents. fsck would most likely not be able to recover from this. -Dan Nelson dnelson@emsphone.com 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?19981103201208.C29791>