Date: Fri, 20 Apr 2001 07:52:03 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Andrew Hesford <ajh3@chmod.ath.cx> Cc: niek@bergboer.net, freebsd-hackers@freebsd.org Subject: Re: UFS block size vs. write speed Message-ID: <20010420075203.T1790@fw.wintelcom.net> In-Reply-To: <20010420093530.A98970@cec.wustl.edu>; from ajh3@chmod.ath.cx on Fri, Apr 20, 2001 at 09:35:30AM -0500 References: <20010420144543.F30241@wit379119.student.utwente.nl> <20010420055426.Q1790@fw.wintelcom.net> <20010420152029.A35974@wit379119.student.utwente.nl> <20010420093530.A98970@cec.wustl.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
* Andrew Hesford <ajh3@chmod.ath.cx> [010420 07:37] wrote: > On Fri, Apr 20, 2001 at 03:20:29PM +0200, Niek Bergboer wrote: > > Isn't it true that softupdates only work when filesystems are mounted > > sync? Or does it also improve performance when filesystems are > > mounted async? > > The other guy was right; you really do need to wrap text at around 70 > lines (I have vim wrap at 72). When I try to reply to messages, it > messes up the reply text. I don't send out messages with screwed-up line > breaks, so I'm not going to help in the future if the formatting is bad. Yes, please. :) However the rest of these statements are incorrect. > Soft updates isn't an "async" or "sync" thing. It combines synchronous > and asynchronous transfers. If I'm not mistaken, all metadata is > synchronously written, and all data is asynchronously written. You're mistaken, what you're describing is the old non-async/non-softupdates way. > It also orders writes so that blocks are allocated before inodes, and > inodes before directory entries. This is why fsck is so fast: if a > directory entry exists for an inode, the file is known to be consistent, > so fsck only needs to check for claimed inodes that don't have directory > entries, and check the free-block bitmap for used blocks that don't have > inodes claiming them. Something like ext2, on the other hand, must check > every directory entry, every inode, and every free block to make sure it > is allocated properly. This is much slower. This is incorrect (afaik), in order to perform a fsck the filesystem must be snapshotted, then since the only inconsistancy that's possible with softupdates is free data that actually isn't, fsck can walk the snapshot and tell the kernel to free blocks that should be free. > But I digress... Since metadata is typically small compared to data, > particularly in your case, the synchronous transfers are trivial. > According to one paper on FFS with soft updates, I think my Marshall > Kirk McKusick, the file system speed approaches that of a memory > filesystem. Actually, with metadata being sync growth of a file can be a problem. Since the blocks allocations may be sync then without softupdates/async it could be expensive to grow a file. > Mounting the partition async would definitely speed up I/O. If you > didn't see a noticible gain in network throughput, that tells you the > bottleneck is somewhere else. Remember, too, that a network operating at > a raw 9Mbits/sec is going to be slower in real-world transfer rates, > because transfer protocols have overhead, breaking data into packets and > reassembling it takes time, and other things. Actually, as I mentioned softupdates can detect when an operation has been "backed out", sort of like a file that's created, but none of the actuall allocations have hit the disk, if that file is deleted under a softupdates filesystem you'll see no disk IO. However an async fs can't see this and will have to do the IO anyway. -- -Alfred Perlstein - [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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010420075203.T1790>