Date: Fri, 02 Mar 2007 17:56:04 -0600 From: Alan Amesbury <amesbury@umn.edu> To: freebsd-performance@freebsd.org Subject: Re: (S)ATA performance in FBSD 6.2/7.0 Message-ID: <45E8B994.2010100@umn.edu> In-Reply-To: <20070302120018.5830716A4A9@hub.freebsd.org> References: <20070302120018.5830716A4A9@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
O. Hartmann" <ohartman@zedat.fu-berlin.de> wrote: > If SYNC is default how can you explain this: > > [12:58]root@hater:~# mount > /dev/ad4s3a on / (ufs, local, synchronous) > devfs on /dev (devfs, local) > /dev/ad4s3d on /tmp (ufs, local, soft-updates) > /dev/ad4s3f on /usr (ufs, local, soft-updates) > /dev/ad4s3e on /var (ufs, local, soft-updates) > > [13:00]root@hater:~# cat /etc/fstab > # Device Mountpoint FStype Options Dump > Pass# > /dev/ad4s3b none swap sw 0 0 > /dev/ad4s3a / ufs rw,sync 1 1 > /dev/ad4s3d /tmp ufs rw 2 2 > /dev/ad4s3f /usr ufs rw 2 2 > /dev/ad4s3e /var ufs rw 2 2 > > And this is only because I manually add *sync* to my /etc/fstab. > > E.g if sync is default why mount do not report that my /dev/ad4s3f on > /usr is mounted synchronous? [snip] No, the default with softupdates disabled is synchronous, not asynchronous under FreeBSD. There was a thread on this years ago (back around 3.5-RELEASE?) where this was discussed in detail. (I'm too lazy to look for it.) The discussion centered around the Linux ext2 working faster than UFS/FFS and it was exactly because ext2 file systems were mounted async by default and UFS/FFS sync by default. Looking at /usr/include/sys/mount.h, I see that there are two flags defined: MNT_SYNCHRONOUS and MNT_ASYNC. I'm not sure why both flags exist, but suspect the former was added so you could mount UFS/FFS/UFS2 filesystems that had soft updates enabled in synchronous mode without having to umount the filesystem, use tunefs(8)'s "-n" flag to enable/disable soft updates, then remount the filesystem with the appropriate flag(s). To return to your original questions, though..... I'm not sure why KB/t doesn't exceed 128, but suspect that you're right about it being a buffer limit of some sort. No idea where, though, without digging through some source. My guess is that the answer is buried somewhere in the ATA DMA bus code, but that's pure speculation. I'm unsure what would cause the slowdown you mention, too. If it were PATA, I'd immediately suspect some sort of legacy device being present, e.g., an older CD-ROM drive or something. However, that's not a concern in the SATA world, and connections are (I thought) point-to-point. Perhaps it's an interrupt sharing problem? Do you have a legacy PATA controller enabled and sharing resources with your SATA controller(s)? What does 'dmesg' show for device identification, in particular which device is on which atan-[master|slave] connection? I'd be careful about running things like 'vmstat' or 'systat' with intervals shorter than five seconds, though, as some of those tools have historically had counters that didn't update meaningfully in intervals shorter than that. There's also the question of jitter, noise, whatever. Also, if you want to benchmark the filesystem code, try running tests against a memory-backed filesystem (but one that doesn't swap!) to see how well they perform. Good luck with your testing! -- Alan Amesbury University of Minnesota
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45E8B994.2010100>