From owner-freebsd-geom@FreeBSD.ORG Mon Jun 19 11:02:52 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 645DE16A481 for ; Mon, 19 Jun 2006 11:02:52 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EFC643D46 for ; Mon, 19 Jun 2006 11:02:52 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5JB2phs064164 for ; Mon, 19 Jun 2006 11:02:51 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5JB2oPO064160 for freebsd-geom@freebsd.org; Mon, 19 Jun 2006 11:02:50 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 19 Jun 2006 11:02:50 GMT Message-Id: <200606191102.k5JB2oPO064160@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-geom@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 11:02:52 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/01/21] kern/76538 geom [gbde] nfs-write on gbde partition stalls o [2005/08/04] kern/84556 geom [geom] GBDE-encrypted swap causes panic a o [2005/10/16] kern/87544 geom [gbde] mmaping large files on a gbde file o [2005/11/16] kern/89102 geom [geom_vfs] [panic] panic when forced unmo o [2005/12/08] bin/90093 geom fdisk(8) incapable of altering in-core ge o [2005/12/18] kern/90582 geom [geom_mirror] [panic] Restore cause panic o [2006/04/15] kern/95771 geom [geom] geom mirror provider destroyed (ma o [2006/05/27] kern/98034 geom [geom] dereference of NULL pointer in acd o [2006/05/29] kern/98093 geom [geli] Detaching gmirror/geli leads to pa o [2006/06/09] kern/98742 geom [geli] IO errors while using geli 10 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/02/26] bin/78131 geom gbde "destroy" not working. o [2005/03/26] kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o [2006/03/18] kern/94632 geom [geom] Kernel output resets input while G o [2006/06/05] kern/98538 geom [geom] Kernel panic on ggate destroy 4 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Jun 19 13:13:59 2006 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E836D16A47A; Mon, 19 Jun 2006 13:13:58 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E08E43D69; Mon, 19 Jun 2006 13:13:43 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id A483851339; Mon, 19 Jun 2006 15:13:41 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id F377750E81; Mon, 19 Jun 2006 15:13:34 +0200 (CEST) Date: Mon, 19 Jun 2006 15:11:01 +0200 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org Message-ID: <20060619131101.GD1130@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rJwd6BRFiFCcLxzm" Content-Disposition: inline X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 13:13:59 -0000 --rJwd6BRFiFCcLxzm Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello. For the last few months I have been working on gjournal project. To stop confusion right here, I want to note, that this project is not related to gjournal project on which Ivan Voras was working on the last SoC (2005). The lack of journaled file system in FreeBSD was a tendon of achilles for many years. We do have many file systems, but none with journaling: - ext2fs (journaling is in ext3fs), - XFS (read-only), - ReiserFS (read-only), - HFS+ (read-write, but without journaling), - NTFS (read-only). GJournal was designed to journal GEOM providers, so it actually works below file system layer, but it has hooks which allow to work with file systems. In other words, gjournal is not file system-depended, it can work probably with any file system with minimum knowledge about it. I implemented only UFS support. The patches are here: http://people.freebsd.org/~pjd/patches/gjournal.patch (for HEAD) http://people.freebsd.org/~pjd/patches/gjournal6.patch (for RELENG_6) To patch your sources you need to: # cd /usr/src # mkdir sbin/geom/class/journal sys/geom/journal sys/modules/geom/geom_jou= rnal # patch < /path/to/gjournal.patch Add 'options UFS_GJOURNAL' to your kernel configuration file and recompile kernel and world. How it works (in short). You may define one or two providers which gjournal will use. If one provider is given, it will be used for both - data and journal. If two providers are given, one will be used for data and one for journal. Every few seconds (you may define how many) journal is terminated and marked as consistent and gjournal starts to copy data from it to the data provider. In the same time new data are stored in new journal. Let's call the moment in which journal is terminated as "journal switch". Journal switch looks as follows: 1. Start journal switch if we have timeout or if we run out of cache. Don't perform journal switch if there were no write requests. 2. If we have file system, synchronize it. 3. Mark file system as clean. 4. Block all write requests to the file system. 5. Terminate the journal. 6. Eventually wait if copying of the previous journal is not yet finished. 7. Send BIO_FLUSH request (if the given provider supports it). 8. Mark new journal position on the journal provider. 9. Unblock write requests. 10. Start copying data from the terminated journal to the data provider. There were few things I needed to implement outside gjournal to make it work reliable: - The BIO_FLUSH request. Currently we have three I/O requests: BIO_READ, BIO_WRITE and BIO_DELETE. I added BIO_FLUSH, which means "flush your write cache". The request is send always with the biggest bio_offset set (mediasize of the destination provider), so it will work properly with bioq_disksort(). The caller need to stop further I/O requests before BIO_FLUSH return, so we don't have starvation effect. The hard part is that is has to be implemented in every disk driver, because flushing the cache is driver-depended operation. I implemented it for ata(4) disks and amr(4). The good news is that it's easy. GJournal can also work with providers that don't support BIO_FLUSH and in my power-failure tests it worked well (no problems), but it depend on fact, that gjournal cache is bigger than the controller cache, so it is hard to call it reliable. You can read in documentation to many journaled file systems, that you should turn off write cache if you want to use it. This is not the case for gjournal (especially when your disk driver does support BIO_FLUSH). The 'gjournal' mount option. To implement gjournal support in UFS I needed to change the way of how deleted, but still open objects are handled. Currently when file or directory is open and we deleted last name which reference it, it will still be usable by those who keep it open. When the last consumer closes it, the inode and blocks are freed. On journal switch I cannot leave such objects, because after a crash fsck(8) is not used to check the file system, so inode and blocks will never be freed. When file system is mounted with 'gjournal' mount option, such objects are not removed when they are open. When last name is deleted, the file/directory is moved to the .deleted/ directory and removed from there on last close. This way, I can just clean the .deleted/ directory after a crash at mount time. Quick start: # gjournal label /dev/ad0 # gjournal load # newfs /dev/ad0.journal # mount -o async,gjournal /dev/ad0.journal /mnt (yes, with gjournal 'async' is safe) Now, after a power failure or system crash no fsck is needed (yay!). There are two hacks in the current implementation, which I'd like to reimplement. First is how 'gjournal' mount option is implemented. There is a garbage collector thread which is responsible for deleting objects from .deleted/ directory and it is using full paths. Because of this when your mount point is /foo/bar/baz and you rename 'bar' to something else, it will not work. This is not what is often done, but definitely should be fixed and I'm working on it. The second hack is related to communication between gjournal and file system. GJournal decides when to make the switch and has to find file system which is mounted on it. Looking for this file system is not nice and should be reimplemented. There are some additional goods which came with gjournal. For example if gjournal is configured over gmirror or graid3, even on power failure or system crash, there is no need to synchronize mirror/raid3 device, because data will be consistent. I spend a lot of time working on gjournal optimization. Because I've few seconds before the data hit the data provider I can perform things like combining smaller write requests into larger once, ignoring data written twice to the same place, etc. Because of this, operations on small files are quite fast. On the other hand, operations on large files are slower, because I need to write the data twice and there is no place for optimization. Here are some numbers. gjournal(1) - the data provider and the journal provider on the same disk gjournal(2) - the data provider and the journal provider on separate disks Copying one large file: UFS: 8s UFS+SU: 8s gjournal(1): 16s gjournal(2): 14s Copying eight large files in parallel: UFS: 120s UFS+SU: 120s gjournal(1): 184s gjournal(2): 165s Untaring eight src.tgz in parallel: UFS: 791s UFS+SU: 650s gjournal(1): 333s gjournal(2): 309s Reading. grep -r on two src/ directories in parallel: UFS: 84s UFS+SU: 138s gjournal(1): 102s gjournal(2): 89s As you can see, even on one disk, untaring eight src.tgz is two times faster than UFS+SU. I've no idea why gjournal is faster in reading. There are a bunch of sysctls to tune gjournal (kern.geom.journal tree). When only one provider is given for both data and journal, the journal part is placed at the end of the provider, so one can use file system without journaling. If you use such configuration (one disk), it is better for performance to place journal before data, so you may want to create two partitions (eg. 2GB for ad0a and the rest for ad0d) and create gjournal this way: # gjournal label ad0d ad0a Enjoy! The work was sponsored by home.pl (http://home.pl). The work was made by Wheel LTD (http://www.wheel.pl). The work was tested in the netperf cluster. I want to thank Alexander Kabaev (kan@) for the help with VFS and Mike Tancsa for test hardware. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --rJwd6BRFiFCcLxzm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFElqJlForvXbEpPzQRAtSFAJ9+Q+NjIqImiypsAFNG6bT6+dGu3wCgkOD0 q1HU94X2QsliV8rtIQRNt2s= =HWoE -----END PGP SIGNATURE----- --rJwd6BRFiFCcLxzm-- From owner-freebsd-geom@FreeBSD.ORG Mon Jun 19 18:32:28 2006 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E41616A47B for ; Mon, 19 Jun 2006 18:32:28 +0000 (UTC) (envelope-from nike_d@cytexbg.com) Received: from mail.interbgc.com (mx04.interbgc.com [217.9.224.231]) by mx1.FreeBSD.org (Postfix) with SMTP id BF81543D49 for ; Mon, 19 Jun 2006 18:32:25 +0000 (GMT) (envelope-from nike_d@cytexbg.com) Received: (qmail 76785 invoked from network); 19 Jun 2006 18:32:24 -0000 Received: from nike_d@cytexbg.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.2.40/v4374. spamassassin: 2.63. Clear:SA:0(0.1/8.0):. Processed in 3.785294 secs); 19 Jun 2006 18:32:24 -0000 X-Spam-Status: No, hits=0.1 required=8.0 Received: from niked.ddns.cablebg.net (HELO tormentor.totalterror.net) (85.130.14.211) by mx04.interbgc.com with SMTP; 19 Jun 2006 18:32:19 -0000 Received: (qmail 6230 invoked from network); 19 Jun 2006 18:32:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (10.0.0.3) by tormentor.totalterror.net with SMTP; 19 Jun 2006 18:32:19 -0000 Message-ID: <4496EDB2.5040706@cytexbg.com> Date: Mon, 19 Jun 2006 21:32:18 +0300 From: Niki Denev User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20060619131101.GD1130@garage.freebsd.pl> In-Reply-To: <20060619131101.GD1130@garage.freebsd.pl> X-Enigmail-Version: 0.94.0.0 OpenPGP: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 18:32:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pawel Jakub Dawidek wrote: > Hello. > > For the last few months I have been working on gjournal project. > To stop confusion right here, I want to note, that this project is not > related to gjournal project on which Ivan Voras was working on the > last SoC (2005). > > The lack of journaled file system in FreeBSD was a tendon of achilles > for many years. We do have many file systems, but none with journaling: > - ext2fs (journaling is in ext3fs), > - XFS (read-only), > - ReiserFS (read-only), > - HFS+ (read-write, but without journaling), > - NTFS (read-only). > > GJournal was designed to journal GEOM providers, so it actually works > below file system layer, but it has hooks which allow to work with > file systems. In other words, gjournal is not file system-depended, > it can work probably with any file system with minimum knowledge > about it. I implemented only UFS support. > > The patches are here: > > http://people.freebsd.org/~pjd/patches/gjournal.patch (for HEAD) > http://people.freebsd.org/~pjd/patches/gjournal6.patch (for RELENG_6) > > To patch your sources you need to: > > # cd /usr/src > # mkdir sbin/geom/class/journal sys/geom/journal sys/modules/geom/geom_journal > # patch < /path/to/gjournal.patch > > Add 'options UFS_GJOURNAL' to your kernel configuration file and > recompile kernel and world. > > How it works (in short). You may define one or two providers which > gjournal will use. If one provider is given, it will be used for both - > data and journal. If two providers are given, one will be used for data > and one for journal. > Every few seconds (you may define how many) journal is terminated and > marked as consistent and gjournal starts to copy data from it to the > data provider. In the same time new data are stored in new journal. > Let's call the moment in which journal is terminated as "journal switch". > Journal switch looks as follows: > 1. Start journal switch if we have timeout or if we run out of cache. > Don't perform journal switch if there were no write requests. > 2. If we have file system, synchronize it. > 3. Mark file system as clean. > 4. Block all write requests to the file system. > 5. Terminate the journal. > 6. Eventually wait if copying of the previous journal is not yet > finished. > 7. Send BIO_FLUSH request (if the given provider supports it). > 8. Mark new journal position on the journal provider. > 9. Unblock write requests. > 10. Start copying data from the terminated journal to the data provider. > > There were few things I needed to implement outside gjournal to make it > work reliable: > > - The BIO_FLUSH request. Currently we have three I/O requests: BIO_READ, > BIO_WRITE and BIO_DELETE. I added BIO_FLUSH, which means "flush your > write cache". The request is send always with the biggest bio_offset set > (mediasize of the destination provider), so it will work properly with > bioq_disksort(). The caller need to stop further I/O requests before > BIO_FLUSH return, so we don't have starvation effect. > The hard part is that is has to be implemented in every disk driver, > because flushing the cache is driver-depended operation. I implemented > it for ata(4) disks and amr(4). The good news is that it's easy. > GJournal can also work with providers that don't support BIO_FLUSH and > in my power-failure tests it worked well (no problems), but it depend > on fact, that gjournal cache is bigger than the controller cache, so it > is hard to call it reliable. > You can read in documentation to many journaled file systems, that you > should turn off write cache if you want to use it. This is not the case > for gjournal (especially when your disk driver does support BIO_FLUSH). > > The 'gjournal' mount option. To implement gjournal support in UFS I > needed to change the way of how deleted, but still open objects are > handled. Currently when file or directory is open and we deleted last > name which reference it, it will still be usable by those who keep it > open. When the last consumer closes it, the inode and blocks are freed. > On journal switch I cannot leave such objects, because after a crash > fsck(8) is not used to check the file system, so inode and blocks will > never be freed. When file system is mounted with 'gjournal' mount > option, such objects are not removed when they are open. When last > name is deleted, the file/directory is moved to the .deleted/ > directory and removed from there on last close. > This way, I can just clean the .deleted/ directory after a crash at > mount time. > > Quick start: > > # gjournal label /dev/ad0 > # gjournal load > # newfs /dev/ad0.journal > # mount -o async,gjournal /dev/ad0.journal /mnt > (yes, with gjournal 'async' is safe) > > Now, after a power failure or system crash no fsck is needed (yay!). > > There are two hacks in the current implementation, which I'd like to > reimplement. First is how 'gjournal' mount option is implemented. > There is a garbage collector thread which is responsible for deleting > objects from .deleted/ directory and it is using full paths. Because > of this when your mount point is /foo/bar/baz and you rename 'bar' to > something else, it will not work. This is not what is often done, but > definitely should be fixed and I'm working on it. The second hack is > related to communication between gjournal and file system. GJournal > decides when to make the switch and has to find file system which is > mounted on it. Looking for this file system is not nice and should be > reimplemented. > > There are some additional goods which came with gjournal. For example > if gjournal is configured over gmirror or graid3, even on power failure > or system crash, there is no need to synchronize mirror/raid3 device, > because data will be consistent. > > I spend a lot of time working on gjournal optimization. Because I've > few seconds before the data hit the data provider I can perform things > like combining smaller write requests into larger once, ignoring data > written twice to the same place, etc. > Because of this, operations on small files are quite fast. On the other > hand, operations on large files are slower, because I need to write the > data twice and there is no place for optimization. Here are some numbers. > gjournal(1) - the data provider and the journal provider on the same disk > gjournal(2) - the data provider and the journal provider on separate > disks > > Copying one large file: > UFS: 8s > UFS+SU: 8s > gjournal(1): 16s > gjournal(2): 14s > > Copying eight large files in parallel: > UFS: 120s > UFS+SU: 120s > gjournal(1): 184s > gjournal(2): 165s > > Untaring eight src.tgz in parallel: > UFS: 791s > UFS+SU: 650s > gjournal(1): 333s > gjournal(2): 309s > > Reading. grep -r on two src/ directories in parallel: > UFS: 84s > UFS+SU: 138s > gjournal(1): 102s > gjournal(2): 89s > > As you can see, even on one disk, untaring eight src.tgz is two times > faster than UFS+SU. I've no idea why gjournal is faster in reading. > > There are a bunch of sysctls to tune gjournal (kern.geom.journal tree). > > When only one provider is given for both data and journal, the journal > part is placed at the end of the provider, so one can use file system > without journaling. If you use such configuration (one disk), it is > better for performance to place journal before data, so you may want to > create two partitions (eg. 2GB for ad0a and the rest for ad0d) and > create gjournal this way: > > # gjournal label ad0d ad0a > > Enjoy! > > The work was sponsored by home.pl (http://home.pl). > > The work was made by Wheel LTD (http://www.wheel.pl). > The work was tested in the netperf cluster. > > I want to thank Alexander Kabaev (kan@) for the help with VFS and > Mike Tancsa for test hardware. > Wow, this looks pretty cool! I wonder if it's possible to use gjournal on existing file system with the journal on a vnode/(swap?) backed md(4) device? (i want to test on a existing installation without free unpartitioned space) And if it is possible, how can i do this for the root filesystem? i'll need the md(4) device before mounting of the root fs which seems hard/impossible? What's going to happen if my root mount is gjournal labeled and has gjournal option in fstab but at boot time the journal GEOM provider does not exist? Thanks for the great work! When finished, this will certainly make FreeBSD much more competitive :) - --niki -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFElu2yHNAJ/fLbfrkRAsVBAKChRFMVLuivXYR1NM3b0u9iVe72uwCfdzH0 DvdjEZwOKjuZu4UV+toVpwo= =+qj/ -----END PGP SIGNATURE----- From owner-freebsd-geom@FreeBSD.ORG Mon Jun 19 18:58:01 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FD7F16A5B0; Mon, 19 Jun 2006 18:58:01 +0000 (UTC) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF73243D46; Mon, 19 Jun 2006 18:58:00 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k5JIw0pg023502; Mon, 19 Jun 2006 11:58:00 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k5JIw0Hd023501; Mon, 19 Jun 2006 11:58:00 -0700 Date: Mon, 19 Jun 2006 11:58:00 -0700 From: Brooks Davis To: Pawel Jakub Dawidek Message-ID: <20060619185800.GA22546@odin.ac.hmc.edu> References: <20060619131101.GD1130@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <20060619131101.GD1130@garage.freebsd.pl> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 18:58:01 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 19, 2006 at 03:11:01PM +0200, Pawel Jakub Dawidek wrote: >=20 > How it works (in short). You may define one or two providers which > gjournal will use. If one provider is given, it will be used for both - > data and journal. If two providers are given, one will be used for data > and one for journal. > Every few seconds (you may define how many) journal is terminated and > marked as consistent and gjournal starts to copy data from it to the > data provider. In the same time new data are stored in new journal. > Let's call the moment in which journal is terminated as "journal switch". Cool solution! I think I'll give this a try on my redundent mirror server at work. I'd be curious to see how gjournal performs with the journal on a battery backed ram disk like the gigabyte i-RAM: http://www.giga-byte.com/Products/Storage/Products_Overview.aspx?ProductID= =3D2180&ProductName=3DGC-RAMDISK It seems like that could reduce or eliminate many of the performance issues in practice. -- Brooks --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFElvO3XY6L6fI4GtQRAleqAKDQVc6j/LfjPPt4vcvqzz7osVfQbACdFErw Jo9Xaa7JuVQmsQw2u4ohwSQ= =q1/p -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- From owner-freebsd-geom@FreeBSD.ORG Tue Jun 20 06:35:27 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4462116A47A; Tue, 20 Jun 2006 06:35:27 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from sccrmhc15.comcast.net (sccrmhc15.comcast.net [63.240.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFA8E43D46; Tue, 20 Jun 2006 06:35:25 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-71-233-168-2.hsd1.ma.comcast.net ([71.233.168.2]) by comcast.net (sccrmhc15) with ESMTP id <200606200635240150091q9ie>; Tue, 20 Jun 2006 06:35:24 +0000 Received: from c-71-233-168-2.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-71-233-168-2.hsd1.ma.comcast.net (8.13.6/8.13.1) with ESMTP id k5K6ZP7e011559; Tue, 20 Jun 2006 02:35:25 -0400 (EDT) (envelope-from rodrigc@c-71-233-168-2.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-71-233-168-2.hsd1.ma.comcast.net (8.13.6/8.13.1/Submit) id k5K6ZPF0011558; Tue, 20 Jun 2006 02:35:25 -0400 (EDT) (envelope-from rodrigc) Date: Tue, 20 Jun 2006 02:35:25 -0400 From: Craig Rodrigues To: Pawel Jakub Dawidek Message-ID: <20060620063525.GA11441@crodrigues.org> References: <20060619131101.GD1130@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060619131101.GD1130@garage.freebsd.pl> User-Agent: Mutt/1.4.2.1i Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 06:35:27 -0000 On Mon, Jun 19, 2006 at 03:11:01PM +0200, Pawel Jakub Dawidek wrote: > http://people.freebsd.org/~pjd/patches/gjournal.patch (for HEAD) > http://people.freebsd.org/~pjd/patches/gjournal6.patch (for RELENG_6) I would recommend that you not introduce a new MNT_GJOURNAL flag to , and that instead you just pass -o gjournal directly down into nmount(). In kernel code, you can use vfs_flagopt()/vfs_getopt() to determine if you have this mount option or not. The mount(8) userland utility would not need any modifications, since it just passes -o options down to nmount(). gjournal looks very interesting! -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-geom@FreeBSD.ORG Tue Jun 20 08:39:17 2006 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 379CC16A492; Tue, 20 Jun 2006 08:39:17 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89D5543D5C; Tue, 20 Jun 2006 08:39:15 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id C469051814; Tue, 20 Jun 2006 10:39:13 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id F252A51307; Tue, 20 Jun 2006 10:39:06 +0200 (CEST) Date: Tue, 20 Jun 2006 10:36:33 +0200 From: Pawel Jakub Dawidek To: Niki Denev Message-ID: <20060620083632.GB6235@garage.freebsd.pl> References: <20060619131101.GD1130@garage.freebsd.pl> <4496EDB2.5040706@cytexbg.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+g7M9IMkV8truYOl" Content-Disposition: inline In-Reply-To: <4496EDB2.5040706@cytexbg.com> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 08:39:17 -0000 --+g7M9IMkV8truYOl Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 19, 2006 at 09:32:18PM +0300, Niki Denev wrote: +> I wonder if it's possible to use gjournal on +> existing file system with the journal on a vnode/(swap?) backed md(4) de= vice? +> (i want to test on a existing installation without free unpartitioned sp= ace) Depend on what do you want to test. If you just want to look around, swap-backed md(4) device for journal should be fine. If you want to perform some crash tests, you may want to turn off the swap and use its provider for journal directly (without md(4)), so it will be available after a reboot. You can configure gjournal on an existing file system, but, as always, the last sector will be used for metadata. For example, you have your file system on ad0s1d and swap on ad0s1b. You can try to configure gjournal this way: # swapoff /dev/ad0s1b # umount /dev/ad0s1d # gjournal label ad0s1d ad0s1b Your swap should have at least 2GB if your file system will be heavy loaded. Be warned that this will overwrite the last sector on ad0s1d, which should be safe, but you never know. +> And if it is possible, how can i do this for the root filesystem? i'll n= eed the md(4) +> device before mounting of the root fs which seems hard/impossible? +> What's going to happen if my root mount is gjournal labeled and has gjou= rnal option in +> fstab but at boot time the journal GEOM provider does not exist? I forgot to mention this in my initial mail. This is not yet possible to use gjournal for the root file system. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --+g7M9IMkV8truYOl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEl7OQForvXbEpPzQRAjDnAJ4zBXaKq7QO6h5tshc4Uc+Z+GeLXwCgjzMw 1lTAcJbB+zfgqC8VzF4DwOg= =Qkqy -----END PGP SIGNATURE----- --+g7M9IMkV8truYOl-- From owner-freebsd-geom@FreeBSD.ORG Tue Jun 20 08:43:51 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C73D16A47A; Tue, 20 Jun 2006 08:43:51 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id B368243D53; Tue, 20 Jun 2006 08:43:50 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 52A9251388; Tue, 20 Jun 2006 10:43:49 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 3C9E951307; Tue, 20 Jun 2006 10:43:44 +0200 (CEST) Date: Tue, 20 Jun 2006 10:41:10 +0200 From: Pawel Jakub Dawidek To: Brooks Davis Message-ID: <20060620084110.GC6235@garage.freebsd.pl> References: <20060619131101.GD1130@garage.freebsd.pl> <20060619185800.GA22546@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2/5bycvrmDh4d1IB" Content-Disposition: inline In-Reply-To: <20060619185800.GA22546@odin.ac.hmc.edu> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 08:43:51 -0000 --2/5bycvrmDh4d1IB Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 19, 2006 at 11:58:00AM -0700, Brooks Davis wrote: +> On Mon, Jun 19, 2006 at 03:11:01PM +0200, Pawel Jakub Dawidek wrote: +> >=20 +> > How it works (in short). You may define one or two providers which +> > gjournal will use. If one provider is given, it will be used for both - +> > data and journal. If two providers are given, one will be used for data +> > and one for journal. +> > Every few seconds (you may define how many) journal is terminated and +> > marked as consistent and gjournal starts to copy data from it to the +> > data provider. In the same time new data are stored in new journal. +> > Let's call the moment in which journal is terminated as "journal switc= h". +>=20 +> Cool solution! I think I'll give this a try on my redundent mirror +> server at work. I'd be curious to see how gjournal performs with the +> journal on a battery backed ram disk like the gigabyte i-RAM: +>=20 +> http://www.giga-byte.com/Products/Storage/Products_Overview.aspx?Product= ID=3D2180&ProductName=3DGC-RAMDISK I am curious too:) But as I said, there is still a lot of room for performance improvements. The bottleneck currently is file system synchronization, I think. I hope our VFS gurus will look into VFS_SYNC() optimizations. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --2/5bycvrmDh4d1IB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEl7SlForvXbEpPzQRAqB1AJ45J7spbBRtAcRzlA/ZhwzgNLz6PgCgmwRx y9ph5z7m5towyeZISTAnQik= =PdyB -----END PGP SIGNATURE----- --2/5bycvrmDh4d1IB-- From owner-freebsd-geom@FreeBSD.ORG Tue Jun 20 09:05:40 2006 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D39C116A49A for ; Tue, 20 Jun 2006 09:05:40 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 33A3043D58 for ; Tue, 20 Jun 2006 09:05:38 +0000 (GMT) (envelope-from ale@FreeBSD.org) Received: (qmail 56922 invoked from network); 20 Jun 2006 09:05:33 -0000 Received: from unknown (HELO ?192.168.2.5?) (192.168.2.5) by andxor.it with SMTP; 20 Jun 2006 09:05:33 -0000 Message-ID: <4497BA5B.8050805@FreeBSD.org> Date: Tue, 20 Jun 2006 11:05:31 +0200 From: Alex Dupre User-Agent: Thunderbird 1.5.0.4 (X11/20060606) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20060619131101.GD1130@garage.freebsd.pl> <4496EDB2.5040706@cytexbg.com> <20060620083632.GB6235@garage.freebsd.pl> In-Reply-To: <20060620083632.GB6235@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 09:05:40 -0000 Pawel Jakub Dawidek wrote: > I forgot to mention this in my initial mail. This is not yet possible to > use gjournal for the root file system. Even if the machine boots from another device and the gjournal kernel module is loaded before mounting the root filesystem? -- Alex Dupre From owner-freebsd-geom@FreeBSD.ORG Tue Jun 20 09:15:11 2006 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA94E16A47A; Tue, 20 Jun 2006 09:15:11 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A48343D64; Tue, 20 Jun 2006 09:14:57 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id AEEDF51388; Tue, 20 Jun 2006 11:14:56 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 586AA50E81; Tue, 20 Jun 2006 11:14:51 +0200 (CEST) Date: Tue, 20 Jun 2006 11:12:17 +0200 From: Pawel Jakub Dawidek To: Alex Dupre Message-ID: <20060620091216.GD6235@garage.freebsd.pl> References: <20060619131101.GD1130@garage.freebsd.pl> <4496EDB2.5040706@cytexbg.com> <20060620083632.GB6235@garage.freebsd.pl> <4497BA5B.8050805@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WChQLJJJfbwij+9x" Content-Disposition: inline In-Reply-To: <4497BA5B.8050805@FreeBSD.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 09:15:12 -0000 --WChQLJJJfbwij+9x Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 20, 2006 at 11:05:31AM +0200, Alex Dupre wrote: +> Pawel Jakub Dawidek wrote: +> >I forgot to mention this in my initial mail. This is not yet possible to +> >use gjournal for the root file system. +>=20 +> Even if the machine boots from another device and the gjournal kernel mo= dule is loaded before mounting the root filesystem? Yes, even then, because mount(8) utility is responsible for cleaning =2Edeleted/ directory. This can be done when the file system is remounted read-write, but I just didn't have time to work on this yet. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --WChQLJJJfbwij+9x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEl7vwForvXbEpPzQRAnUtAKDCxpIzoNix1nU0n+xLHGrrsBpMIACgnh/I oRKJQNNV+TRZ0RmJoR2ojP0= =4o5n -----END PGP SIGNATURE----- --WChQLJJJfbwij+9x-- From owner-freebsd-geom@FreeBSD.ORG Tue Jun 20 10:29:13 2006 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6372516A479; Tue, 20 Jun 2006 10:29:13 +0000 (UTC) (envelope-from regnauld@x0.dk) Received: from x0.dk (x0.dk [62.242.165.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE76843D46; Tue, 20 Jun 2006 10:29:12 +0000 (GMT) (envelope-from regnauld@x0.dk) Received: from localhost (unknown [127.0.0.1]) by tetard.starbsd.org (Postfix) with ESMTP id 36F5B3565C; Tue, 20 Jun 2006 12:29:11 +0200 (CEST) Received: from tetard.starbsd.org ([127.0.0.1]) by localhost (tetard.starbsd.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27908-05; Tue, 20 Jun 2006 12:29:10 +0200 (CEST) Received: by tetard.starbsd.org (Postfix, from userid 1001) id 4556E35667; Tue, 20 Jun 2006 12:29:10 +0200 (CEST) Date: Tue, 20 Jun 2006 12:29:10 +0200 From: Phil Regnauld To: Pawel Jakub Dawidek Message-ID: <20060620102910.GG27055@tetard.starbsd.org> References: <20060619131101.GD1130@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060619131101.GD1130@garage.freebsd.pl> X-Operating-System: FreeBSD 6.1-STABLE i386 Organization: *BSD User-Agent: Mutt/1.5.11 X-Virus-Scanned: amavisd-new at starbsd.org Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 10:29:13 -0000 On Mon, Jun 19, 2006 at 03:11:01PM +0200, Pawel Jakub Dawidek wrote: > > Copying one large file: > UFS: 8s > UFS+SU: 8s > gjournal(1): 16s > gjournal(2): 14s This is very very interesting work! I am definitely going to test this. I know this is too early to ask considering the optimizations that can be done, but do you have any idea how this would perform compared to ReiserFS on similar operations as the ones you benchmarked ? PS: is it me or is the patch missing a gjournal command, as invoked in your examples ? Cheers, Phil From owner-freebsd-geom@FreeBSD.ORG Tue Jun 20 12:10:37 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8BC216A479 for ; Tue, 20 Jun 2006 12:10:37 +0000 (UTC) (envelope-from ivan@ins.dn.ua) Received: from grand.ins.dn.ua (relay.ins.dn.ua [195.184.203.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 265B343D5C for ; Tue, 20 Jun 2006 12:10:31 +0000 (GMT) (envelope-from ivan@ins.dn.ua) Received: from ivan (nat.ins.dn.ua [195.184.203.4]) by grand.ins.dn.ua (8.13.7/8.13.6) with ESMTP id k5KCAR8V010619 for ; Tue, 20 Jun 2006 15:10:27 +0300 (EEST) Date: Tue, 20 Jun 2006 15:11:45 +0300 (EEST) From: Ivan Khilko To: freebsd-geom@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on grand.ins.dn.ua X-Virus-Status: Clean Subject: Problem with dumpon... X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 12:10:37 -0000 Hallo. I have server (Pentium III) with FreeBSD-5.5 on it. On this server I configure gmirror RAID 1 on IDE HDD: kernel: ad0: 76319MB [155061/16/63] at ata0-master UDMA66 kernel: ad2: 76319MB [155061/16/63] at ata1-master UDMA66 All work correct, but sometimes server rebooting. Background file system checks off on this server. I can't find cause of this rebooting. Server work on unattended room. When I come to this room I see only: "Automatic file system check failed...". When I configured crashdump, kernel say: dumpon: ioctl(DIOCSKERNELDUMP): Operation not supported (swap device on /dev/mirror/gm0s1b) Logfile (syslogd: *.* /var/log/messages) not have any error messages. How I may determinate cause of problem? Ivan. e-mail:ivan@ins.dn.ua From owner-freebsd-geom@FreeBSD.ORG Tue Jun 20 12:27:33 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C979E16A47A for ; Tue, 20 Jun 2006 12:27:33 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2428B43D45 for ; Tue, 20 Jun 2006 12:27:32 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id D259451388; Tue, 20 Jun 2006 14:27:30 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 25E6D5131F; Tue, 20 Jun 2006 14:27:26 +0200 (CEST) Date: Tue, 20 Jun 2006 14:24:50 +0200 From: Pawel Jakub Dawidek To: Ivan Khilko Message-ID: <20060620122450.GF6235@garage.freebsd.pl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IuhbYIxU28t+Kd57" Content-Disposition: inline In-Reply-To: X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-geom@freebsd.org Subject: Re: Problem with dumpon... X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 12:27:33 -0000 --IuhbYIxU28t+Kd57 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 20, 2006 at 03:11:45PM +0300, Ivan Khilko wrote: +> Hallo. +>=20 +> I have server (Pentium III) with FreeBSD-5.5 on it. On this server I +> configure gmirror RAID 1 on IDE HDD: +>=20 +> kernel: ad0: 76319MB [155061/16/63] at ata0-master UD= MA66 +> kernel: ad2: 76319MB [155061/16/63] at ata1-master UD= MA66 +>=20 +> All work correct, but sometimes server rebooting. Background file system= checks +> off on this server. I can't find cause of this rebooting. Server work on +> unattended room. When I come to this room I see only: "Automatic file sy= stem +> check failed...". When I configured crashdump, kernel say: +> dumpon: ioctl(DIOCSKERNELDUMP): Operation not supported +> (swap device on /dev/mirror/gm0s1b) +> Logfile (syslogd: *.* /var/log/messages) not have any error messages. Doing crashdumps on gmirror is supported from FreeBSD 6.1, AFAIR. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --IuhbYIxU28t+Kd57 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEl+kSForvXbEpPzQRAuNnAKCZd3dhVlm4KGg4KukUoqMrRKXXMwCbBLrQ ptvmlvePG1U7X3zdd8vExaU= =849g -----END PGP SIGNATURE----- --IuhbYIxU28t+Kd57-- From owner-freebsd-geom@FreeBSD.ORG Tue Jun 20 19:20:58 2006 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5534C16A479 for ; Tue, 20 Jun 2006 19:20:58 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from smtp101.rog.mail.re2.yahoo.com (smtp101.rog.mail.re2.yahoo.com [206.190.36.79]) by mx1.FreeBSD.org (Postfix) with SMTP id EC6F043D46 for ; Tue, 20 Jun 2006 19:20:39 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 30511 invoked from network); 20 Jun 2006 19:20:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=hj305CjEvHVsU5NZ25RJw755sYFbJTSuAgNveYBJs9ZAEIqUpdhNtIChn/GxZu6OepJraxKcBefQX3Hvbgm5vNNg7YZJOoUCT9GcdOQhkvQXha55TXbnleYcflpfXN1L6a45gG6KheCecXbkOx+wnZjwcOW7u7BsjeaLIsIdbZo= ; Received: from unknown (HELO ?70.31.50.218?) (mikej@rogers.com@70.31.50.218 with plain) by smtp101.rog.mail.re2.yahoo.com with SMTP; 20 Jun 2006 19:20:38 -0000 Message-ID: <44984A91.8040805@rogers.com> Date: Tue, 20 Jun 2006 15:20:49 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20060619131101.GD1130@garage.freebsd.pl> In-Reply-To: <20060619131101.GD1130@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 19:20:58 -0000 Pawel Jakub Dawidek wrote: > Copying one large file: > UFS: 8s > UFS+SU: 8s > gjournal(1): 16s > gjournal(2): 14s > > Copying eight large files in parallel: > UFS: 120s > UFS+SU: 120s > gjournal(1): 184s > gjournal(2): 165s > > Untaring eight src.tgz in parallel: > UFS: 791s > UFS+SU: 650s > gjournal(1): 333s > gjournal(2): 309s > > Reading. grep -r on two src/ directories in parallel: > UFS: 84s > UFS+SU: 138s > gjournal(1): 102s > gjournal(2): 89s > Not to sound ungrateful for the work, which i am, this is great! But the performance impact seems rather large to me. Does the presence of journaling mean that we could perhaps mount the filesystems async? Does it eliminate the need for softupdates? From owner-freebsd-geom@FreeBSD.ORG Tue Jun 20 19:39:14 2006 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9D9F16A474; Tue, 20 Jun 2006 19:39:13 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D8F743D46; Tue, 20 Jun 2006 19:39:12 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 9351D51388; Tue, 20 Jun 2006 21:39:11 +0200 (CEST) Received: from localhost (dlc33.neoplus.adsl.tpnet.pl [83.24.32.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 24C8451307; Tue, 20 Jun 2006 21:39:06 +0200 (CEST) Date: Tue, 20 Jun 2006 21:36:30 +0200 From: Pawel Jakub Dawidek To: Mike Jakubik Message-ID: <20060620193630.GA8007@garage.freebsd.pl> References: <20060619131101.GD1130@garage.freebsd.pl> <44984A91.8040805@rogers.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: <44984A91.8040805@rogers.com> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL,RCVD_IN_SORBS_WEB autolearn=no version=3.0.4 Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 19:39:14 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 20, 2006 at 03:20:49PM -0400, Mike Jakubik wrote: +> Pawel Jakub Dawidek wrote: +> >Copying one large file: +> >UFS: 8s +> >UFS+SU: 8s +> >gjournal(1): 16s +> >gjournal(2): 14s +> > +> >Copying eight large files in parallel: +> >UFS: 120s +> >UFS+SU: 120s +> >gjournal(1): 184s +> >gjournal(2): 165s +> > +> >Untaring eight src.tgz in parallel: +> >UFS: 791s +> >UFS+SU: 650s +> >gjournal(1): 333s +> >gjournal(2): 309s +> > +> >Reading. grep -r on two src/ directories in parallel: +> >UFS: 84s +> >UFS+SU: 138s +> >gjournal(1): 102s +> >gjournal(2): 89s +> > =20 +>=20 +> Not to sound ungrateful for the work, which i am, this is great! But the= performance impact seems rather large to me. Does the presence of journali= ng mean that we could=20 +> perhaps mount the filesystems async? Does it eliminate the need for soft= updates? The performance impact is big for large files, because in theory we have to write the data twice. Yes, it eliminates need for SU, but there are reasons, that you still want to use SU, eg. for snapshots. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --0F1p//8PRICkK4MW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEmE4+ForvXbEpPzQRAjSQAJ0e6afsrswjGwoJhPut8ECFSwWpwwCgp+gl dEU8PUrMPRznRZEOSYn1v5g= =NVNr -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW-- From owner-freebsd-geom@FreeBSD.ORG Tue Jun 20 20:00:01 2006 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 595D416A47B; Tue, 20 Jun 2006 20:00:01 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id D42FA43D6E; Tue, 20 Jun 2006 19:59:54 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 83BD3EB2D6D; Wed, 21 Jun 2006 03:59:53 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id TI1VS5fYHhkY; Wed, 21 Jun 2006 03:59:48 +0800 (CST) Received: from [192.168.1.9] (unknown [221.217.210.14]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 8125EEB2D68; Wed, 21 Jun 2006 03:59:47 +0800 (CST) From: Xin LI To: Pawel Jakub Dawidek In-Reply-To: <20060620193630.GA8007@garage.freebsd.pl> References: <20060619131101.GD1130@garage.freebsd.pl> <44984A91.8040805@rogers.com> <20060620193630.GA8007@garage.freebsd.pl> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-p+Mvcxbfi7F/bq0HN1Lm" Organization: The FreeBSD Project Date: Wed, 21 Jun 2006 03:59:46 +0800 Message-Id: <1150833586.24301.1.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port Cc: freebsd-fs@FreeBSD.org, Mike Jakubik , freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 20:00:01 -0000 --=-p+Mvcxbfi7F/bq0HN1Lm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E5=9C=A8 2006-06-20=E4=BA=8C=E7=9A=84 21:36 +0200=EF=BC=8CPawel Jakub Dawi= dek=E5=86=99=E9=81=93=EF=BC=9A > The performance impact is big for large files, because in theory we have > to write the data twice. > Yes, it eliminates need for SU, but there are reasons, that you still > want to use SU, eg. for snapshots. Em... IIRC SU and snapshots are independent, no? Cheers, --=20 Xin LI http://www.delphij.net/ --=-p+Mvcxbfi7F/bq0HN1Lm Content-Type: application/pgp-signature; name=signature.asc Content-Description: =?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?= =?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8=E5=88=86?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQBEmFOyhcUczkLqiksRAvvIAKDL6Of+43Ocr7FgJWkvEyxAfDLl+QCgtAkb wQ02zSKSY4O94UM7Uu6F15M= =4olk -----END PGP SIGNATURE----- --=-p+Mvcxbfi7F/bq0HN1Lm-- From owner-freebsd-geom@FreeBSD.ORG Tue Jun 20 20:07:26 2006 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D12016A47B for ; Tue, 20 Jun 2006 20:07:26 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from smtp104.rog.mail.re2.yahoo.com (smtp104.rog.mail.re2.yahoo.com [206.190.36.82]) by mx1.FreeBSD.org (Postfix) with SMTP id 4A8EF43D45 for ; Tue, 20 Jun 2006 20:07:24 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 66799 invoked from network); 20 Jun 2006 20:07:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=2GQun7jY0/SnK0/NVjCsnWRW1e7wa5mJhxbiTt6O12797Lr1G00QUpk88YcZFVrURHTxfNxjuSqnFPCk6dqZACM5ko3qMrO88CEGeoYEYS/xINcBON96ZMCS7ojhBF/uJ8gZhlEsxeO1NEurszUYn39qaXGIh9IBOPt44nZFmhE= ; Received: from unknown (HELO ?70.31.50.218?) (mikej@rogers.com@70.31.50.218 with plain) by smtp104.rog.mail.re2.yahoo.com with SMTP; 20 Jun 2006 20:07:23 -0000 Message-ID: <44985586.2090504@rogers.com> Date: Tue, 20 Jun 2006 16:07:34 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Xin LI References: <20060619131101.GD1130@garage.freebsd.pl> <44984A91.8040805@rogers.com> <20060620193630.GA8007@garage.freebsd.pl> <1150833586.24301.1.camel@spirit> In-Reply-To: <1150833586.24301.1.camel@spirit> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Pawel Jakub Dawidek , freebsd-geom@FreeBSD.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 20:07:26 -0000 Xin LI wrote: > 在 2006-06-20二的 21:36 +0200，Pawel Jakub Dawidek写道： > >> The performance impact is big for large files, because in theory we have >> to write the data twice. >> Yes, it eliminates need for SU, but there are reasons, that you still >> want to use SU, eg. for snapshots. >> > > Em... IIRC SU and snapshots are independent, no? > > Cheers, > What about mounting the filesystem async though? It was my understanding that the Linux filesystems were much faster in benchmarks because they were mounted async by default, however the presence of journaling allowed this safely. Is this the case here too? From owner-freebsd-geom@FreeBSD.ORG Tue Jun 20 20:29:49 2006 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 781AC16A474; Tue, 20 Jun 2006 20:29:49 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33FC543D46; Tue, 20 Jun 2006 20:29:49 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 933F2294C1; Tue, 20 Jun 2006 13:29:48 -0700 (PDT) To: Pawel Jakub Dawidek In-reply-to: Your message of "Mon, 19 Jun 2006 15:11:01 +0200." <20060619131101.GD1130@garage.freebsd.pl> Date: Tue, 20 Jun 2006 13:29:48 -0700 From: Bakul Shah Message-Id: <20060620202948.933F2294C1@mail.bitblocks.com> Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 20:29:49 -0000 This is great! We have sorely needed this for quite a while what with terabyte size filesystems getting into common use. > How it works (in short). You may define one or two providers which > gjournal will use. If one provider is given, it will be used for both - > data and journal. If two providers are given, one will be used for data > and one for journal. > Every few seconds (you may define how many) journal is terminated and > marked as consistent and gjournal starts to copy data from it to the > data provider. In the same time new data are stored in new journal. Some random comments: Would it make sense to treat the journal as a circular buffer? Then commit to the underlying provider starts when the buffer has $hiwater blocks or the upper layer wants to sync. The commit stops when the buffer has $lowater blocks or in case of sync the buffer is empty. This will allow parallel writes to the provider and the journal, thereby reducing latency. I don't understand why you need FS synchronization. Once the journal is written, the data is safe. A "redo" may be needed after a crash to sync the filesystem but that is about it. Redo should be idempotent. Each journal write block may need some flags. For instance mark a block as a "sync point" -- when this block is on the disk, the FS will be in a consistent state. In case of redo after crash you have to throw away all the journal blocks after the last sync point. It seems to me if you write a serial number with each data block, in the worst case redo has to do a binary search to find the first block to write but normal writes to journal and reads from journal (for commiting to the provider) can be completely sequential. Since redo will be much much faster than fsck you can afford to slow it down a bit if the normal case can be speeded up. Presumably you disallow opening any file in /.deleted. Can you gjournal the journal disk? Recursion is good:-) -- bakul From owner-freebsd-geom@FreeBSD.ORG Tue Jun 20 20:33:11 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35D1316A492; Tue, 20 Jun 2006 20:33:11 +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 6187C43D72; Tue, 20 Jun 2006 20:33:03 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([69.15.205.254]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k5KKWZMA004370; Tue, 20 Jun 2006 14:32:40 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <44985B5C.7090201@samsco.org> Date: Tue, 20 Jun 2006 14:32:28 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Jakubik References: <20060619131101.GD1130@garage.freebsd.pl> <44984A91.8040805@rogers.com> <20060620193630.GA8007@garage.freebsd.pl> <1150833586.24301.1.camel@spirit> <44985586.2090504@rogers.com> In-Reply-To: <44985586.2090504@rogers.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.0 required=3.8 tests=none 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, Pawel Jakub Dawidek , freebsd-current@freebsd.org, Xin LI , freebsd-geom@freebsd.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 20:33:11 -0000 Mike Jakubik wrote: > Xin LI wrote: > >> 在 2006-06-20二的 21:36 +0200，Pawel Jakub Dawidek写道： >> >> >>> The performance impact is big for large files, because in theory we have >>> to write the data twice. >>> Yes, it eliminates need for SU, but there are reasons, that you still >>> want to use SU, eg. for snapshots. >>> >> >> >> Em... IIRC SU and snapshots are independent, no? >> >> Cheers, >> > > > What about mounting the filesystem async though? It was my understanding > that the Linux filesystems were much faster in benchmarks because they > were mounted async by default, however the presence of journaling > allowed this safely. Is this the case here too? > Yes, async mounting is much faster that sync mounting, and slightly faster than SU, except when SU is dealing with huge data sets. Then async is significantly faster. Scott From owner-freebsd-geom@FreeBSD.ORG Tue Jun 20 20:50:17 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69A4516A47C for ; Tue, 20 Jun 2006 20:50:17 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22F8043D6A for ; Tue, 20 Jun 2006 20:50:10 +0000 (GMT) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id h2so1246nfe for ; Tue, 20 Jun 2006 13:50:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to; b=V+SfkU1yMDE8CPKJ5Y7Ojk8uWGueDBuZgYFi754VxAJ6rinWPIH98lNLhimlu0XAuaTVNgQ7VSJVlM86l0R84Wo1jsiALZlFW+QOn49VG5kQSOVxvVPTY6j0JkBGd6yu9HO5nu0zGLcqNx9/7+nDaLrJRbk+Rs/2Q5q/Wo/VEv0= Received: by 10.49.60.12 with SMTP id n12mr6009379nfk; Tue, 20 Jun 2006 13:43:54 -0700 (PDT) Received: from roadrunner.q.local ( [217.185.119.244]) by mx.gmail.com with ESMTP id a24sm7139686nfc.2006.06.20.13.43.52; Tue, 20 Jun 2006 13:43:53 -0700 (PDT) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.6/8.13.6) with ESMTP id k5KKi37R003488; Tue, 20 Jun 2006 22:44:04 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.13.6/8.13.6/Submit) id k5KHXdv3002364; Tue, 20 Jun 2006 19:33:39 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Tue, 20 Jun 2006 19:33:39 +0200 From: Ulrich Spoerlein To: Pawel Jakub Dawidek Message-ID: <20060620173339.GA1638@roadrunner.informatik.uni-wuerzburg.de> Mail-Followup-To: Pawel Jakub Dawidek , freebsd-current@FreeBSD.org, freebsd-fs@FreeBSD.org, freebsd-geom@FreeBSD.org References: <20060619131101.GD1130@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <20060619131101.GD1130@garage.freebsd.pl> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 20:50:17 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Pawel Jakub Dawidek wrote: > Hello. >=20 > For the last few months I have been working on gjournal project. Cool Stuff! > Reading. grep -r on two src/ directories in parallel: > UFS: 84s > UFS+SU: 138s > gjournal(1): 102s > gjournal(2): 89s >=20 > As you can see, even on one disk, untaring eight src.tgz is two times > faster than UFS+SU. I've no idea why gjournal is faster in reading. The UFS+SU score doesn't seem right. Why do SU have a negative impact on read performance? Is it solely because of the atime updates? Ulrich Spoerlein --=20 PGP Key ID: 20FEE9DD Encrypted mail welcome! Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD Which is worse: ignorance or apathy? Don't know. Don't care. --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEmDFy524iJyD+6d0RAgcyAJoDlV8lNXEyU0AdGTc9XJtCSpYbLACfYEI3 yjo78oywHF0CfLTt9aq5IzI= =0lpD -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From owner-freebsd-geom@FreeBSD.ORG Tue Jun 20 20:53:12 2006 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DCDA16A47A; Tue, 20 Jun 2006 20:53:12 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id D05D243D53; Tue, 20 Jun 2006 20:53:11 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id D3D4B51814; Tue, 20 Jun 2006 22:53:08 +0200 (CEST) Received: from localhost (dkb36.neoplus.adsl.tpnet.pl [83.24.5.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 24F9F50EA7; Tue, 20 Jun 2006 22:53:00 +0200 (CEST) Date: Tue, 20 Jun 2006 22:50:22 +0200 From: Pawel Jakub Dawidek To: Phil Regnauld Message-ID: <20060620205022.GB8007@garage.freebsd.pl> References: <20060619131101.GD1130@garage.freebsd.pl> <20060620102910.GG27055@tetard.starbsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qlTNgmc+xy1dBmNv" Content-Disposition: inline In-Reply-To: <20060620102910.GG27055@tetard.starbsd.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 20:53:12 -0000 --qlTNgmc+xy1dBmNv Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 20, 2006 at 12:29:10PM +0200, Phil Regnauld wrote: +> On Mon, Jun 19, 2006 at 03:11:01PM +0200, Pawel Jakub Dawidek wrote: +> >=20 +> > Copying one large file: +> > UFS: 8s +> > UFS+SU: 8s +> > gjournal(1): 16s +> > gjournal(2): 14s +>=20 +> This is very very interesting work! +>=20 +> I am definitely going to test this. +>=20 +> I know this is too early to ask considering the optimizations +> that can be done, but do you have any idea how this would perform +> compared to ReiserFS on similar operations as the ones you +> benchmarked ? No idea. I think ReiserFS is using only metadata journaling, but I don't know for sure. +> PS: is it me or is the patch missing a gjournal command, as invoked +> in your examples ? It is you:) gjournal(8) is implemented as shared library for geom(8) command, just like gconcat(8), gstripe(8), gmirror(8), graid3(8), geli(8), gnop(8), glabel(8) and gshsec(8). --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --qlTNgmc+xy1dBmNv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEmF+OForvXbEpPzQRAqUeAKCN+3d/HrYXz731kPvkf39DX9NX9ACeOwI2 Dc2MSZ4STzuYpZYc9lrLM50= =LvSB -----END PGP SIGNATURE----- --qlTNgmc+xy1dBmNv-- From owner-freebsd-geom@FreeBSD.ORG Tue Jun 20 21:26:55 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A51616A52A for ; Tue, 20 Jun 2006 21:26:55 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30313.mail.mud.yahoo.com (web30313.mail.mud.yahoo.com [68.142.201.231]) by mx1.FreeBSD.org (Postfix) with SMTP id 5BC4A43D7C for ; Tue, 20 Jun 2006 21:26:53 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 37059 invoked by uid 60001); 20 Jun 2006 21:26:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZgK1WoJHPRs/VoKMGyHqMKID413w3SLpLnPTYeM0hgLP6Scm59g5L6gqd1g9KF7A1JyOWoCQDvE5vomJ12D5uKDzzcGIXgqzLd0m8BYFU8r8FCmaabEKjnQZYIUyGX8qptNQWKeDKb+qcVRyTQQXvcZ0XbeN8tar5ZM4ty/LZnU= ; Message-ID: <20060620212652.37057.qmail@web30313.mail.mud.yahoo.com> Received: from [213.54.89.159] by web30313.mail.mud.yahoo.com via HTTP; Tue, 20 Jun 2006 14:26:52 PDT Date: Tue, 20 Jun 2006 14:26:52 -0700 (PDT) From: "R. B. Riddick" To: freebsd-geom@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: geom_raid5 / work in progress already? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 21:26:55 -0000 Hi! Is somebody working on geom_raid5 or so? Or do we already have that? I found, that geom_raid3 might be quite restrictive and slow... I would like to try to write a geom_raid5 based on geom_stripe... But I would like to avoid doing redundant work, too... Bye Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-geom@FreeBSD.ORG Wed Jun 21 06:50:49 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E00E16A474 for ; Wed, 21 Jun 2006 06:50:49 +0000 (UTC) (envelope-from frank.b.scholl@web.de) Received: from fmmailgate01.web.de (fmmailgate01.web.de [217.72.192.221]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BDB043D45 for ; Wed, 21 Jun 2006 06:50:48 +0000 (GMT) (envelope-from frank.b.scholl@web.de) Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate01.web.de (Postfix) with ESMTP id 75A0D30DDE3 for ; Wed, 21 Jun 2006 08:50:46 +0200 (CEST) Received: from [85.216.1.218] (helo=[192.168.1.1]) by smtp05.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.107 #114) id 1FswY2-0007ol-00 for freebsd-geom@freebsd.org; Wed, 21 Jun 2006 08:50:46 +0200 From: "Frank B. Scholl" To: freebsd-geom@freebsd.org Date: Wed, 21 Jun 2006 08:50:58 +0200 User-Agent: KMail/1.9.3 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606210850.58525.frank.b.scholl@web.de> Sender: frank.b.scholl@web.de X-Sender: frank.b.scholl@web.de Subject: GEOM_MIRROR after crash not identical X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 06:50:49 -0000 hello list, i just wanted to describe what happened to me last night. i have an ultra 10 running with a highpoint ide controller, on each channel there are udma100 drives. booting is done via compact flash with the onboard controller. the two udma100 drives form a mirror, which is encrypted with geli. after creating the device with gmirror and inserting the other disk, everything ran fine. then i needed to power down the machine to add more drives. after the machine came up, the mirror was degraded. it always failed to insert the second disk as a valid provider. wouldnt be that bad, i thought, just remount the degraded mirror readonly and backup data, after that lets see what can be done. well, after mounting i saw a lot of data missing, to be exact 180gb from 300gb total. so i thought it might be a problem of the filesystem and tried to fsck it. didnt work either, there are a lot of unreadable blocks on the device, geom_geli through geom_mirror didnt stop flooding my logs. problem: dma timeouts and interrupt storms en masse - with a controller that beforehand worked flawlessly over _weeks_ without any reboot. so i forced hw.ata.ata_dma and hw.ata.atapi_dma to zero and circumvented the timeout problem. changing cables didnt work, either, btw, what seems to be common practice in such cases. so far, i ve only worked on the first disk and decided to go to sleep after having lost 180gb of data to a mirror device. next morning, i woke up and had quite a good idea: lets try the same thing - mounting the degraded mirror - again, but with the second provider only. so i unplugged the first disk, booted, and see, it worked. so now.. how can that be that after a single reboot the two providers are not exactly the same? the thing is.. last data i have on the first provider is from 14 june, on the second provider i have everything until 20 june. the machine was powered down yesterday and was running at least since this month, if not longer. i went through the logfiles and there was not a single hint, where geom_mirror claimed about inconsistency. any ideas? my data is back, so i dont cry anymore. is this a problem due to my platform choice? namely sparc64? thanks for an answer, cheers, frank scholl From owner-freebsd-geom@FreeBSD.ORG Wed Jun 21 15:30:25 2006 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FA0216A47C; Wed, 21 Jun 2006 15:30:25 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32E8E43D5A; Wed, 21 Jun 2006 15:30:23 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 5B36C10D098; Thu, 22 Jun 2006 01:30:21 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5LFUIqT018161; Thu, 22 Jun 2006 01:30:19 +1000 Date: Thu, 22 Jun 2006 01:30:18 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Ulrich Spoerlein In-Reply-To: <20060620173339.GA1638@roadrunner.informatik.uni-wuerzburg.de> Message-ID: <20060622003036.M52310@delplex.bde.org> References: <20060619131101.GD1130@garage.freebsd.pl> <20060620173339.GA1638@roadrunner.informatik.uni-wuerzburg.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Pawel Jakub Dawidek , freebsd-geom@FreeBSD.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 15:30:25 -0000 On Tue, 20 Jun 2006, Ulrich Spoerlein wrote: > Pawel Jakub Dawidek wrote: >> Hello. >> >> For the last few months I have been working on gjournal project. > > Cool Stuff! > >> Reading. grep -r on two src/ directories in parallel: >> UFS: 84s >> UFS+SU: 138s >> gjournal(1): 102s >> gjournal(2): 89s >> >> As you can see, even on one disk, untaring eight src.tgz is two times >> faster than UFS+SU. I've no idea why gjournal is faster in reading. > > The UFS+SU score doesn't seem right. Why do SU have a negative impact on > read performance? Is it solely because of the atime updates? ffs+SU is only 1-10% slower than ffs in my benchmarks of reading back a copy of most of src/ written to a new file system by the same filesystem (code) that does the readback. The speed only depends on which file system wrote the data. I use tar for reading. Maybe concurrent greps on separate directories amplify the problem. A tiny subset of saved benchmarked output: %%% Jan 29 2004 real-current writing to WD 1200JB h: 26683965 73593765 --- srcs = "contrib crypto lib sys" in /usr/src ffs-16384-02048-1: tarcp /f srcs: 43.23 real 0.65 user 6.85 sys tar cf /dev/zero srcs: 15.58 real 0.19 user 2.13 sys ffs-16384-02048-2: tarcp /f srcs: 41.26 real 0.50 user 7.06 sys tar cf /dev/zero srcs: 15.80 real 0.25 user 2.10 sys ffs-16384-02048-as-1: tarcp /f srcs: 22.17 real 0.49 user 6.47 sys tar cf /dev/zero srcs: 15.52 real 0.22 user 2.13 sys ffs-16384-02048-as-2: tarcp /f srcs: 21.67 real 0.45 user 6.61 sys tar cf /dev/zero srcs: 15.65 real 0.19 user 2.16 sys ffs-16384-02048-su-1: tarcp /f srcs: 60.35 real 0.49 user 7.02 sys tar cf /dev/zero srcs: 17.32 real 0.20 user 2.15 sys ffs-16384-02048-su-2: tarcp /f srcs: 61.82 real 0.50 user 7.14 sys tar cf /dev/zero srcs: 17.56 real 0.21 user 2.17 sys %%% Notation: 16384-02048 is the block-frag size; /""/as/su/ are /default/async mounts/soft updates/; -[12] is ffs[12]. The source tree is prefetched into VMIO so that the copy part of the benchmark is mostly a write benchmark and is not affected by any slowness in the physical source file system. The above shows soft updates being about 2 seconds or 10% slower for read-back. It also shows that soft updates is about 3 times as slow as async mounts and about 1.5 times as slow as the default (sync metadata and async data). Soft updates was faster than the default when it was first implemented, but became slower at least for writing a copy of src/. This seems to be due to soft updates interacting badly with bufdaemon. This may be fixed now (I have later runs of the benchmark showing soft updates having about the same speed as the default, but none for -realcurrent). I never found the exact cause of the slower readback. My theory is that block allocation is more delayed in the soft updates case, and soft updates uses this to perfectly pessimize some aspects of the allocation. My version of ffs allocates the first indirect block between the NDADDR-1'th and NDADDR'th data blocks. This seems to help generally, and reduces the disadvantage of soft updates. IIRC, the default normally puts this block not very far away but not necessarily between the data blocks, but soft updates pessimizes it by moving it a long way away. It's still surprising that this makes nearly a 10% difference for src/, since most files in src/ are too small to have even 1 indirect block. I always disable atime updates on ffs file systems and don't have comparitive benchmarks for the difference from this. Bruce From owner-freebsd-geom@FreeBSD.ORG Wed Jun 21 17:02:22 2006 Return-Path: X-Original-To: freebsd-geom@hub.freebsd.org Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6E1016A474; Wed, 21 Jun 2006 17:02:22 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75B4B43DA0; Wed, 21 Jun 2006 17:02:04 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5LH24r9081398; Wed, 21 Jun 2006 17:02:04 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5LH24bj081394; Wed, 21 Jun 2006 17:02:04 GMT (envelope-from linimon) Date: Wed, 21 Jun 2006 17:02:04 GMT From: Mark Linimon Message-Id: <200606211702.k5LH24bj081394@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org Cc: Subject: Re: kern/99256: [geli] kernel panic/freeze with geli and ufs (maybe related to PR: kern/98093) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 17:02:23 -0000 Old Synopsis: kernel panic/freeze with geli and ufs [maybe related to PR: kern/98093] New Synopsis: [geli] kernel panic/freeze with geli and ufs (maybe related to PR: kern/98093) Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jun 21 17:01:09 UTC 2006 Responsible-Changed-Why: Reclassify and assign. http://www.freebsd.org/cgi/query-pr.cgi?pr=99256 From owner-freebsd-geom@FreeBSD.ORG Thu Jun 22 09:49:06 2006 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DAD416A67D; Thu, 22 Jun 2006 09:49:06 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 082CA441AF; Thu, 22 Jun 2006 09:48:35 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 7583551853; Thu, 22 Jun 2006 11:48:33 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id A7BEA51849; Thu, 22 Jun 2006 11:48:29 +0200 (CEST) Date: Thu, 22 Jun 2006 11:45:52 +0200 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org, freebsd-fs@FreeBSD.org, freebsd-geom@FreeBSD.org Message-ID: <20060622094552.GC30568@garage.freebsd.pl> References: <20060619131101.GD1130@garage.freebsd.pl> <20060620173339.GA1638@roadrunner.informatik.uni-wuerzburg.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DIOMP1UsTsWJauNi" Content-Disposition: inline In-Reply-To: <20060620173339.GA1638@roadrunner.informatik.uni-wuerzburg.de> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 09:49:06 -0000 --DIOMP1UsTsWJauNi Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 20, 2006 at 07:33:39PM +0200, Ulrich Spoerlein wrote: +> Pawel Jakub Dawidek wrote: +> > Reading. grep -r on two src/ directories in parallel: +> > UFS: 84s +> > UFS+SU: 138s +> > gjournal(1): 102s +> > gjournal(2): 89s +> >=20 +> > As you can see, even on one disk, untaring eight src.tgz is two times +> > faster than UFS+SU. I've no idea why gjournal is faster in reading. +>=20 +> The UFS+SU score doesn't seem right. Why do SU have a negative impact on +> read performance? Is it solely because of the atime updates? As I said, I've not idea. You may simply ignore my benchmarks and try them on your own:) --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --DIOMP1UsTsWJauNi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEmmbQForvXbEpPzQRAjOhAJ9HYmJq9Mnk9C7okc6eR5sxED6o5wCfW+MI /SRcuCebXaP1hRN/30tbW+Q= =ktIy -----END PGP SIGNATURE----- --DIOMP1UsTsWJauNi-- From owner-freebsd-geom@FreeBSD.ORG Thu Jun 22 09:55:34 2006 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DF8216A47A; Thu, 22 Jun 2006 09:55:34 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D8F144035; Thu, 22 Jun 2006 09:55:33 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0DB7D51884; Thu, 22 Jun 2006 11:55:32 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id C7ACB51853; Thu, 22 Jun 2006 11:55:27 +0200 (CEST) Date: Thu, 22 Jun 2006 11:52:50 +0200 From: Pawel Jakub Dawidek To: Xin LI Message-ID: <20060622095250.GD30568@garage.freebsd.pl> References: <20060619131101.GD1130@garage.freebsd.pl> <44984A91.8040805@rogers.com> <20060620193630.GA8007@garage.freebsd.pl> <1150833586.24301.1.camel@spirit> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jL2BoiuKMElzg3CS" Content-Disposition: inline In-Reply-To: <1150833586.24301.1.camel@spirit> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org, Mike Jakubik , freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 09:55:34 -0000 --jL2BoiuKMElzg3CS Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 21, 2006 at 03:59:46AM +0800, Xin LI wrote: +> ??? 2006-06-20?????? 21:36 +0200???Pawel Jakub Dawidek????????? +> > The performance impact is big for large files, because in theory we ha= ve +> > to write the data twice. +> > Yes, it eliminates need for SU, but there are reasons, that you still +> > want to use SU, eg. for snapshots. +>=20 +> Em... IIRC SU and snapshots are independent, no? Oops. Yes, you are right. bgfsck depends on SU, not snapshots. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --jL2BoiuKMElzg3CS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEmmhyForvXbEpPzQRAohQAJ9cSI5QpRK5ghxwucJ91+fshMSIigCfeDjD UHVHqWF9yKOf+SsGJViLP5c= =nTBz -----END PGP SIGNATURE----- --jL2BoiuKMElzg3CS-- From owner-freebsd-geom@FreeBSD.ORG Thu Jun 22 10:08:59 2006 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E0A616A479; Thu, 22 Jun 2006 10:08:59 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6821B43D88; Thu, 22 Jun 2006 10:08:58 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 7920851814; Thu, 22 Jun 2006 12:08:57 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id DB27750EA7; Thu, 22 Jun 2006 12:08:51 +0200 (CEST) Date: Thu, 22 Jun 2006 12:06:14 +0200 From: Pawel Jakub Dawidek To: Bakul Shah Message-ID: <20060622100614.GF30568@garage.freebsd.pl> References: <20060619131101.GD1130@garage.freebsd.pl> <20060620202948.933F2294C1@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VuQYccsttdhdIfIP" Content-Disposition: inline In-Reply-To: <20060620202948.933F2294C1@mail.bitblocks.com> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 10:08:59 -0000 --VuQYccsttdhdIfIP Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 20, 2006 at 01:29:48PM -0700, Bakul Shah wrote: +> This is great! We have sorely needed this for quite a while +> what with terabyte size filesystems getting into common use. +>=20 +> > How it works (in short). You may define one or two providers which +> > gjournal will use. If one provider is given, it will be used for both - +> > data and journal. If two providers are given, one will be used for data +> > and one for journal. +> > Every few seconds (you may define how many) journal is terminated and +> > marked as consistent and gjournal starts to copy data from it to the +> > data provider. In the same time new data are stored in new journal. +>=20 +> Some random comments: +>=20 +> Would it make sense to treat the journal as a circular +> buffer? Then commit to the underlying provider starts when +> the buffer has $hiwater blocks or the upper layer wants to +> sync. The commit stops when the buffer has $lowater blocks +> or in case of sync the buffer is empty. This will allow +> parallel writes to the provider and the journal, thereby +> reducing latency. This is bascially what is done now. There are always two journal - active and inactive. New data are written to the active journal. When journal switch time arrives (timeout occurs or cache is full), the active journal is terminated and new active journal is started right after this one. The previous active journal becomes inactive and the data is copied to the destination (data) provider in parallel to new requests which are stored in the active journal. Writes are suspended only on synchronize file system and terminate the active journal. Copying data from the inactive journal is done in parallel to normal operations. +> I don't understand why you need FS synchronization. Once the +> journal is written, the data is safe. [...] Which data? When you for example delete a file, you need to perform those operations: - remove name from a directory - mark inode as free - mark blocks as free Synchronizing file system gives me certainty that all those operations reached gjournal, so I can safely mark file system as clean and terminate the journal. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --VuQYccsttdhdIfIP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEmmuWForvXbEpPzQRAkx5AKDwCF5E7AnzKAMcIrzidCm3f841GACfbc4W TbyLYq/4XoccF4Zb4qfRNac= =OMuu -----END PGP SIGNATURE----- --VuQYccsttdhdIfIP-- From owner-freebsd-geom@FreeBSD.ORG Fri Jun 23 08:22:39 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA78D16A492; Fri, 23 Jun 2006 08:22:39 +0000 (UTC) (envelope-from never@kurush.osdn.org.ua) Received: from kurush.osdn.org.ua (external.osdn.org.ua [212.40.34.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C06C43D46; Fri, 23 Jun 2006 08:22:22 +0000 (GMT) (envelope-from never@kurush.osdn.org.ua) Received: from kurush.osdn.org.ua (never@localhost [127.0.0.1]) by kurush.osdn.org.ua (8.12.11/8.12.11) with ESMTP id k5N8MAlM073999; Fri, 23 Jun 2006 11:22:11 +0300 (EEST) (envelope-from never@kurush.osdn.org.ua) Received: (from never@localhost) by kurush.osdn.org.ua (8.12.11/8.12.11/Submit) id k5N8M9vB073996; Fri, 23 Jun 2006 11:22:09 +0300 (EEST) (envelope-from never) Date: Fri, 23 Jun 2006 11:22:09 +0300 From: Alexandr Kovalenko To: Pawel Jakub Dawidek Message-ID: <20060623082209.GD13474@nevermind.kiev.ua> References: <20060619131101.GD1130@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060619131101.GD1130@garage.freebsd.pl> User-Agent: Mutt/1.5.4i Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 08:22:39 -0000 Hello, Pawel Jakub Dawidek! On Mon, Jun 19, 2006 at 03:11:01PM +0200, you wrote: > For the last few months I have been working on gjournal project. > To stop confusion right here, I want to note, that this project is not > related to gjournal project on which Ivan Voras was working on the > last SoC (2005). [dd] > Quick start: > > # gjournal label /dev/ad0 > # gjournal load > # newfs /dev/ad0.journal > # mount -o async,gjournal /dev/ad0.journal /mnt > (yes, with gjournal 'async' is safe) > > Now, after a power failure or system crash no fsck is needed (yay!). Is it safe to do so on existing filesystem (if I'm using 2nd partition for journal)? i.e.: $ grep ad0s1f /etc/fstab /dev/ad0s1f /usr ufs rw,noatime 2 2 $ grep ad0s1b /etc/fstab #/dev/ad0s1b none swap sw 0 0 # gjournal label ad0s1f ad0s1b # gjournal load # fsck -y /dev/ad0s1f.journal # sed -i -e 's|ad0s1f|ad0s1f.journal|' /etc/fstab # sed -i -e 's|noatime|noatime,async,gjournal|' /etc/fstab # mount /usr -- NEVE-RIPE, will build world for food Ukrainian FreeBSD User Group http://uafug.org.ua/ From owner-freebsd-geom@FreeBSD.ORG Fri Jun 23 08:38:40 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31A0616A494 for ; Fri, 23 Jun 2006 08:38:40 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30308.mail.mud.yahoo.com (web30308.mail.mud.yahoo.com [68.142.200.101]) by mx1.FreeBSD.org (Postfix) with SMTP id A6ED143D53 for ; Fri, 23 Jun 2006 08:38:38 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 86541 invoked by uid 60001); 23 Jun 2006 08:38:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=F3rZ2dXJ6OklEpWvhqIZ/euBNIWOJXDu3T/EMhEpd0s2JcjwrQPSfF6BUbAkJ/PtxcDyK9l/Ss6/FFXwxXwyd97wx/GwUy4Le5mJrat+qqGnpHxGkMqEi3ID4qeR+Cni6jXZ0dvb5husRPpXvNJO465S63ldbwJu5CtBda7i7oY= ; Message-ID: <20060623083838.86539.qmail@web30308.mail.mud.yahoo.com> Received: from [213.54.80.34] by web30308.mail.mud.yahoo.com via HTTP; Fri, 23 Jun 2006 01:38:38 PDT Date: Fri, 23 Jun 2006 01:38:38 -0700 (PDT) From: "R. B. Riddick" To: Alexandr Kovalenko In-Reply-To: <20060623082209.GD13474@nevermind.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 08:38:40 -0000 --- Alexandr Kovalenko wrote: > Is it safe to do so on existing filesystem (if I'm using 2nd partition for > journal)? > Hmm... Depends: If your existing file system needs its last sector, then it wont work. If it does not need it, then it might work (although fsck does not check for a raw-device shrinkage - I think)... I say, can you make the size of ad0s1f one sector bigger with bsdlabel(8) without changing the start sector? I mean: Is there at least one free sector after ad0s1f? -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-geom@FreeBSD.ORG Fri Jun 23 08:53:33 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4520816A494; Fri, 23 Jun 2006 08:53:33 +0000 (UTC) (envelope-from never@kurush.osdn.org.ua) Received: from kurush.osdn.org.ua (external.osdn.org.ua [212.40.34.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61F3743D45; Fri, 23 Jun 2006 08:52:49 +0000 (GMT) (envelope-from never@kurush.osdn.org.ua) Received: from kurush.osdn.org.ua (never@localhost [127.0.0.1]) by kurush.osdn.org.ua (8.12.11/8.12.11) with ESMTP id k5N8qbal076002; Fri, 23 Jun 2006 11:52:37 +0300 (EEST) (envelope-from never@kurush.osdn.org.ua) Received: (from never@localhost) by kurush.osdn.org.ua (8.12.11/8.12.11/Submit) id k5N8qbof075999; Fri, 23 Jun 2006 11:52:37 +0300 (EEST) (envelope-from never) Date: Fri, 23 Jun 2006 11:52:37 +0300 From: Alexandr Kovalenko To: "R. B. Riddick" Message-ID: <20060623085236.GE13474@nevermind.kiev.ua> References: <20060623082209.GD13474@nevermind.kiev.ua> <20060623083838.86539.qmail@web30308.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623083838.86539.qmail@web30308.mail.mud.yahoo.com> User-Agent: Mutt/1.5.4i Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 08:53:33 -0000 Hello, R. B. Riddick! On Fri, Jun 23, 2006 at 01:38:38AM -0700, you wrote: > --- Alexandr Kovalenko wrote: > > Is it safe to do so on existing filesystem (if I'm using 2nd partition for > > journal)? > > > Hmm... > > Depends: > If your existing file system needs its last sector, then it wont work. If it > does not need it, then it might work (although fsck does not check for a > raw-device shrinkage - I think)... > > I say, can you make the size of ad0s1f one sector bigger with bsdlabel(8) > without changing the start sector? > I mean: Is there at least one free sector after ad0s1f? Unfortunately - no :( -- NEVE-RIPE, will build world for food Ukrainian FreeBSD User Group http://uafug.org.ua/ From owner-freebsd-geom@FreeBSD.ORG Fri Jun 23 09:05:32 2006 Return-Path: X-Original-To: geom@freebsd.org Delivered-To: freebsd-geom@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5EAF16A49E; Fri, 23 Jun 2006 09:05:32 +0000 (UTC) (envelope-from Geoff.Buckingham@reuters.com) Received: from hpgsmime03.rit.reuters.com (hpgsmime03.rit.reuters.com [167.206.189.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2062143D60; Fri, 23 Jun 2006 09:05:29 +0000 (GMT) (envelope-from Geoff.Buckingham@reuters.com) Received: from eupig2 (unverified [129.1.30.40]) by hpgsmime03.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id ; Fri, 23 Jun 2006 09:03:28 +0000 Received: from LONSMSXB02.emea.ime.reuters.com ([10.14.113.7]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31217) with ESMTP id <0J1B000XW2HP2S@eupig2.dtc.lon.ime.reuters.com>; Fri, 23 Jun 2006 09:03:25 +0000 (GMT) Received: from LONSMSXM04.emea.ime.reuters.com ([10.14.113.14]) by LONSMSXB02.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Fri, 23 Jun 2006 10:03:25 +0100 Date: Fri, 23 Jun 2006 10:03:24 +0100 From: Geoff Buckingham To: geom@freebsd.org, scsi@freebsd.org Message-id: <8753F8EA457BFF4A9707CADA143C8F68012609D2@LONSMSXM04.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: Strange boot delay on Proliant hardware. (RELENG_6_1) Thread-Index: AcaWo+HwpbldNg4QQWC1oAOPeoP8dA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 23 Jun 2006 09:03:25.0266 (UTC) FILETIME=[E2A0C320:01C696A3] Cc: Subject: Strange boot delay on Proliant hardware. (RELENG_6_1) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 09:05:32 -0000 In RELENG_6_1 I am seeing a strange delay of around thirty seconds when booting on Proliant Servers. I do not see the delay on other servers with the same kernel. I suspect some disagreement between GEOM and the ciss driver/controller. The delay increases if I compile into the kernel, or load more GEOM kernel modules before boot. Is there a way to get more verbose output from GEOM at boot time? Is it possible GEOM is confused by the SmartArrays on-disk array configuration data, which I assume should not be visible on da* devices provided by the ciss driver? Jun 23 07:48:39 k11-dl380g3 kernel: da0 at ciss0 bus 0 target 0 lun 0 Jun 23 07:48:39 k11-dl380g3 kernel: da0: Fixed Direct Access SCSI-0 device Jun 23 07:48:39 k11-dl380g3 kernel: da0: 135.168MB/s transfers Jun 23 07:48:39 k11-dl380g3 kernel: da0: 17359MB (35553120 512 byte sectors: 255H 32S/T 4357C) Jun 23 07:48:39 k11-dl380g3 kernel: da1 at ciss0 bus 0 target 1 lun 0 Jun 23 07:48:39 k11-dl380g3 kernel: da1: Fixed Direct Access SCSI-0 device Jun 23 07:48:39 k11-dl380g3 kernel: da1: 135.168MB/s transfers Jun 23 07:48:39 k11-dl380g3 kernel: da1: 208378MB (426759840 512 byte sectors: 255H 32S/T 52299C) Jun 23 07:48:39 k11-dl380g3 kernel: GEOM: new disk da0 Jun 23 07:48:39 k11-dl380g3 kernel: GEOM: new disk da1 Full boot -v ouput: Jun 23 07:48:39 k11-dl380g3 syslogd: kernel boot file is /boot/kernel/kernel Jun 23 07:48:39 k11-dl380g3 kernel: 6 as a target Jun 23 07:48:39 k11-dl380g3 kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Jun 23 07:48:39 k11-dl380g3 kernel: cpu0 (BSP): APIC ID: 0 Jun 23 07:48:39 k11-dl380g3 kernel: cpu1 (AP): APIC ID: 1 Jun 23 07:48:39 k11-dl380g3 kernel: cpu2 (AP): APIC ID: 6 Jun 23 07:48:39 k11-dl380g3 kernel: cpu3 (AP): APIC ID: 7 Jun 23 07:48:39 k11-dl380g3 kernel: bios32: Found BIOS32 Service Directory header at 0xc00ffee0 Jun 23 07:48:39 k11-dl380g3 kernel: bios32: Entry =3D 0xf0000 (c00f0000) Rev =3D 0 Len =3D 1 Jun 23 07:48:39 k11-dl380g3 kernel: pcibios: PCI BIOS entry at 0xf0000+0x94 Jun 23 07:48:39 k11-dl380g3 kernel: Other BIOS signatures found: Jun 23 07:48:39 k11-dl380g3 kernel: APIC: CPU 0 has ACPI ID 0 Jun 23 07:48:39 k11-dl380g3 kernel: APIC: CPU 1 has ACPI ID 1 Jun 23 07:48:39 k11-dl380g3 kernel: APIC: CPU 2 has ACPI ID 6 Jun 23 07:48:39 k11-dl380g3 kernel: APIC: CPU 3 has ACPI ID 7 Jun 23 07:48:39 k11-dl380g3 kernel: MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: Routing external 8259A's -> intpin 0 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 0 -> ExtINT (edge, high) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) Jun 23 07:48:39 k11-dl380g3 kernel: MADT: Found IO APIC ID 3, Interrupt 16 at 0xfec01000 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: intpin 0 -> PCI IRQ 16 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: intpin 1 -> PCI IRQ 17 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: intpin 2 -> PCI IRQ 18 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: intpin 3 -> PCI IRQ 19 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: intpin 4 -> PCI IRQ 20 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: intpin 5 -> PCI IRQ 21 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: intpin 6 -> PCI IRQ 22 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: intpin 7 -> PCI IRQ 23 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: intpin 8 -> PCI IRQ 24 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: intpin 9 -> PCI IRQ 25 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: intpin 11 -> PCI IRQ 27 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: intpin 12 -> PCI IRQ 28 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: intpin 13 -> PCI IRQ 29 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: intpin 14 -> PCI IRQ 30 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: intpin 15 -> PCI IRQ 31 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: MADT: Found IO APIC ID 4, Interrupt 32 at 0xfec02000 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic2: intpin 0 -> PCI IRQ 32 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic2: intpin 1 -> PCI IRQ 33 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic2: intpin 2 -> PCI IRQ 34 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic2: intpin 3 -> PCI IRQ 35 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic2: intpin 4 -> PCI IRQ 36 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic2: intpin 5 -> PCI IRQ 37 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic2: intpin 6 -> PCI IRQ 38 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic2: intpin 7 -> PCI IRQ 39 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic2: intpin 8 -> PCI IRQ 40 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic2: intpin 9 -> PCI IRQ 41 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic2: intpin 10 -> PCI IRQ 42 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic2: intpin 11 -> PCI IRQ 43 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic2: intpin 12 -> PCI IRQ 44 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic2: intpin 13 -> PCI IRQ 45 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic2: intpin 14 -> PCI IRQ 46 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic2: intpin 15 -> PCI IRQ 47 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: MADT: Found IO APIC ID 5, Interrupt 48 at 0xfec03000 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic3: intpin 0 -> PCI IRQ 48 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic3: intpin 1 -> PCI IRQ 49 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic3: intpin 2 -> PCI IRQ 50 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic3: intpin 3 -> PCI IRQ 51 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic3: intpin 4 -> PCI IRQ 52 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic3: intpin 5 -> PCI IRQ 53 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic3: intpin 6 -> PCI IRQ 54 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic3: intpin 7 -> PCI IRQ 55 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic3: intpin 8 -> PCI IRQ 56 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic3: intpin 9 -> PCI IRQ 57 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic3: intpin 10 -> PCI IRQ 58 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic3: intpin 11 -> PCI IRQ 59 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic3: intpin 12 -> PCI IRQ 60 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic3: intpin 13 -> PCI IRQ 61 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic3: intpin 14 -> PCI IRQ 62 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic3: intpin 15 -> PCI IRQ 63 (level, low) Jun 23 07:48:39 k11-dl380g3 kernel: MADT: Interrupt override: source 0, irq 2 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: Routing IRQ 0 -> intpin 2 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 2 trigger: edge Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 2 polarity: high Jun 23 07:48:39 k11-dl380g3 kernel: lapic: Routing NMI -> LINT1 Jun 23 07:48:39 k11-dl380g3 kernel: MADT: Forcing active-low polarity and level trigger for SCI Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 9 polarity: low Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: intpin 9 trigger: level Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0 irqs 0-15 on motherboard Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1 irqs 16-31 on motherboard Jun 23 07:48:39 k11-dl380g3 kernel: ioapic2 irqs 32-47 on motherboard Jun 23 07:48:39 k11-dl380g3 kernel: ioapic3 irqs 48-63 on motherboard Jun 23 07:48:39 k11-dl380g3 kernel: cpu0 BSP: Jun 23 07:48:39 k11-dl380g3 kernel: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff Jun 23 07:48:39 k11-dl380g3 kernel: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff Jun 23 07:48:39 k11-dl380g3 kernel: timer: 0x000100ef therm: 0x00010000 err: 0x000100f0 pcm: 0x00010000 Jun 23 07:48:39 k11-dl380g3 kernel: wlan: <802.11 Link Layer> Jun 23 07:48:39 k11-dl380g3 kernel: random: Jun 23 07:48:39 k11-dl380g3 kernel: nfslock: pseudo-device Jun 23 07:48:39 k11-dl380g3 kernel: io: Jun 23 07:48:39 k11-dl380g3 kernel: kbd: new array size 4 Jun 23 07:48:39 k11-dl380g3 kernel: kbd1 at kbdmux0 Jun 23 07:48:39 k11-dl380g3 kernel: mem: Jun 23 07:48:39 k11-dl380g3 kernel: Pentium Pro MTRR support enabled Jun 23 07:48:39 k11-dl380g3 kernel: null: Jun 23 07:48:39 k11-dl380g3 kernel: rr232x: RocketRAID 232x controller driver v1.02 (May 25 2006 08:45:12) Jun 23 07:48:39 k11-dl380g3 kernel: npx0: INT 16 interface Jun 23 07:48:39 k11-dl380g3 kernel: acpi0: on motherboard Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 Jun 23 07:48:39 k11-dl380g3 kernel: acpi0: [MPSAFE] Jun 23 07:48:39 k11-dl380g3 kernel: acpi0: Power Button (fixed) Jun 23 07:48:39 k11-dl380g3 kernel: pci_open(1): mode 1 addr port (0x0cf8) is 0x00000000 Jun 23 07:48:39 k11-dl380g3 kernel: pci_open(1a): mode1res=3D0x80000000 (0x80000000) Jun 23 07:48:39 k11-dl380g3 kernel: pci_cfgcheck: device 0 [class=3D060000] [hdr=3D80] is there (id=3D00141166) Jun 23 07:48:39 k11-dl380g3 kernel: pcibios: BIOS version 2.10 Jun 23 07:48:39 k11-dl380g3 kernel: AcpiOsDerivePciId: bus 0 dev 0 func 0 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link0: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 7 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link0: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 7 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link0: Links after disable: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link1: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 3 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link1: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link1: Links after disable: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link2: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 5 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link2: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 5 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link2: Links after disable: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link3: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 7 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link3: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 7 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link3: Links after disable: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link4: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link4: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link4: Links after disable: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link5: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 15 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link5: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 15 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link5: Links after disable: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link6: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 11 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link6: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 11 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link6: Links after disable: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link7: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link7: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link7: Links after disable: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link8: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link8: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link8: Links after disable: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link9: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link9: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link9: Links after disable: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link10: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link10: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link10: Links after disable:Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link11: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link11: Links after disable: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link12: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link12: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link12: Links after disable: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link13: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link13: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link13: Links after disable: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link14: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 11 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link14: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQsJun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 15 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link16: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 15 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link16: Links after disable: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link17: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link17: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link17: Links after disable: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link18: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link18: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link18: Links after disable: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link19: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15Jun 23 07:48:39 k11-dl380g3 kernel: pci0: on pcib0 Jun 23 07:48:39 k11-dl380g3 kernel: pci0: physical bus=3D0 Jun 23 07:48:39 k11-dl380g3 kernel: found-> vendor=3D0x1166, dev=3D0x0014, revid=3D0x33 Jun 23 07:48:39 k11-dl380g3 kernel: bus=3D0, slot=3D0, func=3D0 Jun 23 07:48:39 k11-dl380g3 kernel: class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 Jun 23 07:48:39 k11-dl380g3 kernel: cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D16 (dwords) Jun 23 07:48:39 k11-dl380g3 kernel: lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) Jun 23 07:48:39 k11-dl380g3 kernel: found-> vendor=3D0x1166, dev=3D0x0014, revid=3D0x00 Jun 23 07:48:39 k11-dl380g3 kernel: bus=3D0, slot=3D0, func=3D1 Jun 23 07:48:39 k11-dl380g3 kernel: class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 Jun 23 07:48:39 k11-dl380g3 kernel: cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D16 (dwords) Jun 23 07:48:39 k11-dl380g3 kernel: lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) Jun 23 07:48:39 k11-dl380g3 kernel: found-> vendor=3D0x1166, dev=3D0x0014, revid=3D0x00 Jun 23 07:48:39 k11-dl380g3 kernel: bus=3D0, slot=3D0, func=3D2 Jun 23 07:48:39 k11-dl380g3 kernel: class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 Jun 23 07:48:39 k11-dl380g3 kernel: cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D16 (dwords) Jun 23 07:48:39 k11-dl380g3 kernel: lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) Jun 23 07:48:39 k11-dl380g3 kernel: found-> vendor=3D0x1002, dev=3D0x4752, revid=3D0x27 Jun 23 07:48:39 k11-dl380g3 kernel: bus=3D0, slot=3D3, func=3D0 Jun 23 07:48:39 k11-dl380g3 kernel: class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 Jun 23 07:48:39 k11-dl380g3 kernel: cmdreg=3D0x0087, statreg=3D0x0290, cachelnsz=3D16 (dwords) Jun 23 07:48:39 k11-dl380g3 kernel: lattimer=3D0x40 (1920 ns), mingnt=3D0x08 (2000 ns), maxlat=3D0x00 (0 ns) Jun 23 07:48:39 k11-dl380g3 kernel: powerspec 2 supports D0 D1 D2 D3 current D0 Jun 23 07:48:39 k11-dl380g3 kernel: map[10]: type 1, range 32, base ef000000, size 24, enabled Jun 23 07:48:39 k11-dl380g3 kernel: map[14]: type 4, range 32, base 00002400, size 8, enabled Jun 23 07:48:39 k11-dl380g3 kernel: map[18]: type 1, range 32, base eeff0000, size 12, enabled Jun 23 07:48:39 k11-dl380g3 kernel: found-> vendor=3D0x0e11, dev=3D0xb203, revid=3D0x01 Jun 23 07:48:39 k11-dl380g3 kernel: bus=3D0, slot=3D4, func=3D0 Jun 23 07:48:39 k11-dl380g3 kernel: class=3D08-80-00, hdrtype=3D0x00, mfdev=3D1 Jun 23 07:48:39 k11-dl380g3 kernel: cmdreg=3D0x0103, statreg=3D0x0290, cachelnsz=3D0 (dwords) Jun 23 07:48:39 k11-dl380g3 kernel: lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)Jun 23 07:48:39 k11-dl380g3 kernel: map[10]: type 4, range 32, base 00002800, size 8, enabled Jun 23 07:48:39 k11-dl380g3 kernel: map[14]: type 1, range 32, base eefd0000, size 11, enabled Jun 23 07:48:39 k11-dl380g3 kernel: map[18]: type 1, range 32, base eefc0000, size 13, enabled Jun 23 07:48:39 k11-dl380g3 kernel: map[1c]: type 1, range 32, base eef00000, size 19, enabled Jun 23 07:48:39 k11-dl380g3 kernel: pcib0: matched entry for 0.4.INTB Jun 23 07:48:39 k11-dl380g3 kernel: pcib0: slot 4 INTB hardwired to IRQ 17 Jun 23 07:48:39 k11-dl380g3 kernel: found-> vendor=3D0x1166, dev=3D0x0201, revid=3D0x93 Jun 23 07:48:39 k11-dl380g3 kernel: bus=3D0, slot=3D15, func=3D0 Jun 23 07:48:39 k11-dl380g3 kernel: class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 Jun 23 07:48:39 k11-dl380g3 kernel: cmdreg=3D0x0147, statreg=3D0x2200, cachelnsz=3D0 (dwords) Jun 23 07:48:39 k11-dl380g3 kernel: lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) Jun 23 07:48:39 k11-dl380g3 kernel: found-> vendor=3D0x1166, dev=3D0x0212, revid=3D0x93 Jun 23 07:48:39 k11-dl380g3 kernel: bus=3D0, slot=3D15, func=3D1 Jun 23 07:48:39 k11-dl380g3 kernel: class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D1 Jun 23 07:48:39 k11-dl380g3 kernel: cmdreg=3D0x0145, statreg=3D0x0200, cachelnsz=3D0 (dwords) Jun 23 07:48:39 k11-dl380g3 kernel: lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) Jun 23 07:48:39 k11-dl380g3 kernel: map[20]: type 4, range 32, base 00002000, size 4, enabled Jun 23 07:48:39 k11-dl380g3 kernel: found-> vendor=3D0x1166, dev=3D0x0220, revid=3D0x05 Jun 23 07:48:39 k11-dl380g3 kernel: bus=3D0, slot=3D15, func=3D2 Jun 23 07:48:39 k11-dl380g3 kernel: class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D1 Jun 23 07:48:39 k11-dl380g3 kernel: cmdreg=3D0x0157, statreg=3D0x0280, cachelnsz=3D0 (dwords) Jun 23 07:48:39 k11-dl380g3 kernel: lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x50 (20000 ns) Jun 23 07:48:39 k11-dl380g3 kernel: intpin=3Da, irq=3D7 Jun 23 07:48:39 k11-dl380g3 kernel: map[10]: type 1, range 32, base eeef0000, size 12, enabled Jun 23 07:48:39 k11-dl380g3 kernel: pcib0: matched entry for 0.15.INTA (src \_SB_.IUSB:0) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: Changing trigger for pin 7 to level Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: Changing polarity for pin 7 to low Jun 23 07:48:39 k11-dl380g3 kernel: pcib0: slot 15 INTA routed to irq 7 via \_SB_.IUSB Jun 23 07:48:39 k11-dl380g3 kernel: found-> vendor=3D0x1166, dev=3D0x0225, revid=3D0x00 Jun 23 07:48:39 k11-dl380g3 kernel: bus=3D0, slot=3D15, func=3D3 Jun 23 07:48:39 k11-dl380g3 kernel: class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 Jun 23 07:48:39 k11-dl380g3 kernel: cmdreg=3D0x0004, statreg=3D0x0200, cachelnsz=3D0 (dwords) Jun 23 07:48:39 k11-dl380g3 kernel: lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) Jun 23 07:48:39 k11-dl380g3 kernel: found-> vendor=3D0x1166, dev=3D0x0101, revid=3D0x05 Jun 23 07:48:39 k11-dl380g3 kernel: bus=3D0, slot=3D16, func=3D0 Jun 23 07:48:39 k11-dl380g3 kernel: class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 Jun 23 07:48:39 k11-dl380g3 kernel: cmdreg=3D0x0142, statreg=3D0x0230, cachelnsz=3D0 (dwords) Jun 23 07:48:39 k11-dl380g3 kernel: lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) Jun 23 07:48:39 k11-dl380g3 kernel: found-> vendor=3D0x1166, dev=3D0x0101, revid=3D0x05 Jun 23 07:48:39 k11-dl380g3 kernel: bus=3D0, slot=3D16, func=3D2 Jun 23 07:48:39 k11-dl380g3 kernel: class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 Jun 23 07:48:39 k11-dl380g3 kernel: cmdreg=3D0x0142, statreg=3D0x02b0, cachelnsz=3D0 (dwords) Jun 23 07:48:39 k11-dl380g3 kernel: lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) Jun 23 07:48:39 k11-dl380g3 kernel: found-> vendor=3D0x1166, dev=3D0x0101, revid=3D0x05 Jun 23 07:48:39 k11-dl380g3 kernel: bus=3D0, slot=3D17, func=3D0 Jun 23 07:48:39 k11-dl380g3 kernel: class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 Jun 23 07:48:39 k11-dl380g3 kernel: cmdreg=3D0x0142, statreg=3D0x0230, cachelnsz=3D0 (dwords) Jun 23 07:48:39 k11-dl380g3 kernel: lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) Jun 23 07:48:39 k11-dl380g3 kernel: found-> vendor=3D0x1166, dev=3D0x0101, revid=3D0x05 Jun 23 07:48:39 k11-dl380g3 kernel: bus=3D0, slot=3D17, func=3D2 Jun 23 07:48:39 k11-dl380g3 kernel: class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 Jun 23 07:48:39 k11-dl380g3 kernel: cmdreg=3D0x0142, statreg=3D0x0230, cachelnsz=3D0 (dwords) Jun 23 07:48:39 k11-dl380g3 kernel: lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) Jun 23 07:48:39 k11-dl380g3 kernel: pci0: at device 3.0 (no driver attached) Jun 23 07:48:39 k11-dl380g3 kernel: pci0: at device 4.0 (no driver attached) Jun 23 07:48:39 k11-dl380g3 kernel: pci0: at device 4.2 (no driver attached) Jun 23 07:48:39 k11-dl380g3 kernel: isab0: at device 15.0 on pci0 Jun 23 07:48:39 k11-dl380g3 kernel: isa0: on isab0 Jun 23 07:48:39 k11-dl380g3 kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376, 0x2000-0x200f at device 15.1 on pci0 Jun 23 07:48:39 k11-dl380g3 kernel: atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x2000 Jun 23 07:48:39 k11-dl380g3 kernel: ata0: on atapci0 Jun 23 07:48:39 k11-dl380g3 kernel: atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 Jun 23 07:48:39 k11-dl380g3 kernel: atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 Jun 23 07:48:39 k11-dl380g3 kernel: ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D01 Jun 23 07:48:39 k11-dl380g3 kernel: ata0: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb Jun 23 07:48:39 k11-dl380g3 kernel: ata0: stat1=3D0x00 err=3D0x24 lsb=3D0xff msb=3D0x00 Jun 23 07:48:39 k11-dl380g3 kernel: ata0: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x4 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: routing intpin 14 (ISA IRQ 14) to vector 49 Jun 23 07:48:39 k11-dl380g3 kernel: ata0: [MPSAFE] Jun 23 07:48:39 k11-dl380g3 kernel: ata1: on atapci0 Jun 23 07:48:39 k11-dl380g3 kernel: atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 Jun 23 07:48:39 k11-dl380g3 kernel: atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 Jun 23 07:48:39 k11-dl380g3 kernel: ata1: reset tp1 mask=3D00 ostat0=3Dff ostat1=3Dff Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: routing intpin 15 (ISA IRQ 15) to vector 50 Jun 23 07:48:39 k11-dl380g3 kernel: ata1: [MPSAFE] Jun 23 07:48:39 k11-dl380g3 kernel: ohci0: mem 0xeeef0000-0xeeef0fff irq 7 at device 15.2 on pci0 Jun 23 07:48:39 k11-dl380g3 kernel: ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xeeef0000 Jun 23 07:48:39 k11-dl380g3 kernel: ohci0: (New OHCI DeviceId=3D0x02201166) Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: routing intpin 7 (ISA IRQ 7) to vector 51 Jun 23 07:48:39 k11-dl380g3 kernel: ohci0: [GIANT-LOCKED] Jun 23 07:48:39 k11-dl380g3 kernel: usb0: OHCI version 1.0, legacy support Jun 23 07:48:39 k11-dl380g3 kernel: usb0: SMM does not respond, resetting Jun 23 07:48:39 k11-dl380g3 kernel: usb0: on ohci0 Jun 23 07:48:39 k11-dl380g3 kernel: usb0: USB revision 1.0 Jun 23 07:48:39 k11-dl380g3 kernel: uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Jun 23 07:48:39 k11-dl380g3 kernel: uhub0: 4 ports with 4 removable, self powered Jun 23 07:48:39 k11-dl380g3 kernel: pcib1: on acpi0 Jun 23 07:48:39 k11-dl380g3 kernel: pci1: on pcib1 Jun 23 07:48:39 k11-dl380g3 kernel: pci1: physical bus=3D1 Jun 23 07:48:39 k11-dl380g3 kernel: found-> vendor=3D0x0e11, dev=3D0xb178, revid=3D0x01 Jun 23 07:48:39 k11-dl380g3 kernel: bus=3D1, slot=3D3, func=3D0 Jun 23 07:48:39 k11-dl380g3 kernel: class=3D01-04-00, hdrtype=3D0x00, mfdev=3D0 Jun 23 07:48:39 k11-dl380g3 kernel: cmdreg=3D0x0157, statreg=3D0x02b0, cachelnsz=3D16 (dwords) Jun 23 07:48:39 k11-dl380g3 kernel: lattimer=3D0x47 (2130 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) Jun 23 07:48:39 k11-dl380g3 kernel: intpin=3Da, irq=3D10 Jun 23 07:48:39 k11-dl380g3 kernel: powerspec 2 supports D0 D1 D3 current D0 Jun 23 07:48:39 k11-dl380g3 kernel: MSI supports 2 messages, 64 bit Jun 23 07:48:39 k11-dl380g3 kernel: map[10]: type 1, range 64, base f04c0000, size 18, enabled Jun 23 07:48:39 k11-dl380g3 kernel: map[18]: type 4, range 32, base 00003000, size 8, enabled Jun 23 07:48:39 k11-dl380g3 kernel: map[1c]: type 3, range 64, base f03f0000, size 14, enabled Jun 23 07:48:39 k11-dl380g3 kernel: pcib1: matched entry for 1.3.INTA Jun 23 07:48:39 k11-dl380g3 kernel: pcib1: slot 3 INTA hardwired to IRQ 30 Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: port 0x3000-0x30ff mem 0xf04c0000-0xf04fffff,0xf03f0000-0 xf03f3fff irq 30 at device 3.0 on pci1 Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: Reserved 0x40000 bytes for rid 0x10 type 3 at 0xf04c0000 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: routing intpin 14 (PCI IRQ 30) to vector 52 Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: [GIANT-LOCKED] Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: using 256 of 1024 available commands Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: firmware 2.56 Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: 2 SCSI channels Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: signature 'CISS' Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: valence 1 Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: supported I/O methods 0x6 Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: active I/O method 0x3 Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: 4G page base 0x00000000 Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: interrupt coalesce delay 1000us Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: interrupt coalesce count 16 Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: max outstanding commands 1024 Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: bus types 0x2 Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: server name '' Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: heartbeat 0x1000003e Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: 7 physical devices Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: 2 logical drives Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: logical drive (b0t0): RAID 1, 16896MB online Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: logical drive (b0t1): RAID 5, 207872MB online Jun 23 07:48:39 k11-dl380g3 kernel: pcib2: on acpi0 Jun 23 07:48:39 k11-dl380g3 kernel: pci2: on pcib2 Jun 23 07:48:39 k11-dl380g3 kernel: pci2: physical bus=3D2 Jun 23 07:48:39 k11-dl380g3 kernel: found-> vendor=3D0x14e4, dev=3D0x16a7, revid=3D0x02 Jun 23 07:48:39 k11-dl380g3 kernel: bus=3D2, slot=3D1, func=3D0 Jun 23 07:48:39 k11-dl380g3 kernel: class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 Jun 23 07:48:39 k11-dl380g3 kernel: cmdreg=3D0x0156, statreg=3D0x02b0, cachelnsz=3D16 (dwords) Jun 23 07:48:39 k11-dl380g3 kernel: lattimer=3D0x40 (1920 ns), mingnt=3D0x40 (16000 ns), maxlat=3D0x00 (0 ns) Jun 23 07:48:39 k11-dl380g3 kernel: intpin=3Da, irq=3D15 Jun 23 07:48:39 k11-dl380g3 kernel: powerspec 2 supports D0 D3 current D0 Jun 23 07:48:39 k11-dl380g3 kernel: MSI supports 8 messages, 64 bit Jun 23 07:48:39 k11-dl380g3 kernel: map[10]: type 1, range 64, base f05e0000, size 16, enabled Jun 23 07:48:39 k11-dl380g3 kernel: pcib2: matched entry for 2.2.INTA Jun 23 07:48:39 k11-dl380g3 kernel: pcib2: slot 2 INTA hardwired to IRQ 31 Jun 23 07:48:39 k11-dl380g3 kernel: bge0: mem 0xf05f0000-0xf05fffff ir q 29 at device 1.0 on pci2 Jun 23 07:48:39 k11-dl380g3 kernel: bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xf05f0000 Jun 23 07:48:39 k11-dl380g3 kernel: miibus0: on bge0 Jun 23 07:48:39 k11-dl380g3 kernel: brgphy0: on miibus0 Jun 23 07:48:39 k11-dl380g3 kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, au to Jun 23 07:48:39 k11-dl380g3 kernel: bge0: bpf attached Jun 23 07:48:39 k11-dl380g3 kernel: bge0: Ethernet address: 00:0e:7f:20:67:2f Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: routing intpin 13 (PCI IRQ 29) to vector 53 Jun 23 07:48:39 k11-dl380g3 kernel: bge0: [MPSAFE] Jun 23 07:48:39 k11-dl380g3 kernel: bge1: mem 0xf05e0000-0xf05effff ir q 31 at device 2.0 on pci2 Jun 23 07:48:39 k11-dl380g3 kernel: bge1: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xf05e0000 Jun 23 07:48:39 k11-dl380g3 kernel: miibus1: on bge1 Jun 23 07:48:39 k11-dl380g3 kernel: brgphy1: on miibus1 Jun 23 07:48:39 k11-dl380g3 kernel: brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, au to Jun 23 07:48:39 k11-dl380g3 kernel: bge1: bpf attached Jun 23 07:48:39 k11-dl380g3 kernel: bge1: Ethernet address: 00:0e:7f:20:67:2e Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: routing intpin 15 (PCI IRQ 31) to vector 54 Jun 23 07:48:39 k11-dl380g3 kernel: bge1: [MPSAFE] Jun 23 07:48:39 k11-dl380g3 kernel: pcib3: on acpi0 Jun 23 07:48:39 k11-dl380g3 kernel: pci3: on pcib3 Jun 23 07:48:39 k11-dl380g3 kernel: pci3: physical bus=3D3 Jun 23 07:48:39 k11-dl380g3 kernel: found-> vendor=3D0x8086, dev=3D0x1010, revid=3D0x01 Jun 23 07:48:39 k11-dl380g3 kernel: bus=3D3, slot=3D1, func=3D0 Jun 23 07:48:39 k11-dl380g3 kernel: class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 Jun 23 07:48:39 k11-dl380g3 kernel: cmdreg=3D0x0157, statreg=3D0x0230, cachelnsz=3D16 (dwords) Jun 23 07:48:39 k11-dl380g3 kernel: lattimer=3D0x40 (1920 ns), mingnt=3D0xff (63750 ns), maxlat=3D0x00 (0 ns) Jun 23 07:48:39 k11-dl380g3 kernel: intpin=3Da, irq=3D15 Jun 23 07:48:39 k11-dl380g3 kernel: powerspec 2 supports D0 D3 current D0 Jun 23 07:48:39 k11-dl380g3 kernel: MSI supports 1 message, 64 bit Jun 23 07:48:39 k11-dl380g3 kernel: map[10]: type 1, range 64, base f06e0000, size 17, enabled Jun 23 07:48:39 k11-dl380g3 kernel: map[18]: type 1, range 64, base f0680000, size 18, enabled Jun 23 07:48:39 k11-dl380g3 kernel: map[20]: type 4, range 32, base 00004000, size 6, enabled Jun 23 07:48:39 k11-dl380g3 kernel: pcib3: matched entry for 3.1.INTA Jun 23 07:48:39 k11-dl380g3 kernel: pcib3: slot 1 INTA hardwired to IRQ 20 Jun 23 07:48:39 k11-dl380g3 kernel: found-> vendor=3D0x8086, dev=3D0x1010, revid=3D0x01 Jun 23 07:48:39 k11-dl380g3 kernel: bus=3D3, slot=3D1, func=3D1 Jun 23 07:48:39 k11-dl380g3 kernel: class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 Jun 23 07:48:39 k11-dl380g3 kernel: cmdreg=3D0x0157, statreg=3D0x0230, cachelnsz=3D16 (dwords) Jun 23 07:48:39 k11-dl380g3 kernel: lattimer=3D0x40 (1920 ns), mingnt=3D0xff (63750 ns), maxlat=3D0x00 (0 ns) Jun 23 07:48:39 k11-dl380g3 kernel: intpin=3Db, irq=3D11 Jun 23 07:48:39 k11-dl380g3 kernel: powerspec 2 supports D0 D3 current D0 Jun 23 07:48:39 k11-dl380g3 kernel: MSI supports 1 message, 64 bit Jun 23 07:48:39 k11-dl380g3 kernel: map[10]: type 1, range 64, base f0660000, size 17, enabled Jun 23 07:48:39 k11-dl380g3 kernel: map[20]: type 4, range 32, base 00004040, size 6, enabled Jun 23 07:48:39 k11-dl380g3 kernel: pcib3: matched entry for 3.1.INTBJun 23 07:48:39 k11-dl380g3 kernel: pcib3: slot 1 INTB hardwired to IRQ 21 Jun 23 07:48:39 k11-dl380g3 kernel: em0: port 0x4000-0x403f mem 0xf0 6e0000-0xf06fffff,0xf0680000-0xf06bffff irq 20 at device 1.0 on pci3 Jun 23 07:48:39 k11-dl380g3 kernel: em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xf06e0000 Jun 23 07:48:39 k11-dl380g3 kernel: em0: Reserved 0x40 bytes for rid 0x20 type 4 at 0x4000 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: routing intpin 4 (PCI IRQ 20) to vector 55 Jun 23 07:48:39 k11-dl380g3 kernel: em0: [MPSAFE] Jun 23 07:48:39 k11-dl380g3 kernel: em0: bpf attached Jun 23 07:48:39 k11-dl380g3 kernel: em0: Ethernet address: 00:02:a5:48:46:66 Jun 23 07:48:39 k11-dl380g3 kernel: em0: Speed:N/A Duplex:N/A Jun 23 07:48:39 k11-dl380g3 kernel: em1: port 0x4040-0x407f mem 0xf0 660000-0xf067ffff irq 21 at device 1.1 on pci3 Jun 23 07:48:39 k11-dl380g3 kernel: em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xf0660000 Jun 23 07:48:39 k11-dl380g3 kernel: em1: Reserved 0x40 bytes for rid 0x20 type 4 at 0x4040 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: routing intpin 5 (PCI IRQ 21) to vector 56 Jun 23 07:48:39 k11-dl380g3 kernel: em1: [MPSAFE] Jun 23 07:48:39 k11-dl380g3 kernel: em1: bpf attached Jun 23 07:48:39 k11-dl380g3 kernel: em1: Ethernet address: 00:02:a5:48:46:67 Jun 23 07:48:39 k11-dl380g3 kernel: em1: Speed:N/A Duplex:N/A Jun 23 07:48:39 k11-dl380g3 kernel: pcib4: on acpi0 Jun 23 07:48:39 k11-dl380g3 kernel: pci6: on pcib4 Jun 23 07:48:39 k11-dl380g3 kernel: pci6: physical bus=3D6 Jun 23 07:48:39 k11-dl380g3 kernel: found-> vendor=3D0x0e11, dev=3D0xa0f7, revid=3D0x14 Jun 23 07:48:39 k11-dl380g3 kernel: bus=3D6, slot=3D30, func=3D0 Jun 23 07:48:39 k11-dl380g3 kernel: class=3D08-04-00, hdrtype=3D0x00, mfdev=3D0 Jun 23 07:48:39 k11-dl380g3 kernel: cmdreg=3D0x0142, statreg=3D0x0430, cachelnsz=3D0 (dwords) Jun 23 07:48:39 k11-dl380g3 kernel: lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) Jun 23 07:48:39 k11-dl380g3 kernel: intpin=3Da, irq=3D7 Jun 23 07:48:39 k11-dl380g3 kernel: powerspec 2 supports D0 D3 current D0 Jun 23 07:48:39 k11-dl380g3 kernel: MSI supports 1 message, 64 bit Jun 23 07:48:39 k11-dl380g3 kernel: map[10]: type 1, range 32, base f7ff0000, size 12, enabled Jun 23 07:48:39 k11-dl380g3 kernel: pcib4: matched entry for 6.30.INTA Jun 23 07:48:39 k11-dl380g3 kernel: pcib4: slot 30 INTA hardwired to IRQ 18 Jun 23 07:48:39 k11-dl380g3 kernel: pci6: at device 30.0 (no driver attached) Jun 23 07:48:39 k11-dl380g3 kernel: acpi_tz0: on acpi0 Jun 23 07:48:39 k11-dl380g3 kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jun 23 07:48:39 k11-dl380g3 kernel: atkbd0: irq 1 on atkbdc0 Jun 23 07:48:39 k11-dl380g3 kernel: atkbd: the current kbd controller command byte 0065 Jun 23 07:48:39 k11-dl380g3 kernel: atkbd: keyboard ID 0x41ab (2) Jun 23 07:48:39 k11-dl380g3 kernel: kbd0 at atkbd0 Jun 23 07:48:39 k11-dl380g3 kernel: kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: routing intpin 1 (ISA IRQ 1) to vector 57 Jun 23 07:48:39 k11-dl380g3 kernel: atkbd0: [GIANT-LOCKED] Jun 23 07:48:39 k11-dl380g3 kernel: psm0: unable to allocate IRQ Jun 23 07:48:39 k11-dl380g3 kernel: psmcpnp0: irq 12 on acpi0 Jun 23 07:48:39 k11-dl380g3 kernel: psm0: current command byte:0065 Jun 23 07:48:39 k11-dl380g3 kernel: psm0: irq 12 on atkbdc0 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: routing intpin 12 (ISA IRQ 12) to vector 58 Jun 23 07:48:39 k11-dl380g3 kernel: psm0: [GIANT-LOCKED] Jun 23 07:48:39 k11-dl380g3 kernel: psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons Jun 23 07:48:39 k11-dl380g3 kernel: psm0: config:00000000, flags:00000008, packet size:3 Jun 23 07:48:39 k11-dl380g3 kernel: psm0: syncmask:c0, syncbits:00 Jun 23 07:48:39 k11-dl380g3 kernel: sio0: irq maps: 0x1 0x11 0x1 0x1 Jun 23 07:48:39 k11-dl380g3 kernel: sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jun 23 07:48:39 k11-dl380g3 kernel: sio0: type 16550A Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: routing intpin 4 (ISA IRQ 4) to vector 59 Jun 23 07:48:39 k11-dl380g3 kernel: fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on acpi0 Jun 23 07:48:39 k11-dl380g3 kernel: fdc0: ic_type 90 part_id 73 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: routing intpin 6 (ISA IRQ 6) to vector 60 Jun 23 07:48:39 k11-dl380g3 kernel: fdc0: [MPSAFE] Jun 23 07:48:39 k11-dl380g3 kernel: fdc0: [FAST] Jun 23 07:48:39 k11-dl380g3 kernel: fd0: <1440-KB 3.5" drive> on fdc0 drive 0 Jun 23 07:48:39 k11-dl380g3 kernel: ex_isa_identify() Jun 23 07:48:39 k11-dl380g3 kernel: ata: ata0 already exists; skipping it Jun 23 07:48:39 k11-dl380g3 kernel: ata: ata1 already exists; skipping it Jun 23 07:48:39 k11-dl380g3 kernel: atkbdc: atkbdc0 already exists; skipping it Jun 23 07:48:39 k11-dl380g3 kernel: fdc: fdc0 already exists; skipping it Jun 23 07:48:39 k11-dl380g3 kernel: sio: sio0 already exists; skipping it Jun 23 07:48:39 k11-dl380g3 kernel: pnp_identify: Trying Read_Port at 203 Jun 23 07:48:39 k11-dl380g3 kernel: pnp_identify: Trying Read_Port at 243 Jun 23 07:48:39 k11-dl380g3 kernel: pnp_identify: Trying Read_Port at 283 Jun 23 07:48:39 k11-dl380g3 kernel: pnp_identify: Trying Read_Port at 2c3 Jun 23 07:48:39 k11-dl380g3 kernel: pnp_identify: Trying Read_Port at 303 Jun 23 07:48:39 k11-dl380g3 kernel: pnp_identify: Trying Read_Port at 343 Jun 23 07:48:39 k11-dl380g3 kernel: pnp_identify: Trying Read_Port at 383 Jun 23 07:48:39 k11-dl380g3 kernel: pnp_identify: Trying Read_Port at 3c3 Jun 23 07:48:39 k11-dl380g3 kernel: PNP Identify complete Jun 23 07:48:39 k11-dl380g3 kernel: unknown: status reg test failed ff Jun 23 07:48:39 k11-dl380g3 last message repeated 3 times Jun 23 07:48:39 k11-dl380g3 kernel: ahc_isa_probe 0: ioport 0xc00 alloc failed Jun 23 07:48:39 k11-dl380g3 kernel: sc: sc0 already exists; skipping it Jun 23 07:48:39 k11-dl380g3 kernel: vga: vga0 already exists; skipping it Jun 23 07:48:39 k11-dl380g3 kernel: isa_probe_children: disabling PnP devices Jun 23 07:48:39 k11-dl380g3 kernel: isa_probe_children: probing non-PnP devices Jun 23 07:48:39 k11-dl380g3 kernel: pmtimer0 on isa0 Jun 23 07:48:39 k11-dl380g3 kernel: orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff,0xcc000-0xcd7ff,0xcd800 -0xcefff,0xee000-0xeffff on isa0 Jun 23 07:48:39 k11-dl380g3 kernel: adv0: not probed (disabled) Jun 23 07:48:39 k11-dl380g3 kernel: aha0: not probed (disabled) Jun 23 07:48:39 k11-dl380g3 kernel: aic0: not probed (disabled) Jun 23 07:48:39 k11-dl380g3 kernel: bt0: not probed (disabled) Jun 23 07:48:39 k11-dl380g3 kernel: cs0: not probed (disabled) Jun 23 07:48:39 k11-dl380g3 kernel: ed0: not probed (disabled) Jun 23 07:48:39 k11-dl380g3 kernel: fe0: not probed (disabled) Jun 23 07:48:39 k11-dl380g3 kernel: ie0: not probed (disabled) Jun 23 07:48:39 k11-dl380g3 kernel: lnc0: not probed (disabled) Jun 23 07:48:39 k11-dl380g3 kernel: ppc0: parallel port not found. Jun 23 07:48:39 k11-dl380g3 kernel: ppc0: failed to probe at irq 7 on isa0 Jun 23 07:48:39 k11-dl380g3 kernel: sc0: at flags 0x100 on isa0 Jun 23 07:48:39 k11-dl380g3 kernel: sc0: VGA <16 virtual consoles, flags=3D0x300> Jun 23 07:48:39 k11-dl380g3 kernel: sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) Jun 23 07:48:39 k11-dl380g3 kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Jun 23 07:48:39 k11-dl380g3 kernel: sio1: port may not be enabled Jun 23 07:48:39 k11-dl380g3 kernel: sio1: irq maps: 0x41 0x41 0x41 0x41 Jun 23 07:48:39 k11-dl380g3 kernel: sio1: probe failed test(s): 0 1 2 4 6 7 9 Jun 23 07:48:39 k11-dl380g3 kernel: sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 Jun 23 07:48:39 k11-dl380g3 kernel: sio2: not probed (disabled) Jun 23 07:48:39 k11-dl380g3 kernel: sio3: not probed (disabled) Jun 23 07:48:39 k11-dl380g3 kernel: sn0: not probed (disabled) Jun 23 07:48:39 k11-dl380g3 kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jun 23 07:48:39 k11-dl380g3 kernel: vt0: not probed (disabled) Jun 23 07:48:39 k11-dl380g3 kernel: isa_probe_children: probing PnP devices Jun 23 07:48:39 k11-dl380g3 kernel: Device configuration finished. Jun 23 07:48:39 k11-dl380g3 kernel: procfs registered Jun 23 07:48:39 k11-dl380g3 kernel: lapic: Divisor 2, Frequency 66476404 hz Jun 23 07:48:39 k11-dl380g3 kernel: Timecounter "TSC" frequency 3057871256 Hz quality -100 Jun 23 07:48:39 k11-dl380g3 kernel: Timecounters tick every 1.000 msec Jun 23 07:48:39 k11-dl380g3 kernel: lo0: bpf attached Jun 23 07:48:39 k11-dl380g3 kernel: rr232x: no controller detected. Jun 23 07:48:39 k11-dl380g3 kernel: ata0-master: pio=3DPIO4 wdma=3DUNSUPPORTED udma=3DUNSUPPORTED cable=3D40 wire Jun 23 07:48:39 k11-dl380g3 kernel: acd0: setting PIO4 on CSB5 chip Jun 23 07:48:39 k11-dl380g3 kernel: fdc0: output ready timeout Jun 23 07:48:39 k11-dl380g3 last message repeated 6 times Jun 23 07:48:39 k11-dl380g3 kernel: acd0: CDROM drive at ata0 as master Jun 23 07:48:39 k11-dl380g3 kernel: acd0: read 4134KB/s (4134KB/s), 128KB buffer, PIO4 Jun 23 07:48:39 k11-dl380g3 kernel: acd0: Reads: CDR, CDRW, CDDA stream, packet Jun 23 07:48:39 k11-dl380g3 kernel: acd0: Writes: Jun 23 07:48:39 k11-dl380g3 kernel: acd0: Audio: play, 255 volume levels Jun 23 07:48:39 k11-dl380g3 kernel: acd0: Mechanism: ejectable tray, unlocked Jun 23 07:48:39 k11-dl380g3 kernel: acd0: Medium: no/blank disc Jun 23 07:48:39 k11-dl380g3 kernel: fdc0: output ready timeout Jun 23 07:48:39 k11-dl380g3 kernel: fdc0: input ready timeout Jun 23 07:48:39 k11-dl380g3 kernel: fdc0: input ready timeout Jun 23 07:48:39 k11-dl380g3 kernel: fdc0: output ready timeout Jun 23 07:48:39 k11-dl380g3 kernel: fdc0: input ready timeout Jun 23 07:48:39 k11-dl380g3 kernel: fdc0: input ready timeout Jun 23 07:48:39 k11-dl380g3 kernel: fdc0: output ready timeout Jun 23 07:48:39 k11-dl380g3 kernel: fdc0: input ready timeout Jun 23 07:48:39 k11-dl380g3 kernel: fdc0: input ready timeout Jun 23 07:48:39 k11-dl380g3 kernel: fdc0: output ready timeout Jun 23 07:48:39 k11-dl380g3 kernel: fdc0: input ready timeout Jun 23 07:48:39 k11-dl380g3 kernel: fdc0: input ready timeout Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: command status 0x1 (target status) scsi status 0x2 Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: command status 0x1 (target status) scsi status 0x2 Jun 23 07:48:39 k11-dl380g3 kernel: (probe0:ciss0:0:0:0): error 22 Jun 23 07:48:39 k11-dl380g3 kernel: (probe0:ciss0:0:0:0): Unretryable Error Jun 23 07:48:39 k11-dl380g3 kernel: (probe1:ciss0:0:1:0): error 22 Jun 23 07:48:39 k11-dl380g3 kernel: (probe1:ciss0:0:1:0): Unretryable Error Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: command status 0x1 (target status) scsi status 0x2 Jun 23 07:48:39 k11-dl380g3 kernel: ciss0: command status 0x1 (target status) scsi status 0x2 Jun 23 07:48:39 k11-dl380g3 kernel: (probe0:ciss0:0:0:0): error 22 Jun 23 07:48:39 k11-dl380g3 kernel: (probe0:ciss0:0:0:0): Unretryable Error Jun 23 07:48:39 k11-dl380g3 kernel: (probe1:ciss0:0:1:0): error 22 Jun 23 07:48:39 k11-dl380g3 kernel: (probe1:ciss0:0:1:0): Unretryable Error Jun 23 07:48:39 k11-dl380g3 kernel: pass0 at ciss0 bus 0 target 0 lun 0 Jun 23 07:48:39 k11-dl380g3 kernel: pass0: Fixed Direct Access SCSI-0 device Jun 23 07:48:39 k11-dl380g3 kernel: pass0: 135.168MB/s transfers Jun 23 07:48:39 k11-dl380g3 kernel: pass1 at ciss0 bus 0 target 1 lun 0 Jun 23 07:48:39 k11-dl380g3 kernel: pass1: Fixed Direct Access SCSI-0 device Jun 23 07:48:39 k11-dl380g3 kernel: pass1: 135.168MB/s transfers Jun 23 07:48:39 k11-dl380g3 kernel: ATA PseudoRAID loaded Jun 23 07:48:39 k11-dl380g3 kernel: SMP: AP CPU #2 Launched! Jun 23 07:48:39 k11-dl380g3 kernel: cpu2 AP: Jun 23 07:48:39 k11-dl380g3 kernel: ID: 0x06000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff Jun 23 07:48:39 k11-dl380g3 kernel: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ffJun 23 07:48:39 k11-dl380g3 kernel: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff Jun 23 07:48:39 k11-dl380g3 kernel: timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 Jun 23 07:48:39 k11-dl380g3 kernel: INTR: Assigning IRQ 1 to local APIC 0 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: Assigning ISA IRQ 1 to local APIC 0 Jun 23 07:48:39 k11-dl380g3 kernel: INTR: Assigning IRQ 4 to local APIC 6 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: Assigning ISA IRQ 4 to local APIC 6 Jun 23 07:48:39 k11-dl380g3 kernel: INTR: Assigning IRQ 6 to local APIC 0 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: Assigning ISA IRQ 6 to local APIC 0 Jun 23 07:48:39 k11-dl380g3 kernel: INTR: Assigning IRQ 7 to local APIC 6 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: Assigning ISA IRQ 7 to local APIC 6 Jun 23 07:48:39 k11-dl380g3 kernel: INTR: Assigning IRQ 9 to local APIC 0 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: Assigning ISA IRQ 9 to local APIC 0 Jun 23 07:48:39 k11-dl380g3 kernel: INTR: Assigning IRQ 12 to local APIC 6 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: Assigning ISA IRQ 12 to local APIC 6 Jun 23 07:48:39 k11-dl380g3 kernel: INTR: Assigning IRQ 14 to local APIC 0 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: Assigning ISA IRQ 14 to local APIC 0 Jun 23 07:48:39 k11-dl380g3 kernel: INTR: Assigning IRQ 15 to local APIC 6 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic0: Assigning ISA IRQ 15 to local APIC 6 Jun 23 07:48:39 k11-dl380g3 kernel: INTR: Assigning IRQ 20 to local APIC 0 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: Assigning PCI IRQ 20 to local APIC 0 Jun 23 07:48:39 k11-dl380g3 kernel: INTR: Assigning IRQ 21 to local APIC 6 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: Assigning PCI IRQ 21 to local APIC 6 Jun 23 07:48:39 k11-dl380g3 kernel: INTR: Assigning IRQ 29 to local APIC 0 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: Assigning PCI IRQ 29 to local APIC 0 Jun 23 07:48:39 k11-dl380g3 kernel: INTR: Assigning IRQ 30 to local APIC 6 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: Assigning PCI IRQ 30 to local APIC 6 Jun 23 07:48:39 k11-dl380g3 kernel: INTR: Assigning IRQ 31 to local APIC 0 Jun 23 07:48:39 k11-dl380g3 kernel: ioapic1: Assigning PCI IRQ 31 to local APIC 0 Jun 23 07:48:39 k11-dl380g3 kernel: da0 at ciss0 bus 0 target 0 lun 0 Jun 23 07:48:39 k11-dl380g3 kernel: da0: Fixed Direct Access SCSI-0 device Jun 23 07:48:39 k11-dl380g3 kernel: da0: 135.168MB/s transfers Jun 23 07:48:39 k11-dl380g3 kernel: da0: 17359MB (35553120 512 byte sectors: 255H 32S/T 4357C) Jun 23 07:48:39 k11-dl380g3 kernel: da1 at ciss0 bus 0 target 1 lun 0 Jun 23 07:48:39 k11-dl380g3 kernel: da1: Fixed Direct Access SCSI-0 device Jun 23 07:48:39 k11-dl380g3 kernel: da1: 135.168MB/s transfers Jun 23 07:48:39 k11-dl380g3 kernel: da1: 208378MB (426759840 512 byte sectors: 255H 32S/T 52299C) Jun 23 07:48:39 k11-dl380g3 kernel: GEOM: new disk da0 Jun 23 07:48:39 k11-dl380g3 kernel: GEOM: new disk da1 Jun 23 07:48:39 k11-dl380g3 kernel: Trying to mount root from ufs:/dev/da0s1a Jun 23 07:48:39 k11-dl380g3 kernel: start_init: trying /sbin/init Jun 23 07:48:39 k11-dl380g3 kernel: Linux ELF exec handler installed Jun 23 07:48:41 k11-dl380g3 kernel: bge0: link UP Jun 23 07:48:41 k11-dl380g3 kernel: bge0: link state changed to UP Jun 23 07:48:41 k11-dl380g3 kernel: Jun 23 07:48:39 k11-dl380g3 kernel: timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 Jun 23 07:48:39 k11-dl380g3 kernel: SMP: AP CPU #1 Launched! Jun 23 07:48:39 k11-dl380g3 kernel: cpu1 AP: Jun 23 07:48:39 k11-dl380g3 kernel: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff Jun 23 07:48:39 k11-dl380g3 kernel: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff Jun 23 07:48:39 k11-dl380g3 kernel: timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 Jun 23 07:48:39 k11-dl380g3 kernel: SMP: AP CPU #3 Launched! Jun 23 07:48:39 k11-dl380g3 kernel: cpu3 AP: Jun 23 07:48:39 k11-dl380g3 kernel: ID: 0x07000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff Jun 23 07:48:39 k11-dl380g3 kernel: intpin=3Da, irq=3D3 Jun 23 07:48:39 k11-dl380g3 kernel: powerspec 2 supports D0 D3 current D0 Jun 23 07:48:39 k11-dl380g3 kernel: map[10]: type 4, range 32, base 00001800, size 8, enabled Jun 23 07:48:39 k11-dl380g3 kernel: map[14]: type 1, range 32, base eefe0000, size 9, enabled Jun 23 07:48:39 k11-dl380g3 kernel: pcib0: matched entry for 0.4.INTA Jun 23 07:48:39 k11-dl380g3 kernel: pcib0: slot 4 INTA hardwired to IRQ 16 Jun 23 07:48:39 k11-dl380g3 kernel: found-> vendor=3D0x0e11, dev=3D0xb204, revid=3D0x01 Jun 23 07:48:39 k11-dl380g3 kernel: bus=3D0, slot=3D4, func=3D2 Jun 23 07:48:39 k11-dl380g3 kernel: class=3D08-80-00, hdrtype=3D0x00, mfdev=3D1 Jun 23 07:48:39 k11-dl380g3 kernel: cmdreg=3D0x0197, statreg=3D0x0290, cachelnsz=3D16 (dwords) Jun 23 07:48:39 k11-dl380g3 kernel: lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) Jun 23 07:48:39 k11-dl380g3 kernel: intpin=3Db, irq=3D5 Jun 23 07:48:39 k11-dl380g3 kernel: powerspec 2 supports D0 D3 current D0 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link19: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link19: Links after disable: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: ACPI timer: 0/3 1/2 0/3 0/3 0/5 0/5 0/6 0/5 0/5 0/5 -> 1 Jun 23 07:48:39 k11-dl380g3 kernel: Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 Jun 23 07:48:39 k11-dl380g3 kernel: acpi_timer0: <32-bit timer at 3.579545MHz> port 0x920-0x923 on acpi0 Jun 23 07:48:39 k11-dl380g3 kernel: cpu0: on acpi0 Jun 23 07:48:39 k11-dl380g3 kernel: cpu1: on acpi0 Jun 23 07:48:39 k11-dl380g3 kernel: cpu2: on acpi0 Jun 23 07:48:39 k11-dl380g3 kernel: cpu3: on acpi0 Jun 23 07:48:39 k11-dl380g3 kernel: pcib0: on acpi0 Jun 23 07:48:39 k11-dl380g3 kernel: ACPI: Found matching pin for 0.15.INTA at func 2: 7 Jun 23 07:48:39 k11-dl380g3 kernel: 0 11 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link14: Links after disable: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link15: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 10 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link15: Links after initial validation: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 10 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link15: Links after disable: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link16: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs Jun 23 07:48:39 k11-dl380g3 kernel: 0 255 N 0 4 5 7 10 11 15 Jun 23 07:48:39 k11-dl380g3 kernel: pci_link11: Links after initial probe: Jun 23 07:48:39 k11-dl380g3 kernel: Index IRQ Rtd Ref IRQs To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d. From owner-freebsd-geom@FreeBSD.ORG Fri Jun 23 15:20:28 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D82116A47E; Fri, 23 Jun 2006 15:20:28 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00E0543D46; Fri, 23 Jun 2006 15:20:27 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id k5NFKQtN079480; Fri, 23 Jun 2006 10:20:27 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <449C06C6.9070801@centtech.com> Date: Fri, 23 Jun 2006 10:20:38 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20060619131101.GD1130@garage.freebsd.pl> In-Reply-To: <20060619131101.GD1130@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1562/Fri Jun 23 02:50:07 2006 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 15:20:28 -0000 Pawel Jakub Dawidek wrote: > Hello. > > For the last few months I have been working on gjournal project. > To stop confusion right here, I want to note, that this project is not > related to gjournal project on which Ivan Voras was working on the > last SoC (2005). > > The lack of journaled file system in FreeBSD was a tendon of achilles > for many years. We do have many file systems, but none with journaling: > - ext2fs (journaling is in ext3fs), > - XFS (read-only), > - ReiserFS (read-only), > - HFS+ (read-write, but without journaling), > - NTFS (read-only). > > GJournal was designed to journal GEOM providers, so it actually works > below file system layer, but it has hooks which allow to work with > file systems. In other words, gjournal is not file system-depended, > it can work probably with any file system with minimum knowledge > about it. I implemented only UFS support. > > The patches are here: > > http://people.freebsd.org/~pjd/patches/gjournal.patch (for HEAD) > http://people.freebsd.org/~pjd/patches/gjournal6.patch (for RELENG_6) > > To patch your sources you need to: > > # cd /usr/src > # mkdir sbin/geom/class/journal sys/geom/journal sys/modules/geom/geom_journal > # patch < /path/to/gjournal.patch > > Add 'options UFS_GJOURNAL' to your kernel configuration file and > recompile kernel and world. > > How it works (in short). You may define one or two providers which > gjournal will use. If one provider is given, it will be used for both - > data and journal. If two providers are given, one will be used for data > and one for journal. > Every few seconds (you may define how many) journal is terminated and > marked as consistent and gjournal starts to copy data from it to the > data provider. In the same time new data are stored in new journal. I'm not sure this is happening the way you describe exactly. On my laptop, while rsyncing my /home partition to a newly created external disk (400G), I see 20MB/s writing to the journaled UFS2 device (/dev/label/backup.journal) passing through to the journal device (/dev/label/journal), then it switches to no writes to the journaled UFS2 device (/dev/label/backup.journal) (my rsync pauses) while the journaled device (/dev/label/backup) writes at 20MB/s for about 3-10 seconds. > Let's call the moment in which journal is terminated as "journal switch". > Journal switch looks as follows: > 1. Start journal switch if we have timeout or if we run out of cache. > Don't perform journal switch if there were no write requests. > 2. If we have file system, synchronize it. > 3. Mark file system as clean. > 4. Block all write requests to the file system. > 5. Terminate the journal. > 6. Eventually wait if copying of the previous journal is not yet > finished. Seems like this is the point we are busy in. > 7. Send BIO_FLUSH request (if the given provider supports it). > 8. Mark new journal position on the journal provider. > 9. Unblock write requests. > 10. Start copying data from the terminated journal to the data provider. And it seems that 10 is happening earlier on.. Is this all expected behaviour? Thanks for the great work, and fantastic GEOM tools! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-geom@FreeBSD.ORG Fri Jun 23 19:42:24 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90E2F16A494; Fri, 23 Jun 2006 19:42:24 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C39D43D8A; Fri, 23 Jun 2006 19:41:44 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 8F4C55131F; Fri, 23 Jun 2006 21:41:42 +0200 (CEST) Received: from localhost (dlk232.neoplus.adsl.tpnet.pl [83.24.40.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 0634E50EA7; Fri, 23 Jun 2006 21:41:36 +0200 (CEST) Date: Fri, 23 Jun 2006 21:38:57 +0200 From: Pawel Jakub Dawidek To: Eric Anderson Message-ID: <20060623193857.GC40269@garage.freebsd.pl> References: <20060619131101.GD1130@garage.freebsd.pl> <449C06C6.9070801@centtech.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XWOWbaMNXpFDWE00" Content-Disposition: inline In-Reply-To: <449C06C6.9070801@centtech.com> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 19:42:24 -0000 --XWOWbaMNXpFDWE00 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 23, 2006 at 10:20:38AM -0500, Eric Anderson wrote: +> Pawel Jakub Dawidek wrote: +> >Hello. +> >For the last few months I have been working on gjournal project. +> >To stop confusion right here, I want to note, that this project is not +> >related to gjournal project on which Ivan Voras was working on the +> >last SoC (2005). +> >The lack of journaled file system in FreeBSD was a tendon of achilles +> >for many years. We do have many file systems, but none with journaling: +> >- ext2fs (journaling is in ext3fs), +> >- XFS (read-only), +> >- ReiserFS (read-only), +> >- HFS+ (read-write, but without journaling), +> >- NTFS (read-only). +> >GJournal was designed to journal GEOM providers, so it actually works +> >below file system layer, but it has hooks which allow to work with +> >file systems. In other words, gjournal is not file system-depended, +> >it can work probably with any file system with minimum knowledge +> >about it. I implemented only UFS support. +> >The patches are here: +> > http://people.freebsd.org/~pjd/patches/gjournal.patch (for HEAD) +> > http://people.freebsd.org/~pjd/patches/gjournal6.patch (for RELENG_6) +> >To patch your sources you need to: +> > # cd /usr/src +> > # mkdir sbin/geom/class/journal sys/geom/journal sys/modules/geom/geom= _journal +> > # patch < /path/to/gjournal.patch +> >Add 'options UFS_GJOURNAL' to your kernel configuration file and +> >recompile kernel and world. +> >How it works (in short). You may define one or two providers which +> >gjournal will use. If one provider is given, it will be used for both - +> >data and journal. If two providers are given, one will be used for data +> >and one for journal. +> >Every few seconds (you may define how many) journal is terminated and +> >marked as consistent and gjournal starts to copy data from it to the +> >data provider. In the same time new data are stored in new journal. +>=20 +> I'm not sure this is happening the way you describe exactly. On my lapt= op, while rsyncing my /home partition to a newly created external disk (400= G), I see 20MB/s writing=20 +> to the journaled UFS2 device (/dev/label/backup.journal) passing through= to the journal device (/dev/label/journal), then it switches to no writes = to the journaled UFS2=20 +> device (/dev/label/backup.journal) (my rsync pauses) while the journaled= device (/dev/label/backup) writes at 20MB/s for about 3-10 seconds. When it is time for journal switch, we cannot switch the journals if we still copy data from the inactive journal, so we wait then. You can tune it a bit using those two sysctls: kern.geom.journal.parallel_flushes - Number of flush I/O requests send in parallel kern.geom.journal.parallel_copies - Number of copy I/O requests send in parallel By default those are equal, you may increase the second one or decrease the first one to tell gjournal to focus more on copying the data from the inactive journal, so when journal switch time arrives, it doesn't have to wait. Before you do it, please consult kern.geom.journal.stats.wait_for_copy sysctl variable, which will tell you how many times journal switch was delayed because of inactive journal not beeing fully copied. More waiting is because a lot of data is only in memory and when I call file system synchronization all the data go to gjournal provider. All modes in which UFS can operate are not optimal for gjournal - I mean here sync, async and SU. The most optimal mode for gjournal will be something like: send write request immediatelly and don't wait for an answer. GJournal will take care of reordering write request to get optimal throughput and this will allow for more balanced load. For example SU send write requests in picks, which is bad for gjournal. +> >Let's call the moment in which journal is terminated as "journal switch= ". +> >Journal switch looks as follows: +> >1. Start journal switch if we have timeout or if we run out of cache. +> > Don't perform journal switch if there were no write requests. +> >2. If we have file system, synchronize it. +> >3. Mark file system as clean. +> >4. Block all write requests to the file system. +> >5. Terminate the journal. +> >6. Eventually wait if copying of the previous journal is not yet +> > finished. +>=20 +> Seems like this is the point we are busy in. +>=20 +> >7. Send BIO_FLUSH request (if the given provider supports it). +> >8. Mark new journal position on the journal provider. +> >9. Unblock write requests. +> >10. Start copying data from the terminated journal to the data provider. +>=20 +> And it seems that 10 is happening earlier on.. The point number 10 is actually after the journal switch. It is when the active journal was turned into an inactive journal and the copy starts. Don't take this order to strict, I more wanted to show what steps are performed. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --XWOWbaMNXpFDWE00 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEnENRForvXbEpPzQRAl+vAKC1c+ophEYLProOjQ1373BDyoaFKwCdH15u Gb6918+pzKh34atzxPrxhnQ= =opPZ -----END PGP SIGNATURE----- --XWOWbaMNXpFDWE00-- From owner-freebsd-geom@FreeBSD.ORG Fri Jun 23 19:49:26 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1B7316A47B; Fri, 23 Jun 2006 19:49:25 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43AC943D4C; Fri, 23 Jun 2006 19:49:24 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail05.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k5NJnJU0018458 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 24 Jun 2006 05:49:19 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k5NJnJqi003289; Sat, 24 Jun 2006 05:49:19 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k5NJnIIQ003288; Sat, 24 Jun 2006 05:49:18 +1000 (EST) (envelope-from peter) Date: Sat, 24 Jun 2006 05:49:18 +1000 From: Peter Jeremy To: "R. B. Riddick" Message-ID: <20060623194917.GB747@turion.vk2pj.dyndns.org> References: <20060623082209.GD13474@nevermind.kiev.ua> <20060623083838.86539.qmail@web30308.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <20060623083838.86539.qmail@web30308.mail.mud.yahoo.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-fs@freebsd.org, Alexandr Kovalenko , freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Journaling UFS with gjournal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 19:49:26 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 2006-Jun-23 01:38:38 -0700, R. B. Riddick wrote: >--- Alexandr Kovalenko wrote: >> Is it safe to do so on existing filesystem (if I'm using 2nd partition f= or >> journal)? =2E.. >If your existing file system needs its last sector, then it wont work. If = it >does not need it, then it might work (although fsck does not check for a >raw-device shrinkage - I think)... In my experience, the last partition in a disk slice normally has an odd number of sectors and UFS definitely can't handle anything smaller than a fragment (which defaults to 2K) - and I suspect that UFS can't handle a trailing fragment. In this case, the last sector is definitely unused. I may be wrong but I don't think it's possible for the last sector of a partition to be FS metadata because the metadata is always at the beginning of a CG and newfs won't create a CG unless there's some space for data in the CG. If there are an integral number of fragments (or maybe blocks), then marking the last fragment as 'bad' would seem an adequate solution - the FS will ignore that block but anything below the filesystem won't see the "bad block" marker. --=20 Peter Jeremy --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEnEW8/opHv/APuIcRAjoPAJ0f90leQiv+V3Xu4VpYvnBMZT+XwQCfZIQc A3v0WxoDBaIt5pM5omNJN58= =aq1w -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD--