Date: Fri, 20 Apr 2001 10:47:48 -0500 From: Andrew Hesford <ajh3@chmod.ath.cx> To: Alfred Perlstein <bright@wintelcom.net> Cc: Andrew Hesford <ajh3@chmod.ath.cx>, niek@bergboer.net, freebsd-hackers@freebsd.org Subject: Re: UFS block size vs. write speed Message-ID: <20010420104748.A99196@cec.wustl.edu> In-Reply-To: <20010420075203.T1790@fw.wintelcom.net>; from bright@wintelcom.net on Fri, Apr 20, 2001 at 07:52:03AM -0700 References: <20010420144543.F30241@wit379119.student.utwente.nl> <20010420055426.Q1790@fw.wintelcom.net> <20010420152029.A35974@wit379119.student.utwente.nl> <20010420093530.A98970@cec.wustl.edu> <20010420075203.T1790@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 20, 2001 at 07:52:03AM -0700, Alfred Perlstein wrote: > You're mistaken, what you're describing is the old > non-async/non-softupdates way. I do see both synchronous writes and asynchronous writes on my filesystem (as reported by mount); what are these? Is soft updates simply structured asynchronous writing? I always assumed that the metadata was synchronous, which accounted for mount reports. Although, in retrospect, I guess deleting a directory with many files is faster under soft updates than synchronous mounting... Now everything I know is wrong. :) > > 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. According to McKusick, there are two errors that can occur with soft updates: misallocated blocks, and misallocated inodes. Therefore, however fsck analyzes the filesystem, it must check for these problems. This means scanning for inodes that have no directory entry, and scanning for blocks that aren't claimed by any inode. > > 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. Which supports my claim that the bottleneck isn't the filesystem, but something network-related, like protocol overhead or other things. When I said mounting async would speed up I/O, I meant over synchronous writes. The original poster talked about soft updates in a way that led me to believ he wasn't using it, so I'm comparing async I/O to the I/O performance he would see. So I guess we can see that I understand a good portion of how soft updates works in theory, but I've never bothered to learn how all this allows data to be written to disk... -- Andrew Hesford ajh3@chmod.ath.cx 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?20010420104748.A99196>