From owner-freebsd-stable@FreeBSD.ORG Fri Mar 28 15:04:33 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27391106564A for ; Fri, 28 Mar 2008 15:04:33 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id D4F648FC15 for ; Fri, 28 Mar 2008 15:04:32 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.2/8.14.2) with ESMTP id m2SESilK070842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Mar 2008 09:28:44 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.2/8.14.2/Submit) id m2SESiDH070813; Fri, 28 Mar 2008 09:28:44 -0500 (CDT) (envelope-from dan) Date: Fri, 28 Mar 2008 09:28:44 -0500 From: Dan Nelson To: Ivan Voras Message-ID: <20080328142843.GD28690@dan.emsphone.com> References: <47EBA3AB.40307@infracaninophile.co.uk> <200803280029.08136.danny@ricin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 7.0-STABLE User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: Question about file system checks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2008 15:04:33 -0000 In the last episode (Mar 28), Ivan Voras said: > Danny Pansters wrote: >> Generally I can say that with freebsd even if you pull the plug and >> then let it reboot and do the automatical background fsck you'll >> likely loose only that one file you might have been editing while >> (or just before) you unplugged the box. > > Stress testing I've done suggests otherwise :) I've literally > repeatedly pulled the plug of a server in a controlled environment, > and with a network logging of (a high load of) file system > operations. My results show that UFS+SU and ZFS on FreeBSD loose *the > most* files (and in case of UFS+SU especially directories), than any > of: jfs, xfs, reiser3 (on Linux 2.6.22) and NTFS (on Windows 2003 > Server). ext3 is somewhat similar to UFS+SU, though about 30% better > at not loosing files. Note that you can tweak the SU caching time by adjusting the sysctls kern.{meta,dir,file}delay. Take them down to 10 seconds instead of 30 and you'll lose less files (at the cost of more disk I/O of course). > Some other notes from this proceeding: > > 1. UFS+gjournal looses the least, but it's also the slowest. > 2. UFS+SU had no truncated files or files of unexpected length (apparently > it just looses the file that would end up in this state) > 3. XFS and JFS end up with a *huge* number of files that are truncated or > of unexpected length (40%-50%!) > 4. In no case has any of the above file systems gone completely corrupted > or lost any of the files/directories not being updated. > 5. ZFS on FreeBSD was the fastest, in the sense of creating the most files > during this benchmark (though speed was not the target for this benchmark > so this is a low-quality observation), closely followed by JFS and XFS. ZFS's transaction commit interval is only 5 seconds (see txg_time in uts/common/fs/zfs/txg.c); how many more files/second did it create vs the others to be able to lose the most files in that window? :) > 6. ZFS crashed the kernel at least once. -- Dan Nelson dnelson@allantgroup.com