From owner-freebsd-fs@FreeBSD.ORG Sun Jan 7 23:50:46 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9513F16A407 for ; Sun, 7 Jan 2007 23:50:46 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from mailhost.tao.org.uk (transwarp.tao.org.uk [87.74.4.34]) by mx1.freebsd.org (Postfix) with ESMTP id 12C3B13C46B for ; Sun, 7 Jan 2007 23:50:45 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from genius.tao.org.uk (unknown [202.128.119.92]) by mailhost.tao.org.uk (Postfix) with ESMTP id 5E79A652C for ; Sun, 7 Jan 2007 23:21:03 +0000 (GMT) Received: by genius.tao.org.uk (Postfix, from userid 1000) id 1E6A440B7; Sun, 7 Jan 2007 23:20:56 +0000 (GMT) Date: Sun, 7 Jan 2007 23:20:55 +0000 From: Josef Karthauser To: freebsd-fs@freebsd.org Message-ID: <20070107232055.GA2450@genius.tao.org.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline User-Agent: Mutt/1.5.11 Subject: Trouble booting second ide drive (gmirror configuration). X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2007 23:50:46 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm scratching my head trying to work out why I can't boot onto my second ide drive at the boot: prompt. I have a perfectly valid partition on it, which I can mount successfully when the system is booted from the other disk, but the boot loader says that the disk label is corrupt. What am I doing wrong? So, here are the details. The machine is a: FreeBSD X 5.5-STABLE FreeBSD 5.5-STABLE #7: Mon Oct 2 15:55:35 BST 2006 joe@X:/usr/obj/usr/src/sys/KERNEL i386 There are two ide drives, ad0 and ad1. # disklabel ad0 # /dev/ad0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 2097152 0 4.2BSD 2048 16384 28552=20 b: 6291456 2097152 swap =20 c: 240107427 0 unused 0 0 # "raw" part, = don't edit d: 41943040 8388608 4.2BSD 2048 16384 28552=20 e: 41943040 50331648 4.2BSD 2048 16384 28552=20 f: 41943040 92274688 4.2BSD 2048 16384 28552=20 g: 105880000 134217728 4.2BSD 2048 16384 28552=20 # disklabel ad1 # /dev/ad1s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 2097152 16 4.2BSD 2048 16384 28552=20 c: 240099488 0 unused 0 0 # "raw" part, = don't edit disklabel: partition c doesn't cover the whole unit! disklabel: An incorrect partition c may cause problems for standard sys= tem utilities The c partition is the wrong size because this is actually a gmirror partition once gmirror is loaded. However the device /dev/ad1s1a can be mounted without problems: # mount /dev/ad1s1a /mnt # ls /mnt .cshrc SYNC2 data jails root usr .profile bin dev lib sbin var .snap boot dist libexec stand webs COPYRIGHT boot.config entropy mnt sys NEW cdrom etc proc tmp SYNC compat home rescue users So when I boot the machine, and attempt to boot the second drive I get this: FreeBSD/i386 boot Default: 0:ad(0,a)/boot/loader boot: 1:ad(1,1,a)/boot/loaderConsoles: serial port =20 BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS 640kB/2095040kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (joe@X, Fri Apr 29 09:46:27 BST 2005) can't load 'kernel' Type '?' for a list of commands, 'help' for more detailed help. OK show LINES=3D24 acpi_load=3DYES comconsole_speed=3D9600 console=3Dcomconsole currdev=3Ddisk2s1a: hint.acpi.0.oem=3DGBT =20 hint.acpi.0.revision=3D1 hint.acpi.0.rsdt=3D0x7fef3000 interpret=3DOK loaddev=3Ddisk2s1a: prompt=3D${interpret} OK So it manages to load the boot loader from the correct device, but somehow fails when it comes to loading the kernel. I'd really appreciate some suggestions. Thanks, Joe --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iEYEARECAAYFAkWhgFcACgkQXVIcjOaxUBYcNQCdH/oQKeVRQY6KOlNtHH55ifGd Vb4AoMKZXmRxlmMoUFto0MgXwaI1sQzB =aR1E -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- From owner-freebsd-fs@FreeBSD.ORG Sun Jan 7 23:56:12 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E82416A403 for ; Sun, 7 Jan 2007 23:56:12 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from mailhost.tao.org.uk (transwarp.tao.org.uk [87.74.4.34]) by mx1.freebsd.org (Postfix) with ESMTP id 19AB113C4A5 for ; Sun, 7 Jan 2007 23:56:09 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from genius.tao.org.uk (unknown [202.128.119.92]) by mailhost.tao.org.uk (Postfix) with ESMTP id BBF705CAC for ; Sun, 7 Jan 2007 23:56:08 +0000 (GMT) Received: by genius.tao.org.uk (Postfix, from userid 1000) id 2CD8140B7; Sun, 7 Jan 2007 23:56:04 +0000 (GMT) Date: Sun, 7 Jan 2007 23:56:04 +0000 From: Josef Karthauser To: freebsd-fs@freebsd.org Message-ID: <20070107235604.GC1750@genius.tao.org.uk> References: <20070107232055.GA2450@genius.tao.org.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+nBD6E3TurpgldQp" Content-Disposition: inline In-Reply-To: <20070107232055.GA2450@genius.tao.org.uk> User-Agent: Mutt/1.5.11 Subject: Re: Trouble booting second ide drive (gmirror configuration). X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2007 23:56:12 -0000 --+nBD6E3TurpgldQp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 07, 2007 at 11:20:55PM +0000, Josef Karthauser wrote: >=20 > FreeBSD/i386 bootstrap loader, Revision 1.1 > (joe@X, Fri Apr 29 09:46:27 BST 2005) >=20 I thought for a second that perhaps there was a dependancy problem in the build, and that I didn't have a recent enough version of /boot/loader installed. However I've confirmed that I get the same problem a more recent loader, so it's not that. Joe --=20 =3D=3D=3D Josef Karthauser (joe@tao.org.uk) =3D=3D=3D http://x2obuilder.com= /tao =3D=3D=3D --+nBD6E3TurpgldQp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iEYEARECAAYFAkWhiJMACgkQXVIcjOaxUBbVmgCg1HN7cMeo9usz0nLDd8Me2yZE IDgAoLR24pxOPk3+x2sKErFTK69EmGHq =qjxO -----END PGP SIGNATURE----- --+nBD6E3TurpgldQp-- From owner-freebsd-fs@FreeBSD.ORG Tue Jan 9 06:37:24 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 966F616A403 for ; Tue, 9 Jan 2007 06:37:24 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id 2565313C45A for ; Tue, 9 Jan 2007 06:37:23 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l096Q8WY000909; Tue, 9 Jan 2007 17:26:08 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l096Q6F4000908; Tue, 9 Jan 2007 17:26:06 +1100 (EST) (envelope-from peter) Date: Tue, 9 Jan 2007 17:26:06 +1100 From: Peter Jeremy To: Josef Karthauser Message-ID: <20070109062606.GA853@turion.vk2pj.dyndns.org> References: <20070107232055.GA2450@genius.tao.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: <20070107232055.GA2450@genius.tao.org.uk> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-fs@freebsd.org Subject: Re: Trouble booting second ide drive (gmirror configuration). X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2007 06:37:24 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 2007-Jan-07 23:20:55 +0000, Josef Karthauser wrote: >I'm scratching my head trying to work out why I can't boot onto my >second ide drive at the boot: prompt. I have a perfectly valid >partition on it, which I can mount successfully when the system is >booted from the other disk, but the boot loader says that the disk label >is corrupt. What am I doing wrong? The logs you included showed the loader complaining "can't load 'kernel'" rather than having a corrupt disklabel. I presume you've confirmed that the disk actually has a kernel on it? Does the geometry reported by the BIOS match the on-disk geometry from fdisk? Have you tried toggling LBA? When you're at the loader prompt, what do "ls /boot" and "ls /boot/kernel" return? --=20 Peter Jeremy --0F1p//8PRICkK4MW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFozV+/opHv/APuIcRAroeAJ9589k1eAXzMlC+HvkPku0kQ72BZgCgjiCn imTTTIzeFK8HcqtlesfRPkY= =fg7U -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW-- From owner-freebsd-fs@FreeBSD.ORG Tue Jan 9 13:20:30 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6501216A412; Tue, 9 Jan 2007 13:20:30 +0000 (UTC) (envelope-from etc@fluffles.net) Received: from auriate.fluffles.net (cust.95.160.adsl.cistron.nl [195.64.95.160]) by mx1.freebsd.org (Postfix) with ESMTP id BAAA213C467; Tue, 9 Jan 2007 13:20:29 +0000 (UTC) (envelope-from etc@fluffles.net) Received: from destiny ([10.0.0.21]) by auriate.fluffles.net with esmtpa (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H4Gts-00052F-Ob; Tue, 09 Jan 2007 14:20:24 +0100 Message-ID: <45A396C5.2000908@fluffles.net> Date: Tue, 09 Jan 2007 14:21:09 +0100 From: Fluffles User-Agent: Thunderbird 1.5.0.8 (X11/20061114) MIME-Version: 1.0 To: Ivan Voras References: <45A38D38.3020407@fluffles.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Capturing I/O traces X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2007 13:20:30 -0000 Ivan Voras wrote: > Fluffles wrote: > > >> One thought that comes to mind is the gnop geom class; with verbose mode >> this provides a text log of all the I/O accesses. But it does not >> provide the exact time/concurrency etc, only the offset, length, I/O >> > > What do you mean by "time" and "concurrency"? You do realize that > requests are serialized on the low level? > Sure but simply capturing the serial order of requests might not be sufficient. For example: the application might 'wait' for one request to be finished because it needs that data in order to do another I/O request. I guess this is the hard part. If i would just execute the I/O in a serial way things like accesstime or 'latency' are less important because the overall throughput counts; while this may not be true for real applications but they might wait on one request before they can move on; thus a lower latency might be more important than a higher throughput. I guess it's not easy to really make something like this be reliable and realistic, but i'd like to come as close as possible. For example, the website StorageReview also uses traces to benchmark specific uses, two links: http://www.storagereview.com/articles/200611/ST3750640NS_3.html http://www.storagereview.com/articles/200510/Testbed4_4.html I'd like to use traces of applications on FreeBSD (or GNU/Linux) to benchmark KDE startup, MySQL, Apache and other applications. So i can have benchmark suites like "desktop", "webserver" and "database". That would be very neat. From owner-freebsd-fs@FreeBSD.ORG Tue Jan 9 13:23:15 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 060F916A403 for ; Tue, 9 Jan 2007 13:23:15 +0000 (UTC) (envelope-from etc@fluffles.net) Received: from auriate.fluffles.net (cust.95.160.adsl.cistron.nl [195.64.95.160]) by mx1.freebsd.org (Postfix) with ESMTP id AC65B13C43E for ; Tue, 9 Jan 2007 13:23:14 +0000 (UTC) (envelope-from etc@fluffles.net) Received: from destiny ([10.0.0.21]) by auriate.fluffles.net with esmtpa (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H4GGR-0002lu-7h; Tue, 09 Jan 2007 13:39:39 +0100 Message-ID: <45A38D38.3020407@fluffles.net> Date: Tue, 09 Jan 2007 13:40:24 +0100 From: Fluffles User-Agent: Thunderbird 1.5.0.8 (X11/20061114) MIME-Version: 1.0 To: freebsd-geom@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Subject: Capturing I/O traces X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2007 13:23:15 -0000 Hello list, I was wondering if any method is known to "capture" I/O traces. My goal is to be able to simulate I/O access patterns generated by applications such as MySQL or KDE and compare these to other storage systems. This way i can provide more realistic benchmarks (not synthetic) without actually running the application i'm testing. For example, I would like to capture the I/O that occurs when KDE boots, and then be able to reproduce this I/O access on say a gmirror and graid3. This way i can gather more realistic benchmark results. On Windows several commercial applications exist that 'simulate' access patterns used by applications, i was wondering if any BSD/Linux equivalent exists. One thought that comes to mind is the gnop geom class; with verbose mode this provides a text log of all the I/O accesses. But it does not provide the exact time/concurrency etc, only the offset, length, I/O action (read/write) and the serial order of those requests. And even with this information it's not easy to reproduce them; i would have to write an application that reads this log and then be able to reproduce it. I was hoping to find a more elegant solution. If you guys know of any, please share it with me. :) Regards, Veronica From owner-freebsd-fs@FreeBSD.ORG Tue Jan 9 16:58:53 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2513B16A40F for ; Tue, 9 Jan 2007 16:58:53 +0000 (UTC) (envelope-from victorloureirolima@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id DD60813C44B for ; Tue, 9 Jan 2007 16:58:52 +0000 (UTC) (envelope-from victorloureirolima@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so2313190ana for ; Tue, 09 Jan 2007 08:58:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Bddq8iuMsFHztVCwGIj/qkZqREXnp0J2zrObS7EUayUi39wK+qU+MM2R3Yr0PhednBbyMKepuft+qoVIFKfipJB2k6nUkJOWmo4F1TEpeGOxu0jESI1LDt/DnU0dTVZIjstSyvOQJhI6+tnm0ZLDjfoYosTWKIWFw4kmqiXqLWI= Received: by 10.100.190.8 with SMTP id n8mr10832191anf.1168360327458; Tue, 09 Jan 2007 08:32:07 -0800 (PST) Received: by 10.100.109.16 with HTTP; Tue, 9 Jan 2007 08:32:07 -0800 (PST) Message-ID: Date: Tue, 9 Jan 2007 13:32:07 -0300 From: "Victor Loureiro Lima" To: Fluffles In-Reply-To: <45A396C5.2000908@fluffles.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45A38D38.3020407@fluffles.net> <45A396C5.2000908@fluffles.net> Cc: freebsd-fs@freebsd.org, Ivan Voras , freebsd-geom@freebsd.org Subject: Re: Capturing I/O traces X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2007 16:58:53 -0000 Maybe you could take a look at iostat(8), seems to be able to help you somehow!!! ;) att, victor loureiro lima 2007/1/9, Fluffles : > Ivan Voras wrote: > > Fluffles wrote: > > > > > >> One thought that comes to mind is the gnop geom class; with verbose mode > >> this provides a text log of all the I/O accesses. But it does not > >> provide the exact time/concurrency etc, only the offset, length, I/O > >> > > > > What do you mean by "time" and "concurrency"? You do realize that > > requests are serialized on the low level? > > > > Sure but simply capturing the serial order of requests might not be > sufficient. For example: the application might 'wait' for one request to > be finished because it needs that data in order to do another I/O > request. I guess this is the hard part. If i would just execute the I/O > in a serial way things like accesstime or 'latency' are less important > because the overall throughput counts; while this may not be true for > real applications but they might wait on one request before they can > move on; thus a lower latency might be more important than a higher > throughput. > > I guess it's not easy to really make something like this be reliable and > realistic, but i'd like to come as close as possible. For example, the > website StorageReview also uses traces to benchmark specific uses, two > links: > > http://www.storagereview.com/articles/200611/ST3750640NS_3.html > http://www.storagereview.com/articles/200510/Testbed4_4.html > > I'd like to use traces of applications on FreeBSD (or GNU/Linux) to > benchmark KDE startup, MySQL, Apache and other applications. So i can > have benchmark suites like "desktop", "webserver" and "database". That > would be very neat. > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Tue Jan 9 17:51:41 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1722C16A417 for ; Tue, 9 Jan 2007 17:51:41 +0000 (UTC) (envelope-from adamk@voicenet.com) Received: from b.mx.visualtech.com (b.mx.visualtech.com [208.16.19.9]) by mx1.freebsd.org (Postfix) with ESMTP id 8CF4813C458 for ; Tue, 9 Jan 2007 17:51:40 +0000 (UTC) (envelope-from adamk@voicenet.com) Received: from [10.1.3.8] (maat.visualtech.com [208.16.19.254]) by b.mx.visualtech.com (Postfix) with ESMTP id 2C3CE4839D for ; Tue, 9 Jan 2007 12:21:52 -0500 (EST) From: Adam K Kirchhoff To: freebsd-fs@freebsd.org Content-Type: text/plain Date: Tue, 09 Jan 2007 12:21:52 -0500 Message-Id: <1168363312.1450.9.camel@memory.visualtech.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Mounting an xfs drive X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2007 17:51:41 -0000 Hello all, I have an xfs drive from an old Origin 2000 that I'm trying to pull some data from. I've managed to hook it up to my workstation which dual boots FreeBSD -CURRENT and Linux. Both operating systems see the drive, and Linux even sees three partitions (according to fdisk): sda8, sda9, sda11. Unfortunately Linux refuses to mount the actual XFS partition. >From what I can tell, it has to do with the fact that the filesystem is using version 1 directory format, which is unsupported on the linux version of XFS. So I was hoping to see if the same is try for the FreeBSD version of XFS. Again, FreeBSD sees the drive as /dev/da0, but no partitions or slices show up. Much as I expected, trying to mount /dev/da0 directly fails with "Operating not permitted". Before I continue fighting with this, I've taken a look in the xfs source code on my system, and it appears that version 1 directory format is unsupported on FreeBSD as well. Can anyone confirm this? If it is supported, any suggestions on how to get the drive mounted? Thanks :-) Adam From owner-freebsd-fs@FreeBSD.ORG Tue Jan 9 18:57:25 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F4C416A47E for ; Tue, 9 Jan 2007 18:57:25 +0000 (UTC) (envelope-from freebsd@scottevil.com) Received: from relay.aplus.net (relay.aplus.net [216.55.128.212]) by mx1.freebsd.org (Postfix) with ESMTP id 1099913C448 for ; Tue, 9 Jan 2007 18:57:25 +0000 (UTC) (envelope-from freebsd@scottevil.com) Received: from [216.55.129.230] by relay.aplus.net with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1H4KHl-000MVX-8J for freebsd-fs@freebsd.org; Tue, 09 Jan 2007 08:57:17 -0800 Message-ID: <45A3C96A.6030307@scottevil.com> Date: Tue, 09 Jan 2007 08:57:14 -0800 From: Scott Oertel User-Agent: Thunderbird 2.0b1 (X11/20061211) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: skipping fsck with soft-updates enabled X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2007 18:57:25 -0000 I am wondering what kind of problems would occur, besides lost space, if after a system crash a fsck is skipped. According to the documentation, with soft-updates enabled, the file system would be consistant, there would just be lost resources to be recovered which I am assuming can be safely done at a later time to avoid long periods of downtime during peek hours. "Soft updates control the ordering of filesystem updates such that the only inconsistencies in the on-disk representation are that free blocks and inodes may be claimed as "in use" in the on-disk bitmaps when they are really unused." So, would there be other issues if fsck wasn't ran right away after a system crash? Thanks, Scott From owner-freebsd-fs@FreeBSD.ORG Wed Jan 10 04:12:14 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2BD1316A40F; Wed, 10 Jan 2007 04:12:14 +0000 (UTC) (envelope-from unixtools@hotmail.com) Received: from bay0-omc2-s23.bay0.hotmail.com (bay0-omc2-s23.bay0.hotmail.com [65.54.246.159]) by mx1.freebsd.org (Postfix) with ESMTP id 14D7213C45A; Wed, 10 Jan 2007 04:12:14 +0000 (UTC) (envelope-from unixtools@hotmail.com) Received: from hotmail.com ([65.54.161.81]) by bay0-omc2-s23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 9 Jan 2007 20:00:14 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 9 Jan 2007 20:00:13 -0800 Message-ID: Received: from 203.199.109.165 by BAY106-DAV9.phx.gbl with DAV; Wed, 10 Jan 2007 04:00:09 +0000 X-Originating-IP: [203.199.109.165] X-Originating-Email: [unixtools@hotmail.com] X-Sender: unixtools@hotmail.com From: To: "Fluffles" , , References: <45A38D38.3020407@fluffles.net> Date: Wed, 10 Jan 2007 09:59:51 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-OriginalArrivalTime: 10 Jan 2007 04:00:13.0749 (UTC) FILETIME=[D4AB4E50:01C7346B] Cc: Subject: Re: Capturing I/O traces X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 04:12:14 -0000 Hi, To capture appication IO, the best option on freebsd is ktrace. I have no idea how to trace all the io calls triggered by the kernel. Sunil Sunder Raj http://daemon.in ----- Original Message ----- From: "Fluffles" To: ; Sent: Tuesday, January 09, 2007 6:10 PM Subject: Capturing I/O traces > Hello list, > > I was wondering if any method is known to "capture" I/O traces. My goal > is to be able to simulate I/O access patterns generated by applications > such as MySQL or KDE and compare these to other storage systems. This > way i can provide more realistic benchmarks (not synthetic) without > actually running the application i'm testing. For example, I would like > to capture the I/O that occurs when KDE boots, and then be able to > reproduce this I/O access on say a gmirror and graid3. This way i can > gather more realistic benchmark results. On Windows several commercial > applications exist that 'simulate' access patterns used by applications, > i was wondering if any BSD/Linux equivalent exists. > > One thought that comes to mind is the gnop geom class; with verbose mode > this provides a text log of all the I/O accesses. But it does not > provide the exact time/concurrency etc, only the offset, length, I/O > action (read/write) and the serial order of those requests. And even > with this information it's not easy to reproduce them; i would have to > write an application that reads this log and then be able to reproduce > it. I was hoping to find a more elegant solution. If you guys know of > any, please share it with me. :) > > Regards, > > Veronica > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Wed Jan 10 09:21:21 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC9CD16A412; Wed, 10 Jan 2007 09:21:21 +0000 (UTC) (envelope-from etc@fluffles.net) Received: from auriate.fluffles.net (cust.95.160.adsl.cistron.nl [195.64.95.160]) by mx1.freebsd.org (Postfix) with ESMTP id 628E913C47E; Wed, 10 Jan 2007 09:21:21 +0000 (UTC) (envelope-from etc@fluffles.net) Received: from destiny ([10.0.0.21]) by auriate.fluffles.net with esmtpa (Exim 4.63 (FreeBSD)) (envelope-from ) id 1H4Ze0-000Mhh-Ci; Wed, 10 Jan 2007 10:21:16 +0100 Message-ID: <45A4B03A.5030806@fluffles.net> Date: Wed, 10 Jan 2007 10:22:02 +0100 From: Fluffles User-Agent: Thunderbird 1.5.0.8 (X11/20061114) MIME-Version: 1.0 To: unixtools@hotmail.com References: <45A38D38.3020407@fluffles.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Capturing I/O traces X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 09:21:22 -0000 Hello list, Thanks for all your input. After some thought about I/O tracing, I guess ktrace won't work properly. I do not see the offset/length of the requests and it does include the actual contents; so it's not what i need. I think the geom_nop approach might be the best or most simple. Arne Woerner provided me a modified gnop which logs the I/O requests at debuglevel 0. But i would need some form of binary logging, to file. So that with a specially modified gnop it would dump all I/O into a file, like: /mnt/memorydisk/ad4.nop.log. It would have to log all accesses binary. I think i will drop the time between requests, so i will just need the serial order of requests and the following information: - read or write - offset - length It should be binary, like: R<32-bit offset><32-bit length>W<32-bit offset><32-bit length>.... The R means Read (so takes 1 byte) and W ofcourse write. This way it will take 9 bytes per I/O request to log. I could log to memory (md malloc) to minimize performance penalty. The logging should be able to turn off/on via sysctl switch or so, so i can prepare the benchmark setup and turn on tracing just before i launch the application i wish to trace. When this modified gnop module is done, i need a C-like program that can read the log and perform the I/O on a given device. Such as calling the following command: ./tracereproduce ./tracereproduce /mnt/memorydisk/ad4.nop.log /dev/raid5/test Then it would execute all I/O requests logged in the .log file at the fastest speed possible, serially. It should record the start time and end time and calculate the microtime it has used to finish all requests. Say this is 14.9 seconds for 20.000 I/O requests, then it would produce 1342 I/O per second as the end result. Then i can reproduce the test on say a gmirror device and i would get another score, being able to compare between classes. What do you guys think? Any flaws in my idea? I know this is at geom level and not VFS-level, but as Arne Woerner pointed out to me; caching/buffering that happens at the VFS-level will never reach the geom-layer anyway; so i do not need it. All benchmarking will be done on one machine so the only thing different is the geom classes; for example a 4-disk gstripe versus 4-disk graid5, etc. There might be better ways to do tracing; but since i'm a simple webdeveloper i do not have the skills to write a sophisticated applications. The geom-tracing approach outlined above might be my best option and might come very close to realistic performance-gains. Feedback is appreciated. :) - Veronica From owner-freebsd-fs@FreeBSD.ORG Wed Jan 10 10:00:35 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CCC7416A407 for ; Wed, 10 Jan 2007 10:00:35 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30309.mail.mud.yahoo.com (web30309.mail.mud.yahoo.com [209.191.69.71]) by mx1.freebsd.org (Postfix) with SMTP id 4710613C45B for ; Wed, 10 Jan 2007 10:00:35 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: (qmail 25744 invoked by uid 60001); 10 Jan 2007 09:33:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=5h64Is8tVbU6TFlCJgayTd87OxhivvAE3g6jUd0Bs3J5Q2yklChSP7ul4BbocqTb4YoLtRsRKOE5gglLgQ3NGJ/SE00JJyonbML5KWnYQGHxfRKlOsLPcpdXD1Wl08jaLQLFaUmybPtx5K5n1TUs18c0u5YiEM6WkBhid9SHu04=; X-YMail-OSG: jAzsILIVM1n9n7sQGOUaP8hRYWDZBSq.wulzPTHbdMBST4_MGW2KtWUAoEOte4diOg-- Received: from [85.212.20.209] by web30309.mail.mud.yahoo.com via HTTP; Wed, 10 Jan 2007 01:33:53 PST Date: Wed, 10 Jan 2007 01:33:53 -0800 (PST) From: "R. B. Riddick" To: Fluffles In-Reply-To: <45A4B03A.5030806@fluffles.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <478499.24007.qm@web30309.mail.mud.yahoo.com> Cc: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Capturing I/O traces X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 10:00:35 -0000 --- Fluffles wrote: > It should be binary, like: > R<32-bit offset><32-bit length>W<32-bit offset><32-bit length>.... > What is so bad about syslog? Problems with parsing...? :-) When u dont know start times and end times, you will not be able to identify concurrent/simultaneous requests, which might be bad for performance (I think, UFS can use 9 simultaneous requests). -Arne ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited From owner-freebsd-fs@FreeBSD.ORG Wed Jan 10 12:08:52 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86BAE16A49E for ; Wed, 10 Jan 2007 12:08:52 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 11FBC13C4A6 for ; Wed, 10 Jan 2007 12:08:51 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (bshkjo@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l0ABdJ4s088811; Wed, 10 Jan 2007 12:39:24 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l0ABdJ9K088810; Wed, 10 Jan 2007 12:39:19 +0100 (CET) (envelope-from olli) Date: Wed, 10 Jan 2007 12:39:19 +0100 (CET) Message-Id: <200701101139.l0ABdJ9K088810@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG, freebsd@scottevil.com In-Reply-To: <45A3C96A.6030307@scottevil.com> X-Newsgroups: list.freebsd-fs User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 10 Jan 2007 12:39:25 +0100 (CET) Cc: Subject: Re: skipping fsck with soft-updates enabled X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-fs@FreeBSD.ORG, freebsd@scottevil.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 12:08:52 -0000 Scott Oertel wrote: > I am wondering what kind of problems would occur, besides lost space, if > after a system crash a fsck is skipped. According to the documentation, > with soft-updates enabled, the file system would be consistant, there > would just be lost resources to be recovered which I am assuming can be > safely done at a later time to avoid long periods of downtime during > peek hours. I think that's exactly what the background fsck feature does. If you enable it (which is even the default), the fsck process doesn' start right away, so the system comes up in multi-user mode immediately. Then a snapshot is created on the file system, and fsck runs on the snap- shot, freeing the lost space in the file system. Of course, it only works reliably with soft-updates enabled, _and_ there must not be any unexpected inconsistencies. However, with some common setups (e.g. cheap disks lying about completed write operation) it is difficult to guarantee the consistency. Soft-updates is rather fragile when the hardware doesn't work exactly as it's supposed to. I've witnessed breakage in the past, and for that reason I always disable the background fsck feature. And it's the reason I'm looking forward to gjournal to become stable, because it seems to be less fragile in the presence of imperfect hardware. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "C++ is to C as Lung Cancer is to Lung." -- Thomas Funke From owner-freebsd-fs@FreeBSD.ORG Wed Jan 10 12:09:01 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DEF4116A407 for ; Wed, 10 Jan 2007 12:09:01 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 27F2713C458 for ; Wed, 10 Jan 2007 12:09:00 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (dapatm@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l0ABUp2v086923; Wed, 10 Jan 2007 12:30:56 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l0ABUoC4086922; Wed, 10 Jan 2007 12:30:50 +0100 (CET) (envelope-from olli) Date: Wed, 10 Jan 2007 12:30:50 +0100 (CET) Message-Id: <200701101130.l0ABUoC4086922@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG, adamk@voicenet.com In-Reply-To: <1168363312.1450.9.camel@memory.visualtech.com> X-Newsgroups: list.freebsd-fs User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 10 Jan 2007 12:30:56 +0100 (CET) Cc: Subject: Re: Mounting an xfs drive X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-fs@FreeBSD.ORG, adamk@voicenet.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 12:09:02 -0000 Adam K Kirchhoff wrote: > I have an xfs drive from an old Origin 2000 that I'm trying to pull > some data from. Just an idea: Maybe ports/sysutils/xfsprogs can help? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "When your hammer is C++, everything begins to look like a thumb." -- Steve Haflich, in comp.lang.c++ From owner-freebsd-fs@FreeBSD.ORG Wed Jan 10 13:38:02 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2960916A40F for ; Wed, 10 Jan 2007 13:38:02 +0000 (UTC) (envelope-from victorloureirolima@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id E3C1513C459 for ; Wed, 10 Jan 2007 13:38:01 +0000 (UTC) (envelope-from victorloureirolima@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so30866ana for ; Wed, 10 Jan 2007 05:38:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mbmBt1zkr5r7JOZOP2TNsjidi9hArK6N+veWlWRHARqDxTubrB9NhTgEMqGdA7u2K9G+6oo5emcmntmCReBQoeAVs/1WP7YmO4SgKszPGLWHEflZAWHvosbdc4ZYD6shTIL/65dNXQ2qXPYpRifykILusDTCW6VY7UZl0Lg4/u0= Received: by 10.100.48.7 with SMTP id v7mr237186anv.1168436281374; Wed, 10 Jan 2007 05:38:01 -0800 (PST) Received: by 10.100.109.16 with HTTP; Wed, 10 Jan 2007 05:38:01 -0800 (PST) Message-ID: Date: Wed, 10 Jan 2007 11:38:01 -0200 From: "Victor Loureiro Lima" To: freebsd-fs@freebsd.org, freebsd@scottevil.com In-Reply-To: <200701101139.l0ABdJ9K088810@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45A3C96A.6030307@scottevil.com> <200701101139.l0ABdJ9K088810@lurza.secnetix.de> Cc: Subject: Re: skipping fsck with soft-updates enabled X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 13:38:02 -0000 >From rc.conf man page: --- background_fsck_delay (int) The amount of time in seconds to sleep before starting a background fsck(8). It defaults to sixty seconds to allow large applications such as the X server to start before disk I/O bandwidth is monopolized by fsck(8). --- You can set the delay as long as you want, so it wont have to start right away, in fact it can start as late as a year (if thats really what you want ;)) att, victor loureiro lima 2007/1/10, Oliver Fromme : > Scott Oertel wrote: > > I am wondering what kind of problems would occur, besides lost space, if > > after a system crash a fsck is skipped. According to the documentation, > > with soft-updates enabled, the file system would be consistant, there > > would just be lost resources to be recovered which I am assuming can be > > safely done at a later time to avoid long periods of downtime during > > peek hours. > > I think that's exactly what the background fsck feature > does. If you enable it (which is even the default), the > fsck process doesn' start right away, so the system comes > up in multi-user mode immediately. Then a snapshot is > created on the file system, and fsck runs on the snap- > shot, freeing the lost space in the file system. > > Of course, it only works reliably with soft-updates enabled, > _and_ there must not be any unexpected inconsistencies. > However, with some common setups (e.g. cheap disks lying > about completed write operation) it is difficult to > guarantee the consistency. Soft-updates is rather fragile > when the hardware doesn't work exactly as it's supposed to. > I've witnessed breakage in the past, and for that reason > I always disable the background fsck feature. And it's the > reason I'm looking forward to gjournal to become stable, > because it seems to be less fragile in the presence of > imperfect hardware. > > Best regards > Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing > Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd > Any opinions expressed in this message may be personal to the author > and may not necessarily reflect the opinions of secnetix in any way. > > "C++ is to C as Lung Cancer is to Lung." > -- Thomas Funke > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Wed Jan 10 14:56:10 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0844216A403 for ; Wed, 10 Jan 2007 14:56:10 +0000 (UTC) (envelope-from freebsd@scottevil.com) Received: from pro28.abac.com (pro28.abac.com [66.226.64.29]) by mx1.freebsd.org (Postfix) with ESMTP id D625E13C455 for ; Wed, 10 Jan 2007 14:56:09 +0000 (UTC) (envelope-from freebsd@scottevil.com) Received: from [192.168.1.120] (cpe-24-165-18-105.san.res.rr.com [24.165.18.105]) (authenticated bits=0) by pro28.abac.com (8.13.6/8.13.6) with ESMTP id l0AERMue041385; Wed, 10 Jan 2007 06:27:22 -0800 (PST) (envelope-from freebsd@scottevil.com) Message-ID: <45A485C6.2060405@scottevil.com> Date: Tue, 09 Jan 2007 22:20:54 -0800 From: Scott Oertel User-Agent: Thunderbird 1.5.0.9 (X11/20070106) MIME-Version: 1.0 To: Victor Loureiro Lima References: <45A3C96A.6030307@scottevil.com> <200701101139.l0ABdJ9K088810@lurza.secnetix.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.746 (DATE_IN_PAST_06_12) Cc: freebsd-fs@freebsd.org Subject: Re: skipping fsck with soft-updates enabled X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 14:56:10 -0000 Victor Loureiro Lima wrote: > From rc.conf man page: > --- > background_fsck_delay > (int) The amount of time in seconds to sleep before > starting > a background fsck(8). It defaults to sixty seconds to > allow > large applications such as the X server to start > before disk > I/O bandwidth is monopolized by fsck(8). > --- > > You can set the delay as long as you want, so it wont have to start > right away, in fact it can start as late as a year (if thats really > what you want ;)) > > att, > victor loureiro lima > > 2007/1/10, Oliver Fromme : >> Scott Oertel wrote: >> > I am wondering what kind of problems would occur, besides lost >> space, if >> > after a system crash a fsck is skipped. According to the >> documentation, >> > with soft-updates enabled, the file system would be consistant, there >> > would just be lost resources to be recovered which I am assuming >> can be >> > safely done at a later time to avoid long periods of downtime during >> > peek hours. >> >> I think that's exactly what the background fsck feature >> does. If you enable it (which is even the default), the >> fsck process doesn' start right away, so the system comes >> up in multi-user mode immediately. Then a snapshot is >> created on the file system, and fsck runs on the snap- >> shot, freeing the lost space in the file system. >> >> Of course, it only works reliably with soft-updates enabled, >> _and_ there must not be any unexpected inconsistencies. >> However, with some common setups (e.g. cheap disks lying >> about completed write operation) it is difficult to >> guarantee the consistency. Soft-updates is rather fragile >> when the hardware doesn't work exactly as it's supposed to. >> I've witnessed breakage in the past, and for that reason >> I always disable the background fsck feature. And it's the >> reason I'm looking forward to gjournal to become stable, >> because it seems to be less fragile in the presence of >> imperfect hardware. >> >> Best regards >> Oliver >> >> -- >> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing >> Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd >> Any opinions expressed in this message may be personal to the author >> and may not necessarily reflect the opinions of secnetix in any way. >> >> "C++ is to C as Lung Cancer is to Lung." >> -- Thomas Funke >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> The problem with background fsck is that on my machines, it doesn't work well. These machines have 8x750gb SATA drives and they are under extreme stress all the time. When you run fsck in the background each drive takes 10+ minutes to create the snapshot file, during which time the machine is completely unresponsive, and unstable. That is why I am wondering, if it is ok to skip the background fsck's, foreground fsck's and reschedule them for a later time, during non peak hours. Thanks, Scott From owner-freebsd-fs@FreeBSD.ORG Wed Jan 10 15:12:21 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6162816A47B for ; Wed, 10 Jan 2007 15:12:21 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 421A013C467 for ; Wed, 10 Jan 2007 15:12:21 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l0AFCEL0091408; Wed, 10 Jan 2007 09:12:14 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <45A5024F.10502@centtech.com> Date: Wed, 10 Jan 2007 09:12:15 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5.0.9 (X11/20061223) MIME-Version: 1.0 To: Scott Oertel References: <45A3C96A.6030307@scottevil.com> <200701101139.l0ABdJ9K088810@lurza.secnetix.de> <45A485C6.2060405@scottevil.com> In-Reply-To: <45A485C6.2060405@scottevil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2432/Wed Jan 10 07:12:31 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-fs@freebsd.org Subject: Re: skipping fsck with soft-updates enabled X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 15:12:21 -0000 On 01/10/07 00:20, Scott Oertel wrote: > Victor Loureiro Lima wrote: >> From rc.conf man page: >> --- >> background_fsck_delay >> (int) The amount of time in seconds to sleep before >> starting >> a background fsck(8). It defaults to sixty seconds to >> allow >> large applications such as the X server to start >> before disk >> I/O bandwidth is monopolized by fsck(8). >> --- >> >> You can set the delay as long as you want, so it wont have to start >> right away, in fact it can start as late as a year (if thats really >> what you want ;)) >> >> att, >> victor loureiro lima >> >> 2007/1/10, Oliver Fromme : >>> Scott Oertel wrote: >>> > I am wondering what kind of problems would occur, besides lost >>> space, if >>> > after a system crash a fsck is skipped. According to the >>> documentation, >>> > with soft-updates enabled, the file system would be consistant, there >>> > would just be lost resources to be recovered which I am assuming >>> can be >>> > safely done at a later time to avoid long periods of downtime during >>> > peek hours. >>> >>> I think that's exactly what the background fsck feature >>> does. If you enable it (which is even the default), the >>> fsck process doesn' start right away, so the system comes >>> up in multi-user mode immediately. Then a snapshot is >>> created on the file system, and fsck runs on the snap- >>> shot, freeing the lost space in the file system. >>> >>> Of course, it only works reliably with soft-updates enabled, >>> _and_ there must not be any unexpected inconsistencies. >>> However, with some common setups (e.g. cheap disks lying >>> about completed write operation) it is difficult to >>> guarantee the consistency. Soft-updates is rather fragile >>> when the hardware doesn't work exactly as it's supposed to. >>> I've witnessed breakage in the past, and for that reason >>> I always disable the background fsck feature. And it's the >>> reason I'm looking forward to gjournal to become stable, >>> because it seems to be less fragile in the presence of >>> imperfect hardware. >>> >>> Best regards >>> Oliver >>> >>> -- >>> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing >>> Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd >>> Any opinions expressed in this message may be personal to the author >>> and may not necessarily reflect the opinions of secnetix in any way. >>> >>> "C++ is to C as Lung Cancer is to Lung." >>> -- Thomas Funke >>> _______________________________________________ > The problem with background fsck is that on my machines, it doesn't work > well. These machines have 8x750gb SATA drives and they are under extreme > stress all the time. When you run fsck in the background each drive > takes 10+ minutes to create the snapshot file, during which time the > machine is completely unresponsive, and unstable. What version of FreeBSD are you running? You might try gjournal, which I've had great luck with, and Pawel (pjd@) is incredibly responsive to bug reports, etc. > That is why I am wondering, if it is ok to skip the background fsck's, > foreground fsck's and reschedule them for a later time, during non peak > hours. I think most people would be nervous to tell you 'sure, skip it until later', but I can tell you from experience that I myself have delayed fscking for weeks on end, to do exactly what you want. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology An undefined problem has an infinite number of solutions. ------------------------------------------------------------------------ From owner-freebsd-fs@FreeBSD.ORG Wed Jan 10 16:18:14 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7709C16A40F for ; Wed, 10 Jan 2007 16:18:14 +0000 (UTC) (envelope-from freebsd@scottevil.com) Received: from relay.aplus.net (relay.aplus.net [216.55.128.212]) by mx1.freebsd.org (Postfix) with ESMTP id 641E613C457 for ; Wed, 10 Jan 2007 16:18:14 +0000 (UTC) (envelope-from freebsd@scottevil.com) Received: from [216.55.129.230] by relay.aplus.net with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1H4g9V-000I5l-SK; Wed, 10 Jan 2007 08:18:13 -0800 Message-ID: <45A511C0.9000402@scottevil.com> Date: Wed, 10 Jan 2007 08:18:08 -0800 From: Scott Oertel User-Agent: Thunderbird 2.0b1 (X11/20061211) MIME-Version: 1.0 To: Eric Anderson References: <45A3C96A.6030307@scottevil.com> <200701101139.l0ABdJ9K088810@lurza.secnetix.de> <45A485C6.2060405@scottevil.com> <45A5024F.10502@centtech.com> In-Reply-To: <45A5024F.10502@centtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: skipping fsck with soft-updates enabled X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 16:18:14 -0000 Eric Anderson wrote: > On 01/10/07 00:20, Scott Oertel wrote: >> Victor Loureiro Lima wrote: >>> From rc.conf man page: >>> --- >>> background_fsck_delay >>> (int) The amount of time in seconds to sleep before >>> starting >>> a background fsck(8). It defaults to sixty seconds >>> to allow >>> large applications such as the X server to start >>> before disk >>> I/O bandwidth is monopolized by fsck(8). >>> --- >>> >>> You can set the delay as long as you want, so it wont have to start >>> right away, in fact it can start as late as a year (if thats really >>> what you want ;)) >>> >>> att, >>> victor loureiro lima >>> >>> 2007/1/10, Oliver Fromme : >>>> Scott Oertel wrote: >>>> > I am wondering what kind of problems would occur, besides lost >>>> space, if >>>> > after a system crash a fsck is skipped. According to the >>>> documentation, >>>> > with soft-updates enabled, the file system would be consistant, >>>> there >>>> > would just be lost resources to be recovered which I am assuming >>>> can be >>>> > safely done at a later time to avoid long periods of downtime >>>> during >>>> > peek hours. >>>> >>>> I think that's exactly what the background fsck feature >>>> does. If you enable it (which is even the default), the >>>> fsck process doesn' start right away, so the system comes >>>> up in multi-user mode immediately. Then a snapshot is >>>> created on the file system, and fsck runs on the snap- >>>> shot, freeing the lost space in the file system. >>>> >>>> Of course, it only works reliably with soft-updates enabled, >>>> _and_ there must not be any unexpected inconsistencies. >>>> However, with some common setups (e.g. cheap disks lying >>>> about completed write operation) it is difficult to >>>> guarantee the consistency. Soft-updates is rather fragile >>>> when the hardware doesn't work exactly as it's supposed to. >>>> I've witnessed breakage in the past, and for that reason >>>> I always disable the background fsck feature. And it's the >>>> reason I'm looking forward to gjournal to become stable, >>>> because it seems to be less fragile in the presence of >>>> imperfect hardware. >>>> >>>> Best regards >>>> Oliver >>>> >>>> -- >>>> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing >>>> Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd >>>> Any opinions expressed in this message may be personal to the author >>>> and may not necessarily reflect the opinions of secnetix in any way. >>>> >>>> "C++ is to C as Lung Cancer is to Lung." >>>> -- Thomas Funke >>>> _______________________________________________ >> The problem with background fsck is that on my machines, it doesn't >> work well. These machines have 8x750gb SATA drives and they are under >> extreme stress all the time. When you run fsck in the background each >> drive takes 10+ minutes to create the snapshot file, during which >> time the machine is completely unresponsive, and unstable. > > What version of FreeBSD are you running? You might try gjournal, > which I've had great luck with, and Pawel (pjd@) is incredibly > responsive to bug reports, etc. > >> That is why I am wondering, if it is ok to skip the background >> fsck's, foreground fsck's and reschedule them for a later time, >> during non peak hours. > > I think most people would be nervous to tell you 'sure, skip it until > later', but I can tell you from experience that I myself have delayed > fscking for weeks on end, to do exactly what you want. > > Eric > > > I'm running on 6.2-RC2. For fun I tried to create a snapshot on one of our newest machines, same drive config as the previous ones, it's just less active then the others. It's running 6.2RC2 and it just completely locked up. Anyway, thanks for the suggestion about running gjournal, i'm not sure running non-offical patches on the file system code with production machines is such a great idea. Have you had any problems with gjournal, if so, of what nature were they? From owner-freebsd-fs@FreeBSD.ORG Wed Jan 10 18:11:02 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1CA9F16A403 for ; Wed, 10 Jan 2007 18:11:02 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (grnl-static-02-0046.dsl.iowatelecom.net [69.66.56.110]) by mx1.freebsd.org (Postfix) with ESMTP id A1EDE13C469 for ; Wed, 10 Jan 2007 18:11:01 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id l0AHhc5m008224; Wed, 10 Jan 2007 11:43:38 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id l0AHhc4n008223; Wed, 10 Jan 2007 11:43:38 -0600 (CST) (envelope-from brooks) Date: Wed, 10 Jan 2007 11:43:38 -0600 From: Brooks Davis To: Eric Anderson Message-ID: <20070110174337.GA7544@lor.one-eyed-alien.net> References: <45A3C96A.6030307@scottevil.com> <200701101139.l0ABdJ9K088810@lurza.secnetix.de> <45A485C6.2060405@scottevil.com> <45A5024F.10502@centtech.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <45A5024F.10502@centtech.com> User-Agent: Mutt/1.5.11 Cc: freebsd-fs@freebsd.org Subject: Re: skipping fsck with soft-updates enabled X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 18:11:02 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 10, 2007 at 09:12:15AM -0600, Eric Anderson wrote: > On 01/10/07 00:20, Scott Oertel wrote: > >Victor Loureiro Lima wrote: > >>From rc.conf man page: > >>--- > >>background_fsck_delay > >> (int) The amount of time in seconds to sleep before=20 > >>starting > >> a background fsck(8). It defaults to sixty seconds to= =20 > >>allow > >> large applications such as the X server to start=20 > >>before disk > >> I/O bandwidth is monopolized by fsck(8). > >>--- > >> > >>You can set the delay as long as you want, so it wont have to start > >>right away, in fact it can start as late as a year (if thats really > >>what you want ;)) > >> > >>att, > >>victor loureiro lima > >> > >>2007/1/10, Oliver Fromme : > >>>Scott Oertel wrote: > >>> > I am wondering what kind of problems would occur, besides lost=20 > >>>space, if > >>> > after a system crash a fsck is skipped. According to the=20 > >>>documentation, > >>> > with soft-updates enabled, the file system would be consistant, the= re > >>> > would just be lost resources to be recovered which I am assuming=20 > >>>can be > >>> > safely done at a later time to avoid long periods of downtime during > >>> > peek hours. > >>> > >>>I think that's exactly what the background fsck feature > >>>does. If you enable it (which is even the default), the > >>>fsck process doesn' start right away, so the system comes > >>>up in multi-user mode immediately. Then a snapshot is > >>>created on the file system, and fsck runs on the snap- > >>>shot, freeing the lost space in the file system. > >>> > >>>Of course, it only works reliably with soft-updates enabled, > >>>_and_ there must not be any unexpected inconsistencies. > >>>However, with some common setups (e.g. cheap disks lying > >>>about completed write operation) it is difficult to > >>>guarantee the consistency. Soft-updates is rather fragile > >>>when the hardware doesn't work exactly as it's supposed to. > >>>I've witnessed breakage in the past, and for that reason > >>>I always disable the background fsck feature. And it's the > >>>reason I'm looking forward to gjournal to become stable, > >>>because it seems to be less fragile in the presence of > >>>imperfect hardware. > >>> > >>>Best regards > >>> Oliver > >>> > >>>--=20 > >>>Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing > >>>Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd > >>>Any opinions expressed in this message may be personal to the author > >>>and may not necessarily reflect the opinions of secnetix in any way. > >>> > >>>"C++ is to C as Lung Cancer is to Lung." > >>> -- Thomas Funke > >>>_______________________________________________ > >The problem with background fsck is that on my machines, it doesn't work= =20 > >well. These machines have 8x750gb SATA drives and they are under extreme= =20 > >stress all the time. When you run fsck in the background each drive=20 > >takes 10+ minutes to create the snapshot file, during which time the=20 > >machine is completely unresponsive, and unstable. >=20 > What version of FreeBSD are you running? You might try gjournal, which= =20 > I've had great luck with, and Pawel (pjd@) is incredibly responsive to=20 > bug reports, etc. >=20 > >That is why I am wondering, if it is ok to skip the background fsck's,= =20 > >foreground fsck's and reschedule them for a later time, during non peak= =20 > >hours. >=20 > I think most people would be nervous to tell you 'sure, skip it until=20 > later', but I can tell you from experience that I myself have delayed=20 > fscking for weeks on end, to do exactly what you want. I've been thinking it would be useful to have a new background_fsck_delay value of CRON and have a cron job that can accomplish the background fsck during off hours if needed. -- Brooks --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFpSXJXY6L6fI4GtQRAm7RAJ9HOzb/UlQbXT+BJOoFEWvsAEzPggCg5HvW BK/HnggNuwOkRMauSXGXiQY= =toQP -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From owner-freebsd-fs@FreeBSD.ORG Thu Jan 11 00:07:45 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5B41F16A4D1 for ; Thu, 11 Jan 2007 00:07:45 +0000 (UTC) (envelope-from freebsd@scottevil.com) Received: from relay.aplus.net (relay.aplus.net [216.55.128.212]) by mx1.freebsd.org (Postfix) with ESMTP id 44F2013C45E for ; Thu, 11 Jan 2007 00:07:45 +0000 (UTC) (envelope-from freebsd@scottevil.com) Received: from [216.55.129.230] by relay.aplus.net with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1H4nTs-000Hyk-NS; Wed, 10 Jan 2007 16:07:44 -0800 Message-ID: <45A57FCA.6090004@scottevil.com> Date: Wed, 10 Jan 2007 16:07:38 -0800 From: Scott Oertel User-Agent: Thunderbird 2.0b1 (X11/20061211) MIME-Version: 1.0 To: Brooks Davis References: <45A3C96A.6030307@scottevil.com> <200701101139.l0ABdJ9K088810@lurza.secnetix.de> <45A485C6.2060405@scottevil.com> <45A5024F.10502@centtech.com> <20070110174337.GA7544@lor.one-eyed-alien.net> In-Reply-To: <20070110174337.GA7544@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: skipping fsck with soft-updates enabled X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2007 00:07:45 -0000 Brooks Davis wrote: > On Wed, Jan 10, 2007 at 09:12:15AM -0600, Eric Anderson wrote: > >> On 01/10/07 00:20, Scott Oertel wrote: >> >>> Victor Loureiro Lima wrote: >>> >From rc.conf man page: >>> >>>> --- >>>> background_fsck_delay >>>> (int) The amount of time in seconds to sleep before >>>> starting >>>> a background fsck(8). It defaults to sixty seconds to >>>> allow >>>> large applications such as the X server to start >>>> before disk >>>> I/O bandwidth is monopolized by fsck(8). >>>> --- >>>> >>>> You can set the delay as long as you want, so it wont have to start >>>> right away, in fact it can start as late as a year (if thats really >>>> what you want ;)) >>>> >>>> att, >>>> victor loureiro lima >>>> >>>> 2007/1/10, Oliver Fromme : >>>> >>>>> Scott Oertel wrote: >>>>> >>>>>> I am wondering what kind of problems would occur, besides lost >>>>>> >>>>> space, if >>>>> >>>>>> after a system crash a fsck is skipped. According to the >>>>>> >>>>> documentation, >>>>> >>>>>> with soft-updates enabled, the file system would be consistant, there >>>>>> would just be lost resources to be recovered which I am assuming >>>>>> >>>>> can be >>>>> >>>>>> safely done at a later time to avoid long periods of downtime during >>>>>> peek hours. >>>>>> >>>>> I think that's exactly what the background fsck feature >>>>> does. If you enable it (which is even the default), the >>>>> fsck process doesn' start right away, so the system comes >>>>> up in multi-user mode immediately. Then a snapshot is >>>>> created on the file system, and fsck runs on the snap- >>>>> shot, freeing the lost space in the file system. >>>>> >>>>> Of course, it only works reliably with soft-updates enabled, >>>>> _and_ there must not be any unexpected inconsistencies. >>>>> However, with some common setups (e.g. cheap disks lying >>>>> about completed write operation) it is difficult to >>>>> guarantee the consistency. Soft-updates is rather fragile >>>>> when the hardware doesn't work exactly as it's supposed to. >>>>> I've witnessed breakage in the past, and for that reason >>>>> I always disable the background fsck feature. And it's the >>>>> reason I'm looking forward to gjournal to become stable, >>>>> because it seems to be less fragile in the presence of >>>>> imperfect hardware. >>>>> >>>>> Best regards >>>>> Oliver >>>>> >>>>> -- >>>>> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing >>>>> Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd >>>>> Any opinions expressed in this message may be personal to the author >>>>> and may not necessarily reflect the opinions of secnetix in any way. >>>>> >>>>> "C++ is to C as Lung Cancer is to Lung." >>>>> -- Thomas Funke >>>>> _______________________________________________ >>>>> >>> The problem with background fsck is that on my machines, it doesn't work >>> well. These machines have 8x750gb SATA drives and they are under extreme >>> stress all the time. When you run fsck in the background each drive >>> takes 10+ minutes to create the snapshot file, during which time the >>> machine is completely unresponsive, and unstable. >>> >> What version of FreeBSD are you running? You might try gjournal, which >> I've had great luck with, and Pawel (pjd@) is incredibly responsive to >> bug reports, etc. >> >> >>> That is why I am wondering, if it is ok to skip the background fsck's, >>> foreground fsck's and reschedule them for a later time, during non peak >>> hours. >>> >> I think most people would be nervous to tell you 'sure, skip it until >> later', but I can tell you from experience that I myself have delayed >> fscking for weeks on end, to do exactly what you want. >> > > I've been thinking it would be useful to have a new background_fsck_delay > value of CRON and have a cron job that can accomplish the background > fsck during off hours if needed. > > -- Brooks > I'll probably do some testing with the effects of delaying fsck for long periods of time using soft-updates. Personally, I haven't found anyone stating any hard facts that would leave me to believe that running on a dirty filesystem for an extended period of time won't cause further inconsistencies. Which was what I was hoping to get out of this post, maybe someone will read it down the line and provide some real facts of why it is or is not dangerous to delay fsck's for an extended period of time. Thanks for the input.. --Scott From owner-freebsd-fs@FreeBSD.ORG Thu Jan 11 08:41:57 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D09E816A403 for ; Thu, 11 Jan 2007 08:41:57 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 4E8D713C46A for ; Thu, 11 Jan 2007 08:41:57 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (obmtuh@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l0B8fon8067683; Thu, 11 Jan 2007 09:41:55 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l0B8foK1067682; Thu, 11 Jan 2007 09:41:50 +0100 (CET) (envelope-from olli) Date: Thu, 11 Jan 2007 09:41:50 +0100 (CET) Message-Id: <200701110841.l0B8foK1067682@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG, freebsd@scottevil.com In-Reply-To: <45A57FCA.6090004@scottevil.com> X-Newsgroups: list.freebsd-fs User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 11 Jan 2007 09:41:56 +0100 (CET) Cc: Subject: Re: skipping fsck with soft-updates enabled X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-fs@FreeBSD.ORG, freebsd@scottevil.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2007 08:41:57 -0000 Scott Oertel wrote: > I'll probably do some testing with the effects of delaying fsck for long > periods of time using soft-updates. Personally, I haven't found anyone > stating any hard facts that would leave me to believe that running on a > dirty filesystem for an extended period of time won't cause further > inconsistencies. s/further// If soft-updates is running correctly on the drive, then there are _no_ inconsistencies on the file systems after a crash. And there's no reason why any inconsistencies should appear later on. The only thing that's "dirty" about the file systems is unused space that's still marked as used, which means that it is not available to new allocations when writing data. That's not harmful (unless you run out of disk space, of course). The only thing that fsck will do in that situation -- no matter whether regular fsck or background fsck -- is to find those unused areas and mark them as free. It does not matter whether that's done immediately after the reboot, or a few hours later, or a month later, or even never at all. The only drawback is that some disk space is unavailable for new allocations until fsck cleans it up. All of the above is theory, and it _should_ work exactly like that. In practice, every non-trivial piece of code contains bugs. In practice, disk drives don't always behave as the driver expects: because of misconfiguration (e.g. enabling write-cache on drives without support for tagged command queueing), or because of bugs in the firm- ware, misunderstanding of the specs, or even intentional deviations from the spec by the vendor (which isn't all that unusual, unfortunately). Furthermore, if the crash is caused by hardware failure (e.g. power outage, pulling the plug, kicking the hard drive, disk head crash etc.), then _no_ piece of software can guarantee anything about the state of the filesystem. A full, regular fsck (non-background) is required in such cases, and even then there is no guarantee that you don't have corrupted files. The problem is that the code doesn't seem to be able to detect such cases reliably. Another cause of trouble is when the background fsck is interrupted in the middle by another crash. In my experience that's almost always guaranteed to cause serious corruption. > Which was what I was hoping to get out of this post, maybe someone will > read it down the line and provide some real facts of why it is or is not > dangerous to delay fsck's for an extended period of time. Well, above I provided some real facts and explained some potential risks. But it's up to yourself to decide whether it could be dangerous in your situation or not. Personally, it's my impression that pjd's new gjournal code -- even though it's still considered experimental -- seems to be more reliable than background fsck. It costs a bit of I/O performance, though, but if you put the journal on a dedicated disk, it's not that bad. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "What is this talk of 'release'? We do not make software 'releases'. Our software 'escapes', leaving a bloody trail of designers and quality assurance people in its wake." From owner-freebsd-fs@FreeBSD.ORG Thu Jan 11 11:45:29 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 793DB16A40F for ; Thu, 11 Jan 2007 11:45:29 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from mailhost.tao.org.uk (transwarp.tao.org.uk [87.74.4.34]) by mx1.freebsd.org (Postfix) with ESMTP id 29B4413C441 for ; Thu, 11 Jan 2007 11:45:27 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from genius.tao.org.uk (genius.tao.org.uk [87.74.4.41]) by mailhost.tao.org.uk (Postfix) with ESMTP id 985666EC7; Thu, 11 Jan 2007 11:45:25 +0000 (GMT) Received: by genius.tao.org.uk (Postfix, from userid 1000) id C0BB940EF; Thu, 11 Jan 2007 11:45:24 +0000 (GMT) Date: Thu, 11 Jan 2007 11:45:24 +0000 From: Josef Karthauser To: Peter Jeremy Message-ID: <20070111114524.GA13405@genius.tao.org.uk> References: <20070107232055.GA2450@genius.tao.org.uk> <20070109062606.GA853@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <20070109062606.GA853@turion.vk2pj.dyndns.org> User-Agent: Mutt/1.5.11 Cc: freebsd-fs@freebsd.org Subject: Re: Trouble booting second ide drive (gmirror configuration). X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2007 11:45:29 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 09, 2007 at 05:26:06PM +1100, Peter Jeremy wrote: >=20 > The logs you included showed the loader complaining "can't load 'kernel'" > rather than having a corrupt disklabel. >=20 > I presume you've confirmed that the disk actually has a kernel on it? Yes, it's a dump/restore of the existing root partition on the other disk, and I can mount it correctly and verify this when booted off drive zero. =20 > Does the geometry reported by the BIOS match the on-disk geometry from > fdisk? Have you tried toggling LBA? Hmm. How can I verify this? The machine is remote and I've not got access to the bios screen. =20 > When you're at the loader prompt, what do "ls /boot" and "ls /boot/kernel" > return? It will have to wait until a quiet period so I can reboot to verify, but my memory tells me that when I tried to see what was on the disk from the boot loader I got some message about inconsistent or corrupt disklabel. Is it possible that it's a bios issue and that the bios isn't correctly configured for this disk? How might I work around that if that's the case? This is what fdisk reports: ******* Working on device /dev/ad0 ******* parameters extracted from in-core disklabel are: cylinders=3D238216 heads=3D16 sectors/track=3D63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=3D238216 heads=3D16 sectors/track=3D63 (1008 blks/cyl) ******* Working on device /dev/ad1 ******* parameters extracted from in-core disklabel are: cylinders=3D238216 heads=3D16 sectors/track=3D63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=3D238216 heads=3D16 sectors/track=3D63 (1008 blks/cyl) and this is the boot time probe: ad0: 117246MB [238216/16/63] at ata0-master U= DMA100 ad1: 117246MB [238216/16/63] at ata0-slave UD= MA100 Joe --=20 =3D=3D=3D Josef Karthauser (joe@tao.org.uk) =3D=3D=3D http://x2obuilder.com= /tao =3D=3D=3D --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iEYEARECAAYFAkWmI1QACgkQXVIcjOaxUBZdswCggROrBAJzwmQ5/+pDiqA7U881 0ckAoOaCF5iAWTRU+g4UOGOyLCzg8LlV =XyLH -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- From owner-freebsd-fs@FreeBSD.ORG Thu Jan 11 16:04:41 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FB3116A40F for ; Thu, 11 Jan 2007 16:04:41 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3D44213C448 for ; Thu, 11 Jan 2007 16:04:41 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l0BG4cLG061666; Thu, 11 Jan 2007 10:04:38 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <45A66017.30003@centtech.com> Date: Thu, 11 Jan 2007 10:04:39 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5.0.9 (X11/20061223) MIME-Version: 1.0 To: Brooks Davis References: <45A3C96A.6030307@scottevil.com> <200701101139.l0ABdJ9K088810@lurza.secnetix.de> <45A485C6.2060405@scottevil.com> <45A5024F.10502@centtech.com> <20070110174337.GA7544@lor.one-eyed-alien.net> In-Reply-To: <20070110174337.GA7544@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2436/Thu Jan 11 05:48:19 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-fs@freebsd.org Subject: Re: skipping fsck with soft-updates enabled X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2007 16:04:41 -0000 On 01/10/07 11:43, Brooks Davis wrote: > On Wed, Jan 10, 2007 at 09:12:15AM -0600, Eric Anderson wrote: >> On 01/10/07 00:20, Scott Oertel wrote: >>> Victor Loureiro Lima wrote: >>> >From rc.conf man page: >>>> --- >>>> background_fsck_delay >>>> (int) The amount of time in seconds to sleep before >>>> starting >>>> a background fsck(8). It defaults to sixty seconds to >>>> allow >>>> large applications such as the X server to start >>>> before disk >>>> I/O bandwidth is monopolized by fsck(8). >>>> --- >>>> >>>> You can set the delay as long as you want, so it wont have to start >>>> right away, in fact it can start as late as a year (if thats really >>>> what you want ;)) >>>> >>>> att, >>>> victor loureiro lima >>>> >>>> 2007/1/10, Oliver Fromme : >>>>> Scott Oertel wrote: >>>>>> I am wondering what kind of problems would occur, besides lost >>>>> space, if >>>>>> after a system crash a fsck is skipped. According to the >>>>> documentation, >>>>>> with soft-updates enabled, the file system would be consistant, there >>>>>> would just be lost resources to be recovered which I am assuming >>>>> can be >>>>>> safely done at a later time to avoid long periods of downtime during >>>>>> peek hours. >>>>> I think that's exactly what the background fsck feature >>>>> does. If you enable it (which is even the default), the >>>>> fsck process doesn' start right away, so the system comes >>>>> up in multi-user mode immediately. Then a snapshot is >>>>> created on the file system, and fsck runs on the snap- >>>>> shot, freeing the lost space in the file system. >>>>> >>>>> Of course, it only works reliably with soft-updates enabled, >>>>> _and_ there must not be any unexpected inconsistencies. >>>>> However, with some common setups (e.g. cheap disks lying >>>>> about completed write operation) it is difficult to >>>>> guarantee the consistency. Soft-updates is rather fragile >>>>> when the hardware doesn't work exactly as it's supposed to. >>>>> I've witnessed breakage in the past, and for that reason >>>>> I always disable the background fsck feature. And it's the >>>>> reason I'm looking forward to gjournal to become stable, >>>>> because it seems to be less fragile in the presence of >>>>> imperfect hardware. >>>>> >>>>> Best regards >>>>> Oliver >>>>> >>>>> -- >>>>> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing >>>>> Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd >>>>> Any opinions expressed in this message may be personal to the author >>>>> and may not necessarily reflect the opinions of secnetix in any way. >>>>> >>>>> "C++ is to C as Lung Cancer is to Lung." >>>>> -- Thomas Funke >>>>> _______________________________________________ >>> The problem with background fsck is that on my machines, it doesn't work >>> well. These machines have 8x750gb SATA drives and they are under extreme >>> stress all the time. When you run fsck in the background each drive >>> takes 10+ minutes to create the snapshot file, during which time the >>> machine is completely unresponsive, and unstable. >> What version of FreeBSD are you running? You might try gjournal, which >> I've had great luck with, and Pawel (pjd@) is incredibly responsive to >> bug reports, etc. >> >>> That is why I am wondering, if it is ok to skip the background fsck's, >>> foreground fsck's and reschedule them for a later time, during non peak >>> hours. >> I think most people would be nervous to tell you 'sure, skip it until >> later', but I can tell you from experience that I myself have delayed >> fscking for weeks on end, to do exactly what you want. > > I've been thinking it would be useful to have a new background_fsck_delay > value of CRON and have a cron job that can accomplish the background > fsck during off hours if needed. > > -- Brooks I think an even better solution is to have a "NONE" option, that never does it. Then, you can just cron it whenever if you wish, or never if you wish. NONE is also more consistent with other rc-like options (I think). Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology An undefined problem has an infinite number of solutions. ------------------------------------------------------------------------ From owner-freebsd-fs@FreeBSD.ORG Thu Jan 11 16:15:52 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9349716A403 for ; Thu, 11 Jan 2007 16:15:52 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6BAD213C458 for ; Thu, 11 Jan 2007 16:15:52 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l0BGFjuv063777; Thu, 11 Jan 2007 10:15:45 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <45A662B2.9080801@centtech.com> Date: Thu, 11 Jan 2007 10:15:46 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5.0.9 (X11/20061223) MIME-Version: 1.0 To: Scott Oertel References: <45A3C96A.6030307@scottevil.com> <200701101139.l0ABdJ9K088810@lurza.secnetix.de> <45A485C6.2060405@scottevil.com> <45A5024F.10502@centtech.com> <45A511C0.9000402@scottevil.com> In-Reply-To: <45A511C0.9000402@scottevil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2436/Thu Jan 11 05:48:19 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-fs@freebsd.org Subject: Re: skipping fsck with soft-updates enabled X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2007 16:15:52 -0000 On 01/10/07 10:18, Scott Oertel wrote: > Eric Anderson wrote: >> On 01/10/07 00:20, Scott Oertel wrote: >>> Victor Loureiro Lima wrote: >>>> From rc.conf man page: >>>> --- >>>> background_fsck_delay >>>> (int) The amount of time in seconds to sleep before >>>> starting >>>> a background fsck(8). It defaults to sixty seconds >>>> to allow >>>> large applications such as the X server to start >>>> before disk >>>> I/O bandwidth is monopolized by fsck(8). >>>> --- >>>> >>>> You can set the delay as long as you want, so it wont have to start >>>> right away, in fact it can start as late as a year (if thats really >>>> what you want ;)) >>>> >>>> att, >>>> victor loureiro lima >>>> >>>> 2007/1/10, Oliver Fromme : >>>>> Scott Oertel wrote: >>>>> > I am wondering what kind of problems would occur, besides lost >>>>> space, if >>>>> > after a system crash a fsck is skipped. According to the >>>>> documentation, >>>>> > with soft-updates enabled, the file system would be consistant, >>>>> there >>>>> > would just be lost resources to be recovered which I am assuming >>>>> can be >>>>> > safely done at a later time to avoid long periods of downtime >>>>> during >>>>> > peek hours. >>>>> >>>>> I think that's exactly what the background fsck feature >>>>> does. If you enable it (which is even the default), the >>>>> fsck process doesn' start right away, so the system comes >>>>> up in multi-user mode immediately. Then a snapshot is >>>>> created on the file system, and fsck runs on the snap- >>>>> shot, freeing the lost space in the file system. >>>>> >>>>> Of course, it only works reliably with soft-updates enabled, >>>>> _and_ there must not be any unexpected inconsistencies. >>>>> However, with some common setups (e.g. cheap disks lying >>>>> about completed write operation) it is difficult to >>>>> guarantee the consistency. Soft-updates is rather fragile >>>>> when the hardware doesn't work exactly as it's supposed to. >>>>> I've witnessed breakage in the past, and for that reason >>>>> I always disable the background fsck feature. And it's the >>>>> reason I'm looking forward to gjournal to become stable, >>>>> because it seems to be less fragile in the presence of >>>>> imperfect hardware. >>>>> >>>>> Best regards >>>>> Oliver >>>>> >>>>> -- >>>>> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing >>>>> Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd >>>>> Any opinions expressed in this message may be personal to the author >>>>> and may not necessarily reflect the opinions of secnetix in any way. >>>>> >>>>> "C++ is to C as Lung Cancer is to Lung." >>>>> -- Thomas Funke >>>>> _______________________________________________ >>> The problem with background fsck is that on my machines, it doesn't >>> work well. These machines have 8x750gb SATA drives and they are under >>> extreme stress all the time. When you run fsck in the background each >>> drive takes 10+ minutes to create the snapshot file, during which >>> time the machine is completely unresponsive, and unstable. >> What version of FreeBSD are you running? You might try gjournal, >> which I've had great luck with, and Pawel (pjd@) is incredibly >> responsive to bug reports, etc. >> >>> That is why I am wondering, if it is ok to skip the background >>> fsck's, foreground fsck's and reschedule them for a later time, >>> during non peak hours. >> I think most people would be nervous to tell you 'sure, skip it until >> later', but I can tell you from experience that I myself have delayed >> fscking for weeks on end, to do exactly what you want. >> >> Eric >> >> >> > I'm running on 6.2-RC2. For fun I tried to create a snapshot on one of > our newest machines, same drive config as the previous ones, it's just > less active then the others. It's running 6.2RC2 and it just completely > locked up. Anyway, thanks for the suggestion about running gjournal, i'm > not sure running non-offical patches on the file system code with > production machines is such a great idea. Have you had any problems with > gjournal, if so, of what nature were they? > Honestly, I haven't had many issues with snapshots since 6.1-ish and before. There were lots of deadlocks, livelocks, etc. I think Kris@ has done a bang up job at finding bugs and getting them fixed. If you still see snapshot issues like this, it would be great if you could start sending some info like a ps -auxl, and if it's a deadlock, drop to the debugger and get a crash dump. As far as gjournal, I now have it running on several systems, all very high usage NFS servers (~1000 high end machines pounding them very hard, 24x7). I've only seen a few little issues on one of my systems that is running an older 6-STABLE (it's a little difficult for me to update it right now), but all my other systems have been very solid. PJD has done a great job getting it stable and ready for production use. As far as I have experienced, I have had no data loss, and no file system corruption using it. The worst that's happened is a livelock, followed by a reboot. Since it is indeed journaled, the reboot takes a few minutes, and the fsck takes a few *seconds* (on a 10TB volume). I would say, that using gjournal is more reliable over time, than relying on background fsck's. Gjournal is, however, still in a beta test mode, however you should do your own testing to evaluate it. You can always disable it very easily, without losing your data. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology An undefined problem has an infinite number of solutions. ------------------------------------------------------------------------ From owner-freebsd-fs@FreeBSD.ORG Thu Jan 11 18:17:48 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E19F316A529 for ; Thu, 11 Jan 2007 18:17:48 +0000 (UTC) (envelope-from freebsd@scottevil.com) Received: from relay.aplus.net (relay.aplus.net [216.55.128.212]) by mx1.freebsd.org (Postfix) with ESMTP id CB57913C4BF for ; Thu, 11 Jan 2007 18:17:48 +0000 (UTC) (envelope-from freebsd@scottevil.com) Received: from [216.55.129.230] by relay.aplus.net with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1H54Um-0001Z1-EN; Thu, 11 Jan 2007 10:17:48 -0800 Message-ID: <45A67F44.3000109@scottevil.com> Date: Thu, 11 Jan 2007 10:17:40 -0800 From: Scott Oertel User-Agent: Thunderbird 2.0b1 (X11/20061211) MIME-Version: 1.0 To: Eric Anderson , freebsd-fs@freebsd.org References: <45A3C96A.6030307@scottevil.com> <200701101139.l0ABdJ9K088810@lurza.secnetix.de> <45A485C6.2060405@scottevil.com> <45A5024F.10502@centtech.com> <45A511C0.9000402@scottevil.com> <45A662B2.9080801@centtech.com> In-Reply-To: <45A662B2.9080801@centtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: skipping fsck with soft-updates enabled X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2007 18:17:49 -0000 Eric Anderson wrote: > On 01/10/07 10:18, Scott Oertel wrote: >> Eric Anderson wrote: >>> On 01/10/07 00:20, Scott Oertel wrote: >>>> Victor Loureiro Lima wrote: >>>>> From rc.conf man page: >>>>> --- >>>>> background_fsck_delay >>>>> (int) The amount of time in seconds to sleep >>>>> before starting >>>>> a background fsck(8). It defaults to sixty >>>>> seconds to allow >>>>> large applications such as the X server to start >>>>> before disk >>>>> I/O bandwidth is monopolized by fsck(8). >>>>> --- >>>>> >>>>> You can set the delay as long as you want, so it wont have to start >>>>> right away, in fact it can start as late as a year (if thats really >>>>> what you want ;)) >>>>> >>>>> att, >>>>> victor loureiro lima >>>>> >>>>> 2007/1/10, Oliver Fromme : >>>>>> Scott Oertel wrote: >>>>>> > I am wondering what kind of problems would occur, besides lost >>>>>> space, if >>>>>> > after a system crash a fsck is skipped. According to the >>>>>> documentation, >>>>>> > with soft-updates enabled, the file system would be >>>>>> consistant, there >>>>>> > would just be lost resources to be recovered which I am >>>>>> assuming can be >>>>>> > safely done at a later time to avoid long periods of downtime >>>>>> during >>>>>> > peek hours. >>>>>> >>>>>> I think that's exactly what the background fsck feature >>>>>> does. If you enable it (which is even the default), the >>>>>> fsck process doesn' start right away, so the system comes >>>>>> up in multi-user mode immediately. Then a snapshot is >>>>>> created on the file system, and fsck runs on the snap- >>>>>> shot, freeing the lost space in the file system. >>>>>> >>>>>> Of course, it only works reliably with soft-updates enabled, >>>>>> _and_ there must not be any unexpected inconsistencies. >>>>>> However, with some common setups (e.g. cheap disks lying >>>>>> about completed write operation) it is difficult to >>>>>> guarantee the consistency. Soft-updates is rather fragile >>>>>> when the hardware doesn't work exactly as it's supposed to. >>>>>> I've witnessed breakage in the past, and for that reason >>>>>> I always disable the background fsck feature. And it's the >>>>>> reason I'm looking forward to gjournal to become stable, >>>>>> because it seems to be less fragile in the presence of >>>>>> imperfect hardware. >>>>>> >>>>>> Best regards >>>>>> Oliver >>>>>> >>>>>> -- >>>>>> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing >>>>>> Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd >>>>>> Any opinions expressed in this message may be personal to the author >>>>>> and may not necessarily reflect the opinions of secnetix in any way. >>>>>> >>>>>> "C++ is to C as Lung Cancer is to Lung." >>>>>> -- Thomas Funke >>>>>> _______________________________________________ >>>> The problem with background fsck is that on my machines, it doesn't >>>> work well. These machines have 8x750gb SATA drives and they are >>>> under extreme stress all the time. When you run fsck in the >>>> background each drive takes 10+ minutes to create the snapshot >>>> file, during which time the machine is completely unresponsive, and >>>> unstable. >>> What version of FreeBSD are you running? You might try gjournal, >>> which I've had great luck with, and Pawel (pjd@) is incredibly >>> responsive to bug reports, etc. >>> >>>> That is why I am wondering, if it is ok to skip the background >>>> fsck's, foreground fsck's and reschedule them for a later time, >>>> during non peak hours. >>> I think most people would be nervous to tell you 'sure, skip it >>> until later', but I can tell you from experience that I myself have >>> delayed fscking for weeks on end, to do exactly what you want. >>> >>> Eric >>> >>> >>> >> I'm running on 6.2-RC2. For fun I tried to create a snapshot on one >> of our newest machines, same drive config as the previous ones, it's >> just less active then the others. It's running 6.2RC2 and it just >> completely locked up. Anyway, thanks for the suggestion about running >> gjournal, i'm not sure running non-offical patches on the file system >> code with production machines is such a great idea. Have you had any >> problems with gjournal, if so, of what nature were they? >> > > > Honestly, I haven't had many issues with snapshots since 6.1-ish and > before. There were lots of deadlocks, livelocks, etc. I think Kris@ > has done a bang up job at finding bugs and getting them fixed. If you > still see snapshot issues like this, it would be great if you could > start sending some info like a ps -auxl, and if it's a deadlock, drop > to the debugger and get a crash dump. What size are the hard drives you're creating snapshots of? is it > 750gb? If it is then I would be happy to find a resolution for the snapshot issue by providing debug info and such. > > As far as gjournal, I now have it running on several systems, all very > high usage NFS servers (~1000 high end machines pounding them very > hard, 24x7). I've only seen a few little issues on one of my systems > that is running an older 6-STABLE (it's a little difficult for me to > update it right now), but all my other systems have been very solid. > PJD has done a great job getting it stable and ready for production > use. As far as I have experienced, I have had no data loss, and no > file system corruption using it. The worst that's happened is a > livelock, followed by a reboot. Since it is indeed journaled, the > reboot takes a few minutes, and the fsck takes a few *seconds* (on a > 10TB volume). I would say, that using gjournal is more reliable over > time, than relying on background fsck's. Gjournal is, however, still > in a beta test mode, however you should do your own testing to > evaluate it. You can always disable it very easily, without losing > your data. > > Eric > > > I'll go ahead and give gjournal a test run on a test machine, and see how I like it. Thank you for the information based on your experiences with it. -Scott From owner-freebsd-fs@FreeBSD.ORG Thu Jan 11 18:25:18 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 47DCF16A40F for ; Thu, 11 Jan 2007 18:25:18 +0000 (UTC) (envelope-from freebsd@scottevil.com) Received: from relay.aplus.net (relay.aplus.net [216.55.128.212]) by mx1.freebsd.org (Postfix) with ESMTP id 31C0913C4A9 for ; Thu, 11 Jan 2007 18:25:18 +0000 (UTC) (envelope-from freebsd@scottevil.com) Received: from [216.55.129.230] by relay.aplus.net with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1H54c1-0002JS-Pv; Thu, 11 Jan 2007 10:25:18 -0800 Message-ID: <45A68105.9060506@scottevil.com> Date: Thu, 11 Jan 2007 10:25:09 -0800 From: Scott Oertel User-Agent: Thunderbird 2.0b1 (X11/20061211) MIME-Version: 1.0 To: freebsd-fs@FreeBSD.ORG, freebsd@scottevil.com References: <200701110841.l0B8foK1067682@lurza.secnetix.de> In-Reply-To: <200701110841.l0B8foK1067682@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: skipping fsck with soft-updates enabled X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2007 18:25:18 -0000 Oliver Fromme wrote: > Scott Oertel wrote: > > I'll probably do some testing with the effects of delaying fsck for long > > periods of time using soft-updates. Personally, I haven't found anyone > > stating any hard facts that would leave me to believe that running on a > > dirty filesystem for an extended period of time won't cause further > > inconsistencies. > > s/further// > > If soft-updates is running correctly on the drive, then > there are _no_ inconsistencies on the file systems after > a crash. And there's no reason why any inconsistencies > should appear later on. > I don't believe that you can say that there are "_no_ inconsistencies" 100% of the time guaranteed. > The only thing that's "dirty" about the file systems is > unused space that's still marked as used, which means > that it is not available to new allocations when writing > data. That's not harmful (unless you run out of disk > space, of course). > > The only thing that fsck will do in that situation -- no > matter whether regular fsck or background fsck -- is to > find those unused areas and mark them as free. It does > not matter whether that's done immediately after the > reboot, or a few hours later, or a month later, or even > never at all. The only drawback is that some disk space > is unavailable for new allocations until fsck cleans it > up. > > All of the above is theory, and it _should_ work exactly > like that. In practice, every non-trivial piece of code > contains bugs. In practice, disk drives don't always > behave as the driver expects: because of misconfiguration > (e.g. enabling write-cache on drives without support for > tagged command queueing), or because of bugs in the firm- > ware, misunderstanding of the specs, or even intentional > deviations from the spec by the vendor (which isn't all > that unusual, unfortunately). > "Theory", this is what makes me a little nervous about putting into daily practice on production machines. > Furthermore, if the crash is caused by hardware failure > (e.g. power outage, pulling the plug, kicking the hard > drive, disk head crash etc.), then _no_ piece of software > can guarantee anything about the state of the filesystem. > A full, regular fsck (non-background) is required in such > cases, and even then there is no guarantee that you don't > have corrupted files. The problem is that the code doesn't > seem to be able to detect such cases reliably. Another > cause of trouble is when the background fsck is interrupted > in the middle by another crash. In my experience that's > almost always guaranteed to cause serious corruption. > > ^^ This is why you can't guarantee 100% consistency, correct? > > Which was what I was hoping to get out of this post, maybe someone will > > read it down the line and provide some real facts of why it is or is not > > dangerous to delay fsck's for an extended period of time. > > Well, above I provided some real facts and explained > some potential risks. But it's up to yourself to decide > whether it could be dangerous in your situation or not. > > Personally, it's my impression that pjd's new gjournal > code -- even though it's still considered experimental -- > seems to be more reliable than background fsck. It > costs a bit of I/O performance, though, but if you put > the journal on a dedicated disk, it's not that bad. > > Best regards > Oliver > > Thank you for the long and in depth review on my post, the information you provided is very useful. I've been hearing all sorts of good things about gjournal, so I'm going to put it into a testing environment and stress test it a bit. If it proves to be reliable I might place it on the machines that are failing frequently, but probably not for a while. --Scott From owner-freebsd-fs@FreeBSD.ORG Thu Jan 11 20:23:58 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C49516A415 for ; Thu, 11 Jan 2007 20:23:58 +0000 (UTC) (envelope-from ahnjoan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id ECAED13C457 for ; Thu, 11 Jan 2007 20:23:57 +0000 (UTC) (envelope-from ahnjoan@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so532174uge for ; Thu, 11 Jan 2007 12:23:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ojJPhEUGjlprU2PXl3dxtIGwwHGVZyFEkDSlmbhU5L2j7obJXPHTGM7cBhvZb7UJCdHgU4AMq9zmxDEntxVCcKlUE/ZEXyLmctsxK+OCmlzQhdK/lRZHS7bNgeNn4yLG7zQitcp4ZOxwBebRSHf+0FCr6BrGdqtJDr7Wacs1sGU= Received: by 10.78.149.15 with SMTP id w15mr669425hud.1168545347221; Thu, 11 Jan 2007 11:55:47 -0800 (PST) Received: by 10.78.11.6 with HTTP; Thu, 11 Jan 2007 11:55:47 -0800 (PST) Message-ID: <5e575c8a0701111155l859d0ecif617dbda43cef842@mail.gmail.com> Date: Thu, 11 Jan 2007 14:55:47 -0500 From: "Ahnjoan Amous" To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: aac scsi raid driver performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2007 20:23:58 -0000 I'm trying to find possible explanations for slow concurrent writes through the aac driver. This machine runs under 1% load and has less than 4 transfers per second to the drives in question when not being used for testing. When I attempt sequential "dd"s as follow, the results are better then 70MB/sec. dd if=/dev/zero of=/data02/helloworld bs=1m count=1000 1048576000 bytes transferred in 13.886718 secs (75509274 bytes/sec) dd if=/dev/zero of=/data03/helloworld bs=1m count=1000 1048576000 bytes transferred in 14.011323 secs (74837758 bytes/sec) When I attempt concurrent "dd"s as follow, with a 1 second sleep interval between starts, the results are better than 40MB/sec dd if=/dev/zero of=/data02/helloworld bs=1m count=1000 & sleep 1 dd if=/dev/zero of=/data03/helloworld bs=1m count=1000 & 1048576000 bytes transferred in 25.269555 secs (41495626 bytes/sec) 1048576000 bytes transferred in 24.935765 secs (42051086 bytes/sec) When I attempt concurrent "dd"s as follow, the results are little better than 20MB/sec dd if=/dev/zero of=/data02/helloworld bs=1m count=1000 & dd if=/dev/zero of=/data03/helloworld bs=1m count=1000 & 1048576000 bytes transferred in 44.963408 secs (23320652 bytes/sec) 1048576000 bytes transferred in 45.010065 secs (23296478 bytes/sec) I can't account for what causes the huge difference however the results are reproducible. I've run the tests dozens and dozens of times now, first blaming the em driver for my slow ggatec/ggated results, then GEOM for my slow local mirroring after eliminating the network, and finally blaming the aac driver after removing GEOM from the equation. If anyone has ideas on what I might look at or change or test I would love to hear. ****** Misc. Information ****** root:somehost:~ > df -k Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/aacd2s1e 2026030 1024532 839416 55% /data02 /dev/aacd3s1e 2026030 1024532 839416 55% /data03 Hardware - aac - Dell PERC3/Di U160 aacd2 - hardware RAID 0, w/1 U320 300G drive aacd3 - hardware RAID 0, w/1 U320 300G drive From owner-freebsd-fs@FreeBSD.ORG Thu Jan 11 21:07:28 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 191E416A415 for ; Thu, 11 Jan 2007 21:07:28 +0000 (UTC) (envelope-from ahnjoan@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by mx1.freebsd.org (Postfix) with ESMTP id AD8F513C43E for ; Thu, 11 Jan 2007 21:07:27 +0000 (UTC) (envelope-from ahnjoan@gmail.com) Received: by wr-out-0506.google.com with SMTP id i28so314630wra for ; Thu, 11 Jan 2007 13:07:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DmO/1TwUkLDEuyRTPh1ZeRrIej3qaMKMfFDJrjtoTo+W2+C4NGXKh7TKD8n/REHfW2IfufdbjQ3oyY4hOMD/6k7PCx7RhCvdVsTfhoucpJ1fP3SRKjSp9rCnmLWmEDx3RIdNESfh99ynXdQasecOkZjdpUKFk+dS0bIUpuq3gRM= Received: by 10.78.136.9 with SMTP id j9mr713704hud.1168549642440; Thu, 11 Jan 2007 13:07:22 -0800 (PST) Received: by 10.78.11.6 with HTTP; Thu, 11 Jan 2007 13:07:22 -0800 (PST) Message-ID: <5e575c8a0701111307s5a839b82ra4ba5c45d554d3b9@mail.gmail.com> Date: Thu, 11 Jan 2007 16:07:22 -0500 From: "Ahnjoan Amous" To: "Scott Long" In-Reply-To: <45A6A138.8090208@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5e575c8a0701111155l859d0ecif617dbda43cef842@mail.gmail.com> <45A6A138.8090208@samsco.org> Cc: freebsd-fs@freebsd.org Subject: Re: aac scsi raid driver performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2007 21:07:28 -0000 I reset the controller to the defaults for everything before I did the installation. Each of the containers were created with the following options. Container Type - RAID 0 Container Label - data03 Container Size - 279.396 GB Chunk Size - 64KB Read Caching (Yes/No) - Y Write Caching : Enable when protected Create RAID 5 via - N/A Then the controller itself has a single cache option Drives Write Cache - Disabled Thanks Ahnjoan On 1/11/07, Scott Long wrote: > Did you enable read caching for the arrays? > > Scott > > > Ahnjoan Amous wrote: > > I'm trying to find possible explanations for slow concurrent writes > > through the > > aac driver. This machine runs under 1% load and has less than 4 > > transfers per > > second to the drives in question when not being used for testing. > > > > When I attempt sequential "dd"s as follow, the results are better then > > 70MB/sec. > > dd if=/dev/zero of=/data02/helloworld bs=1m count=1000 > > 1048576000 bytes transferred in 13.886718 secs (75509274 bytes/sec) > > dd if=/dev/zero of=/data03/helloworld bs=1m count=1000 > > 1048576000 bytes transferred in 14.011323 secs (74837758 bytes/sec) > > > > When I attempt concurrent "dd"s as follow, with a 1 second sleep interval > > between starts, the results are better than 40MB/sec > > dd if=/dev/zero of=/data02/helloworld bs=1m count=1000 & > > sleep 1 > > dd if=/dev/zero of=/data03/helloworld bs=1m count=1000 & > > 1048576000 bytes transferred in 25.269555 secs (41495626 bytes/sec) > > 1048576000 bytes transferred in 24.935765 secs (42051086 bytes/sec) > > > > When I attempt concurrent "dd"s as follow, the results are little better > > than > > 20MB/sec > > dd if=/dev/zero of=/data02/helloworld bs=1m count=1000 & > > dd if=/dev/zero of=/data03/helloworld bs=1m count=1000 & > > 1048576000 bytes transferred in 44.963408 secs (23320652 bytes/sec) > > 1048576000 bytes transferred in 45.010065 secs (23296478 bytes/sec) > > > > I can't account for what causes the huge difference however the results are > > reproducible. I've run the tests dozens and dozens of times now, first > > blaming > > the em driver for my slow ggatec/ggated results, then GEOM for my slow > > local > > mirroring after eliminating the network, and finally blaming the aac driver > > after removing GEOM from the equation. If anyone has ideas on what I might > > look at or change or test I would love to hear. > > > > > > ****** Misc. Information ****** > > root:somehost:~ > df -k > > Filesystem 1K-blocks Used Avail Capacity Mounted on > > /dev/aacd2s1e 2026030 1024532 839416 55% /data02 > > /dev/aacd3s1e 2026030 1024532 839416 55% /data03 > > Hardware - > > aac - Dell PERC3/Di U160 > > aacd2 - hardware RAID 0, w/1 U320 300G drive > > aacd3 - hardware RAID 0, w/1 U320 300G drive > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > From owner-freebsd-fs@FreeBSD.ORG Thu Jan 11 21:10:29 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 035E616A50A for ; Thu, 11 Jan 2007 21:10:29 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 2505413C457 for ; Thu, 11 Jan 2007 21:10:27 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id l0BKgWcc023440; Thu, 11 Jan 2007 13:42:38 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <45A6A138.8090208@samsco.org> Date: Thu, 11 Jan 2007 13:42:32 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20061227 SeaMonkey/1.1 MIME-Version: 1.0 To: Ahnjoan Amous References: <5e575c8a0701111155l859d0ecif617dbda43cef842@mail.gmail.com> In-Reply-To: <5e575c8a0701111155l859d0ecif617dbda43cef842@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Thu, 11 Jan 2007 13:42:38 -0700 (MST) X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-fs@freebsd.org Subject: Re: aac scsi raid driver performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2007 21:10:29 -0000 Did you enable read caching for the arrays? Scott Ahnjoan Amous wrote: > I'm trying to find possible explanations for slow concurrent writes > through the > aac driver. This machine runs under 1% load and has less than 4 > transfers per > second to the drives in question when not being used for testing. > > When I attempt sequential "dd"s as follow, the results are better then > 70MB/sec. > dd if=/dev/zero of=/data02/helloworld bs=1m count=1000 > 1048576000 bytes transferred in 13.886718 secs (75509274 bytes/sec) > dd if=/dev/zero of=/data03/helloworld bs=1m count=1000 > 1048576000 bytes transferred in 14.011323 secs (74837758 bytes/sec) > > When I attempt concurrent "dd"s as follow, with a 1 second sleep interval > between starts, the results are better than 40MB/sec > dd if=/dev/zero of=/data02/helloworld bs=1m count=1000 & > sleep 1 > dd if=/dev/zero of=/data03/helloworld bs=1m count=1000 & > 1048576000 bytes transferred in 25.269555 secs (41495626 bytes/sec) > 1048576000 bytes transferred in 24.935765 secs (42051086 bytes/sec) > > When I attempt concurrent "dd"s as follow, the results are little better > than > 20MB/sec > dd if=/dev/zero of=/data02/helloworld bs=1m count=1000 & > dd if=/dev/zero of=/data03/helloworld bs=1m count=1000 & > 1048576000 bytes transferred in 44.963408 secs (23320652 bytes/sec) > 1048576000 bytes transferred in 45.010065 secs (23296478 bytes/sec) > > I can't account for what causes the huge difference however the results are > reproducible. I've run the tests dozens and dozens of times now, first > blaming > the em driver for my slow ggatec/ggated results, then GEOM for my slow > local > mirroring after eliminating the network, and finally blaming the aac driver > after removing GEOM from the equation. If anyone has ideas on what I might > look at or change or test I would love to hear. > > > ****** Misc. Information ****** > root:somehost:~ > df -k > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/aacd2s1e 2026030 1024532 839416 55% /data02 > /dev/aacd3s1e 2026030 1024532 839416 55% /data03 > Hardware - > aac - Dell PERC3/Di U160 > aacd2 - hardware RAID 0, w/1 U320 300G drive > aacd3 - hardware RAID 0, w/1 U320 300G drive > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Fri Jan 12 09:30:16 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 372A216A407 for ; Fri, 12 Jan 2007 09:30:16 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id D4E3113C428 for ; Fri, 12 Jan 2007 09:30:15 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id l0C9U53q027930; Fri, 12 Jan 2007 02:30:11 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <45A7551C.5030006@samsco.org> Date: Fri, 12 Jan 2007 02:30:04 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20061227 SeaMonkey/1.1 MIME-Version: 1.0 To: Ahnjoan Amous References: <5e575c8a0701111155l859d0ecif617dbda43cef842@mail.gmail.com> <45A6A138.8090208@samsco.org> <5e575c8a0701111307s5a839b82ra4ba5c45d554d3b9@mail.gmail.com> In-Reply-To: <5e575c8a0701111307s5a839b82ra4ba5c45d554d3b9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 12 Jan 2007 02:30:11 -0700 (MST) X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-fs@freebsd.org Subject: Re: aac scsi raid driver performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2007 09:30:16 -0000 Turn off read caching Ahnjoan Amous wrote: > I reset the controller to the defaults for everything before I did the > installation. > > Each of the containers were created with the following options. > Container Type - RAID 0 > Container Label - data03 > Container Size - 279.396 GB > Chunk Size - 64KB > Read Caching (Yes/No) - Y > Write Caching : Enable when protected > Create RAID 5 via - N/A > > Then the controller itself has a single cache option > Drives Write Cache - Disabled > > Thanks > Ahnjoan > > On 1/11/07, Scott Long wrote: >> Did you enable read caching for the arrays? >> >> Scott >> >> >> Ahnjoan Amous wrote: >> > I'm trying to find possible explanations for slow concurrent writes >> > through the >> > aac driver. This machine runs under 1% load and has less than 4 >> > transfers per >> > second to the drives in question when not being used for testing. >> > >> > When I attempt sequential "dd"s as follow, the results are better then >> > 70MB/sec. >> > dd if=/dev/zero of=/data02/helloworld bs=1m count=1000 >> > 1048576000 bytes transferred in 13.886718 secs (75509274 bytes/sec) >> > dd if=/dev/zero of=/data03/helloworld bs=1m count=1000 >> > 1048576000 bytes transferred in 14.011323 secs (74837758 bytes/sec) >> > >> > When I attempt concurrent "dd"s as follow, with a 1 second sleep >> interval >> > between starts, the results are better than 40MB/sec >> > dd if=/dev/zero of=/data02/helloworld bs=1m count=1000 & >> > sleep 1 >> > dd if=/dev/zero of=/data03/helloworld bs=1m count=1000 & >> > 1048576000 bytes transferred in 25.269555 secs (41495626 bytes/sec) >> > 1048576000 bytes transferred in 24.935765 secs (42051086 bytes/sec) >> > >> > When I attempt concurrent "dd"s as follow, the results are little >> better >> > than >> > 20MB/sec >> > dd if=/dev/zero of=/data02/helloworld bs=1m count=1000 & >> > dd if=/dev/zero of=/data03/helloworld bs=1m count=1000 & >> > 1048576000 bytes transferred in 44.963408 secs (23320652 bytes/sec) >> > 1048576000 bytes transferred in 45.010065 secs (23296478 bytes/sec) >> > >> > I can't account for what causes the huge difference however the >> results are >> > reproducible. I've run the tests dozens and dozens of times now, first >> > blaming >> > the em driver for my slow ggatec/ggated results, then GEOM for my slow >> > local >> > mirroring after eliminating the network, and finally blaming the aac >> driver >> > after removing GEOM from the equation. If anyone has ideas on what >> I might >> > look at or change or test I would love to hear. >> > >> > >> > ****** Misc. Information ****** >> > root:somehost:~ > df -k >> > Filesystem 1K-blocks Used Avail Capacity Mounted on >> > /dev/aacd2s1e 2026030 1024532 839416 55% /data02 >> > /dev/aacd3s1e 2026030 1024532 839416 55% /data03 >> > Hardware - >> > aac - Dell PERC3/Di U160 >> > aacd2 - hardware RAID 0, w/1 U320 300G drive >> > aacd3 - hardware RAID 0, w/1 U320 300G drive >> > _______________________________________________ >> > freebsd-fs@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> >> From owner-freebsd-fs@FreeBSD.ORG Sat Jan 13 15:03:22 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD21316A40F for ; Sat, 13 Jan 2007 15:03:22 +0000 (UTC) (envelope-from ahnjoan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id 7AE5D13C442 for ; Sat, 13 Jan 2007 15:03:22 +0000 (UTC) (envelope-from ahnjoan@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so912881uge for ; Sat, 13 Jan 2007 07:03:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Nek7qtE9qXOrqAf8DfAV4HjqSstidv4kEF6aLYvYLOJKD5s+mfCVXyxfNaMXDlQH45q7CD+AXa1O0rAoa864U+KRoWZw5oOMRmKkTAI8kdi3rN2H+MaHUxq99W9RYqeSJvdCDvZsIv4eb7IAsIjfyFTn/T0qxax+dcZXuWAxiIM= Received: by 10.78.200.3 with SMTP id x3mr1220449huf.1168700601173; Sat, 13 Jan 2007 07:03:21 -0800 (PST) Received: by 10.78.11.6 with HTTP; Sat, 13 Jan 2007 07:03:20 -0800 (PST) Message-ID: <5e575c8a0701130703y6c528cecoed9019472a4956c8@mail.gmail.com> Date: Sat, 13 Jan 2007 10:03:20 -0500 From: "Ahnjoan Amous" To: "Scott Long" In-Reply-To: <45A7551C.5030006@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5e575c8a0701111155l859d0ecif617dbda43cef842@mail.gmail.com> <45A6A138.8090208@samsco.org> <5e575c8a0701111307s5a839b82ra4ba5c45d554d3b9@mail.gmail.com> <45A7551C.5030006@samsco.org> Cc: freebsd-fs@freebsd.org Subject: Re: aac scsi raid driver performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2007 15:03:22 -0000 Scott - I disabled read cache on both containers and the end result for my write tests is still 25M/sec. I have included the output to aaccli to confirm that I disabled the correct cache. Maybe I'm just expecting too much from the PE2650 with PERC 3/di. I know there are a lot of variables in this equation but what speeds would you expect for this U160 scsi raid controller front ending U320 devices on a box with no load and no i/o, other than two concurrent dd's to two different ufs mounted hardware raid 0 volumes? Thanks Ahnjoan AAC0> container show cache 2 Read Cache Setting : DISABLE Write Cache Setting : ENABLE WHEN PROTECTED Write Cache Status : Active, protected AAC0> container show cache 3 Read Cache Setting : DISABLE Write Cache Setting : ENABLE WHEN PROTECTED Write Cache Status : Active, protected On 1/12/07, Scott Long wrote: > Turn off read caching > > Ahnjoan Amous wrote: > > I reset the controller to the defaults for everything before I did the > > installation. > > > > Each of the containers were created with the following options. > > Container Type - RAID 0 > > Container Label - data03 > > Container Size - 279.396 GB > > Chunk Size - 64KB > > Read Caching (Yes/No) - Y > > Write Caching : Enable when protected > > Create RAID 5 via - N/A > > > > Then the controller itself has a single cache option > > Drives Write Cache - Disabled > > > > Thanks > > Ahnjoan > > > > On 1/11/07, Scott Long wrote: > >> Did you enable read caching for the arrays? > >> > >> Scott > >> > >> > >> Ahnjoan Amous wrote: > >> > I'm trying to find possible explanations for slow concurrent writes > >> > through the > >> > aac driver. This machine runs under 1% load and has less than 4 > >> > transfers per > >> > second to the drives in question when not being used for testing. > >> > > >> > When I attempt sequential "dd"s as follow, the results are better then > >> > 70MB/sec. > >> > dd if=/dev/zero of=/data02/helloworld bs=1m count=1000 > >> > 1048576000 bytes transferred in 13.886718 secs (75509274 bytes/sec) > >> > dd if=/dev/zero of=/data03/helloworld bs=1m count=1000 > >> > 1048576000 bytes transferred in 14.011323 secs (74837758 bytes/sec) > >> > > >> > When I attempt concurrent "dd"s as follow, with a 1 second sleep > >> interval > >> > between starts, the results are better than 40MB/sec > >> > dd if=/dev/zero of=/data02/helloworld bs=1m count=1000 & > >> > sleep 1 > >> > dd if=/dev/zero of=/data03/helloworld bs=1m count=1000 & > >> > 1048576000 bytes transferred in 25.269555 secs (41495626 bytes/sec) > >> > 1048576000 bytes transferred in 24.935765 secs (42051086 bytes/sec) > >> > > >> > When I attempt concurrent "dd"s as follow, the results are little > >> better > >> > than > >> > 20MB/sec > >> > dd if=/dev/zero of=/data02/helloworld bs=1m count=1000 & > >> > dd if=/dev/zero of=/data03/helloworld bs=1m count=1000 & > >> > 1048576000 bytes transferred in 44.963408 secs (23320652 bytes/sec) > >> > 1048576000 bytes transferred in 45.010065 secs (23296478 bytes/sec) > >> > > >> > I can't account for what causes the huge difference however the > >> results are > >> > reproducible. I've run the tests dozens and dozens of times now, first > >> > blaming > >> > the em driver for my slow ggatec/ggated results, then GEOM for my slow > >> > local > >> > mirroring after eliminating the network, and finally blaming the aac > >> driver > >> > after removing GEOM from the equation. If anyone has ideas on what > >> I might > >> > look at or change or test I would love to hear. > >> > > >> > > >> > ****** Misc. Information ****** > >> > root:somehost:~ > df -k > >> > Filesystem 1K-blocks Used Avail Capacity Mounted on > >> > /dev/aacd2s1e 2026030 1024532 839416 55% /data02 > >> > /dev/aacd3s1e 2026030 1024532 839416 55% /data03 > >> > Hardware - > >> > aac - Dell PERC3/Di U160 > >> > aacd2 - hardware RAID 0, w/1 U320 300G drive > >> > aacd3 - hardware RAID 0, w/1 U320 300G drive > >> > _______________________________________________ > >> > freebsd-fs@freebsd.org mailing list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > >> > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > >> > >> > >