From owner-freebsd-fs@FreeBSD.ORG Sun Apr 15 11:20:24 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8747416A400 for ; Sun, 15 Apr 2007 11:20: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 D637213C44C for ; Sun, 15 Apr 2007 11:20:23 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id AA091456AB; Sun, 15 Apr 2007 13:20:21 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 4780E45685; Sun, 15 Apr 2007 13:20:16 +0200 (CEST) Date: Sun, 15 Apr 2007 13:19:55 +0200 From: Pawel Jakub Dawidek To: Barry Pederson Message-ID: <20070415111955.GB16971@garage.freebsd.pl> References: <46205338.3090803@barryp.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eJnRUKwClWJh1Khz" Content-Disposition: inline In-Reply-To: <46205338.3090803@barryp.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=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS raidz device replacement problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 11:20:24 -0000 --eJnRUKwClWJh1Khz Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 13, 2007 at 11:06:16PM -0500, Barry Pederson wrote: > I've been playing with ZFS (awesome stuff, thanks PJD) and noticed someth= ing funny when replacing a device under a raidz pool. It seems that even t= hough ZFS says=20 > resilvering is complete, you still need to manually do a "zpool scrub" to= really get the pool into a good state. How do you tell it's not in a good state? > From what I've read in the "Solaris ZFS Administration Guide", it doesn't= seem that that step should be required. Is there some kind of auto-scrub = being missed? >=20 > I've tried to show this below with some md devices, creating 4 of them, p= utting 3 into a raidz and then replacing one. This is with a world and ker= nel csupped and built=20 > earlier today (2007-04-13) [...] > # zpool create mypool raidz md0 md1 md2 [...] > # zpool replace mypool md2 md3 [...] > # zpool status mypool > pool: mypool > state: ONLINE > scrub: resilver completed with 0 errors on Fri Apr 13 22:43:19 2007 > config: >=20 > NAME STATE READ WRITE CKSUM > mypool ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > md0 ONLINE 0 0 0 > md1 ONLINE 0 0 0 > replacing ONLINE 0 0 0 > md2 ONLINE 0 0 0 > md3 ONLINE 0 0 0 Do you mean that resilver is completed, but it is still replacing? ZFS resilvers only live data, those md's was free, so it completed immediately. > # zpool status mypool > pool: mypool > state: ONLINE > scrub: resilver completed with 0 errors on Fri Apr 13 22:43:19 2007 > config: >=20 > NAME STATE READ WRITE CKSUM > mypool ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > md0 ONLINE 0 0 0 > md1 ONLINE 0 0 0 > md3 ONLINE 0 0 0 It looks everything is fine. What's wrong? > # zpool scrub mypool >=20 > # zpool status mypool > pool: mypool > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are unaffect= ed. > action: Determine if the device needs to be replaced, and clear the errors > using 'zpool clear' or replace the device with 'zpool replace'. > see: http://www.sun.com/msg/ZFS-8000-9P > scrub: scrub completed with 0 errors on Fri Apr 13 22:43:46 2007 > config: >=20 > NAME STATE READ WRITE CKSUM > mypool ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > md0 ONLINE 0 0 0 > md1 ONLINE 0 0 0 > md3 ONLINE 0 0 5 If you are referring to this CKSUM count not beeing 0, this was a bug in ZFS itself, and was fixes in OpenSolaris already and fix was merged to FreeBSD. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --eJnRUKwClWJh1Khz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD4DBQFGIgpbForvXbEpPzQRAjhdAJd4VOMEq5V6tzfd7vIOK2gRmfh6AJ93BK2g fd0ANARFcae6ykqw53VYFg== =U0I+ -----END PGP SIGNATURE----- --eJnRUKwClWJh1Khz-- From owner-freebsd-fs@FreeBSD.ORG Sun Apr 15 15:39:09 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83D7916A407; Sun, 15 Apr 2007 15:39:09 +0000 (UTC) (envelope-from bp@barryp.org) Received: from eden.barryp.org (host-42-60-230-24.midco.net [24.230.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4372513C45A; Sun, 15 Apr 2007 15:39:09 +0000 (UTC) (envelope-from bp@barryp.org) Received: from [10.66.1.10] (helo=barry-pedersons-computer.local) by eden.barryp.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Hd6om-0007k9-E2; Sun, 15 Apr 2007 10:39:08 -0500 Message-ID: <46224706.4010704@barryp.org> Date: Sun, 15 Apr 2007 10:38:46 -0500 From: Barry Pederson User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <46205338.3090803@barryp.org> <20070415111955.GB16971@garage.freebsd.pl> In-Reply-To: <20070415111955.GB16971@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS raidz device replacement problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 15:39:09 -0000 Pawel Jakub Dawidek wrote: > On Fri, Apr 13, 2007 at 11:06:16PM -0500, Barry Pederson wrote: >> I've been playing with ZFS (awesome stuff, thanks PJD) and noticed something funny when replacing a device under a raidz pool. It seems that even though ZFS says >> resilvering is complete, you still need to manually do a "zpool scrub" to really get the pool into a good state. > > How do you tell it's not in a good state? I took this last output showing cksum errors on the replaced device to mean that the device wasn't really synced up with the rest of the raidz members - it didn't have the data on it that ZFS expected it to. >> # zpool status mypool >> pool: mypool >> state: ONLINE >> status: One or more devices has experienced an unrecoverable error. An >> attempt was made to correct the error. Applications are unaffected. >> action: Determine if the device needs to be replaced, and clear the errors >> using 'zpool clear' or replace the device with 'zpool replace'. >> see: http://www.sun.com/msg/ZFS-8000-9P >> scrub: scrub completed with 0 errors on Fri Apr 13 22:43:46 2007 >> config: >> >> NAME STATE READ WRITE CKSUM >> mypool ONLINE 0 0 0 >> raidz1 ONLINE 0 0 0 >> md0 ONLINE 0 0 0 >> md1 ONLINE 0 0 0 >> md3 ONLINE 0 0 5 > > If you are referring to this CKSUM count not beeing 0, this was a bug in > ZFS itself, and was fixes in OpenSolaris already and fix was merged to > FreeBSD. OK, I'll update and try again. But the thing that got me going on this was that if you *don't* do the scrub after the replace but instead do some other destructive things to one of the non-replaced devices, like: dd if=/dev/random bs=1m count=64 oseek=1 conv=notrunc of=/tmp/foo1 and *then* do a scrub and then "zpool status -v mypool", you get this really alarming message mentioning data corruption. --------------------- zpool status -v mypool pool: mypool state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub completed with 184 errors on Sun Apr 15 09:55:43 2007 config: NAME STATE READ WRITE CKSUM mypool ONLINE 0 0 761 raidz1 ONLINE 0 0 761 md0 ONLINE 0 0 0 md1 ONLINE 0 0 521 md3 ONLINE 0 0 25 errors: Permanent errors have been detected in the following files: mypool:<0x100> mypool:<0x104> mypool:<0x105> . . --------------------- I suppose you have to actually have some files in /mypool for this to show up. (are there supposed to be real filenames in the message instead of things like "<0x100>" ?) Now that I look at this closer and run "diff -r" between files I copied into the pool and the originals, I don't see any differences - so ZFS's claim about detecting actual corrupted files seems wrong there too. ("zpool clear mypool" doesn't make that "data corruption" warning go away, just the cksum counts). I'll keep poking at it. Barry From owner-freebsd-fs@FreeBSD.ORG Sun Apr 15 18:14:56 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E8AE16A400; Sun, 15 Apr 2007 18:14:56 +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 3743C13C469; Sun, 15 Apr 2007 18:14:55 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id BCE20487FB; Sun, 15 Apr 2007 20:14:54 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id A30AD487FA; Sun, 15 Apr 2007 20:14:49 +0200 (CEST) Date: Sun, 15 Apr 2007 20:14:26 +0200 From: Pawel Jakub Dawidek To: Joao Barros Message-ID: <20070415181426.GC16971@garage.freebsd.pl> References: <20070409094319.GB76673@garage.freebsd.pl> <70e8236f0704090808y5d305175wdc3cee5be1a26a9@mail.gmail.com> <20070409153338.GH76673@garage.freebsd.pl> <70e8236f0704090931v3d62d067kfa25993da10fb331@mail.gmail.com> <86bqhxcifq.fsf@dwp.des.no> <70e8236f0704100852y214dad89g1291bb525f4efc74@mail.gmail.com> <70e8236f0704121130u1262ccb6r571e18ad1a491dd3@mail.gmail.com> <86odlte2rm.fsf@dwp.des.no> <70e8236f0704121416h15f398dah479351b7776e8679@mail.gmail.com> <70e8236f0704140704v44a1810ft6bf3b7e6c426bb65@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2JFBq9zoW8cOFH7v" Content-Disposition: inline In-Reply-To: <70e8236f0704140704v44a1810ft6bf3b7e6c426bb65@mail.gmail.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=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS: amd64, devd, root file system. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 18:14:56 -0000 --2JFBq9zoW8cOFH7v Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 14, 2007 at 03:04:26PM +0100, Joao Barros wrote: > I only got one problem now: from what I can see swapon runs first that > the zfs startup script so I have no swap. > Only after booting I can see /dev/zvol/r4x320/swap and swapon works. I just committed a change to rc.d/zfs that will automatically configure swap on ZVOLs that have org.freebsd:swap=3Don property. So you need to update your system and: # zfs set org.freebsd:swap=3Don r4x320/swap --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --2JFBq9zoW8cOFH7v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGImuCForvXbEpPzQRAvReAKDGgYofAKeOwLr9eFnUrrGsvx057gCdHGFM EhkU/p/VsWxkYbTp/xXURhg= =CZ7k -----END PGP SIGNATURE----- --2JFBq9zoW8cOFH7v-- From owner-freebsd-fs@FreeBSD.ORG Sun Apr 15 19:12:17 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 230FF16A400; Sun, 15 Apr 2007 19:12:17 +0000 (UTC) (envelope-from bp@barryp.org) Received: from eden.barryp.org (host-42-60-230-24.midco.net [24.230.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id F24B013C4BE; Sun, 15 Apr 2007 19:12:14 +0000 (UTC) (envelope-from bp@barryp.org) Received: from [10.66.1.10] (helo=barry-pedersons-computer.local) by eden.barryp.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HdA8z-000LIr-G3; Sun, 15 Apr 2007 14:12:13 -0500 Message-ID: <462278F7.2060800@barryp.org> Date: Sun, 15 Apr 2007 14:11:51 -0500 From: Barry Pederson User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <46205338.3090803@barryp.org> <20070415111955.GB16971@garage.freebsd.pl> <46224706.4010704@barryp.org> In-Reply-To: <46224706.4010704@barryp.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS raidz device replacement problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 19:12:17 -0000 Barry Pederson wrote: > Pawel Jakub Dawidek wrote: >> >> If you are referring to this CKSUM count not beeing 0, this was a bug in >> ZFS itself, and was fixes in OpenSolaris already and fix was merged to >> FreeBSD. I just updated world and kernel, and it all seems good now. Thanks Barry From owner-freebsd-fs@FreeBSD.ORG Mon Apr 16 14:27:45 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8390F16A400 for ; Mon, 16 Apr 2007 14:27:45 +0000 (UTC) (envelope-from ml.freebsd-fs@ledisez.net) Received: from ledisez.net (ledisez.net [80.247.230.138]) by mx1.freebsd.org (Postfix) with ESMTP id 4DE5B13C484 for ; Mon, 16 Apr 2007 14:27:45 +0000 (UTC) (envelope-from ml.freebsd-fs@ledisez.net) Received: from webmail.ledisez.net (localhost.localdomain [80.247.230.138]) by ledisez.net (Postfix) with ESMTP id 685A845AD51 for ; Mon, 16 Apr 2007 16:27:44 +0200 (CEST) Received: from 62.212.122.219 (SquirrelMail authenticated user romain) by webmail.ledisez.net with HTTP; Mon, 16 Apr 2007 16:27:44 +0200 (CEST) Message-ID: <55456.62.212.122.219.1176733664.squirrel@webmail.ledisez.net> Date: Mon, 16 Apr 2007 16:27:44 +0200 (CEST) From: "Romain LE DISEZ" To: freebsd-fs@freebsd.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [ZFS] Problems with SATA disks (SET TRANSFERT MODE ...) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 14:27:45 -0000 Hi, I'm running FreeBSD-CURRENT (csup'ed from today). My config is : - Motherboard : Asus P4C800-E Deluxe - 2 SATA disks on the (ad10 and ad12) - 2 SATA disks on the (ad4 and ad6) On disks ad4, ad6 and ad12 there is a ZFS pool (raid-z) created with OpenSolaris. When copying big files, there is no problems. When copying somes little files, there is no problems. But, when I try to copy a lot of little files (eg: the source tree), I get the following messages on console : ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly ad6: FAILURE - FLUSHCACHE timed out (the same messages appear also for ad4 and ad12). Sometimes this messages appear on the boot, when starting ZFS (I enabled zfs at boot) It's strange because on ad10 (where freebsd is installed), I don't have this messages. After various research, I found http://lists.freebsd.org/pipermail/freebsd-hardware/2006-October/003924.html It could be a problem from the Promise controller sharing IRQ with other component (USB for example). I disabled USB from the BIOS but the problems still exist. I don't know if it's a bug from the controller, the ATA driver or ZFS. Thanks for your help. -- Romain LE DISEZ 06.78.77.99.18 http://www.ledisez.net/ From owner-freebsd-fs@FreeBSD.ORG Mon Apr 16 14:44:41 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0C1F16A404 for ; Mon, 16 Apr 2007 14:44:41 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 713A213C44B for ; Mon, 16 Apr 2007 14:44:41 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 878F52094; Mon, 16 Apr 2007 16:44:37 +0200 (CEST) X-Spam-Tests: AWL,UPPERCASE_25_50 X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 0A3712091; Mon, 16 Apr 2007 16:44:37 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id D473254A6; Mon, 16 Apr 2007 16:44:36 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: "Romain LE DISEZ" References: <55456.62.212.122.219.1176733664.squirrel@webmail.ledisez.net> Date: Mon, 16 Apr 2007 16:44:36 +0200 In-Reply-To: <55456.62.212.122.219.1176733664.squirrel@webmail.ledisez.net> (Romain LE DISEZ's message of "Mon, 16 Apr 2007 16:27:44 +0200 (CEST)") Message-ID: <86ps64nzu3.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: [ZFS] Problems with SATA disks (SET TRANSFERT MODE ...) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 14:44:41 -0000 "Romain LE DISEZ" writes: > But, when I try to copy a lot of little files (eg: the source tree), I get > the following messages on console : > ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - > completing request directly > ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - > completing request directly > ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing > request directly > ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing > request directly > ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly > ad6: FAILURE - FLUSHCACHE timed out > [...] > I don't know if it's a bug from the controller, the ATA driver or ZFS. I have the same problem with two different Promise chips. It's not limited to ZFS, though ZFS seems to make it worse. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Mon Apr 16 22:18:48 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0FBBE16A533 for ; Mon, 16 Apr 2007 22:18:48 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id 9189D13C459 for ; Mon, 16 Apr 2007 22:18:47 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 56979 invoked by uid 2001); 16 Apr 2007 22:18:42 -0000 Date: Mon, 16 Apr 2007 17:18:42 -0500 From: "Rick C. Petty" To: freebsd-fs@freebsd.org Message-ID: <20070416221842.GA56883@keira.kiwi-computer.com> References: <55456.62.212.122.219.1176733664.squirrel@webmail.ledisez.net> <86ps64nzu3.fsf@dwp.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86ps64nzu3.fsf@dwp.des.no> User-Agent: Mutt/1.4.2.1i Subject: Re: [ZFS] Problems with SATA disks (SET TRANSFERT MODE ...) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 22:18:48 -0000 On Mon, Apr 16, 2007 at 04:44:36PM +0200, Dag-Erling Sm?rgrav wrote: > "Romain LE DISEZ" writes: > > But, when I try to copy a lot of little files (eg: the source tree), I get > > the following messages on console : > > ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - > > completing request directly > > ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - > > completing request directly > > ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing > > request directly > > ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing > > request directly > > ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly > > ad6: FAILURE - FLUSHCACHE timed out I was gonna ask-- Is this a Promise chipset? > I have the same problem with two different Promise chips. It's not > limited to ZFS, though ZFS seems to make it worse. This is a known problem. I'm not sure if linux handles the Promise chips better-- I'm testing that tomorrow. From stepping through our ATA code, it seems like the card is just not responsive. For instance, on certain Promise cards you cannot do: atacontrol detach $promiseChannel atacontrol attach $promiseChannel or: atacontrol reinit $promiseChannel Which is weird, because the other 3 channels are being used at the same time without any problems. My advice: Stay away from Promise, or at least the "Promise PDC40718 SATA300 controller" but I've heard the same horror stories with numerous other chips. -- Rick C. Petty From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 09:09:28 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8494316A407 for ; Tue, 17 Apr 2007 09:09:28 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 45F1313C487 for ; Tue, 17 Apr 2007 09:09:28 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 525F72090; Tue, 17 Apr 2007 11:09:12 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 4370D2087; Tue, 17 Apr 2007 11:09:11 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 8951E5419; Tue, 17 Apr 2007 11:09:11 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: rick-freebsd@kiwi-computer.com References: <55456.62.212.122.219.1176733664.squirrel@webmail.ledisez.net> <86ps64nzu3.fsf@dwp.des.no> <20070416221842.GA56883@keira.kiwi-computer.com> Date: Tue, 17 Apr 2007 11:09:11 +0200 In-Reply-To: <20070416221842.GA56883@keira.kiwi-computer.com> (Rick C. Petty's message of "Mon, 16 Apr 2007 17:18:42 -0500") Message-ID: <86bqhn9xl4.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: [ZFS] Problems with SATA disks (SET TRANSFERT MODE ...) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 09:09:28 -0000 "Rick C. Petty" writes: > My advice: Stay away from Promise, or at least the "Promise PDC40718 > SATA300 controller" but I've heard the same horror stories with > numerous other chips. What's the alternative? Silicon Image? I can't seem to find a SATA controller which isn't either Promise or Silicon Image. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 13:19:46 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 314FF16A403 for ; Tue, 17 Apr 2007 13:19:46 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id F20A113C45D for ; Tue, 17 Apr 2007 13:19:45 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.8/8.13.8) with ESMTP id l3HCgA7l043614; Tue, 17 Apr 2007 07:42:10 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4624C0A2.5010101@centtech.com> Date: Tue, 17 Apr 2007 07:42:10 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <45D321F8.2000808@centtech.com> <20070214233848.GA13680@garage.freebsd.pl> In-Reply-To: <20070214233848.GA13680@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/3109/Mon Apr 16 22:59:17 2007 on mh2.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh2.centtech.com Cc: "freebsd-fs@freebsd.org" Subject: Re: fsck times/memory sizes/etc X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 13:19:46 -0000 On 02/14/07 17:38, Pawel Jakub Dawidek wrote: > On Wed, Feb 14, 2007 at 08:51:36AM -0600, Eric Anderson wrote: >> I just did some quick playing around, doing newfs and fsck's on fresh file systems. I did one set on a 1Gb malloc'ed md, and another on a 65GB real disk device. The disk >> was only being used for this test, nothing else. >> >> I don't claim these numbers are perfect, but I did run each test 3-4 times to make sure they were consistent. >> >> I found it interesting that the fsck times didn't reduce once all the files/directories were deleted. > > This may be because of UFS2 has lazy inodes allocator - it doesn't > initialize all inode blocks at newfs time, so fsck verifies only > allocated inode blocks, thus runs faster on new file system. > When you fill your file system, inode blocks are allocated, but are not > reclaimed when you delete file/directories. > You may try the same tests with UFS1, which allocates all inode blocks > at newfs time. > Finally got around to doing this: ################################################## # newfs -O1 /dev/ad2s2a /dev/ad2s2a: 65397.4MB (133933888 sectors) block size 16384, fragment size 2048 using 357 cylinder groups of 183.69MB, 11756 blks, 23552 inodes. # time fsck -f /dev/ad2s2a ** /dev/ad2s2a ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 2 files, 2 used, 32952243 free (19 frags, 4119028 blocks, 0.0% fragmentation) real 0m50.056s user 0m3.914s sys 0m0.460s # memory usage reached max of 7184kb (7MB) # fill it up # df -i /mnt Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/ad2s2a 65904490 138742 60493390 0% 8408062 0 100% /mnt # time fsck -f /dev/ad2s2a ** /dev/ad2s2a ** Last Mounted on /mnt ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 8408062 files, 69371 used, 32882874 free (18 frags, 4110357 blocks, 0.0% fragmentation) real 1m2.790s user 0m11.167s sys 0m0.553s # memory usage reached max of 39952kb (39MB) # mount, rm -rf all created files/dirs # df -i /mnt Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/ad2s2a 65904490 6 60632126 0% 2 8408060 0% /mnt # time fsck -f /dev/ad2s2a ** /dev/ad2s2a ** Last Mounted on /mnt ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 2 files, 3 used, 32952242 free (18 frags, 4119028 blocks, 0.0% fragmentation) real 0m49.576s user 0m2.281s sys 0m0.166s # memory usage reached max of 7184kb (7MB) ################################################## # newfs -O1 -b 16384 -f 2048 -i 262144 /dev/ad2s2a /dev/ad2s2a: 65397.4MB (133933888 sectors) block size 16384, fragment size 2048 using 294 cylinder groups of 223.02MB, 14273 blks, 896 inodes. # time fsck -f /dev/ad2s2a ** /dev/ad2s2a ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 2 files, 2 used, 33462291 free (19 frags, 4182784 blocks, 0.0% fragmentation) real 0m8.147s user 0m0.496s sys 0m0.015s # memory usage reached max of 7184kb (7MB) # fill it up # df -i /mnt Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/ad2s2a 66924586 4342 61566278 0% 263422 0 100% /mnt # time fsck -f /dev/ad2s2a ** /dev/ad2s2a ** Last Mounted on /mnt ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 263422 files, 2171 used, 33460122 free (26 frags, 4182512 blocks, 0.0% fragmentation) real 0m8.229s user 0m0.578s sys 0m0.104s # memory usage reached max of 8208kb (8MB) # mount, rm -rf all created files/dirs # df -i /mnt Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/ad2s2a 66924586 4 61570616 0% 2 263420 0% /mnt # time fsck -f /dev/ad2s2a ** /dev/ad2s2a ** Last Mounted on /mnt ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 2 files, 2 used, 33462291 free (19 frags, 4182784 blocks, 0.0% fragmentation) real 0m7.797s user 0m0.473s sys 0m0.035s # memory usage reached max of 7184kb (7MB) ################################################## Full report here: http://www.googlebit.com/doku.php?id=fsck_times_memory_sizes Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology An undefined problem has an infinite number of solutions. ------------------------------------------------------------------------ From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 16:11:08 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F1F116A40E for ; Tue, 17 Apr 2007 16:11:08 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id F017613C4B0 for ; Tue, 17 Apr 2007 16:11:07 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 86348 invoked by uid 2001); 17 Apr 2007 16:11:06 -0000 Date: Tue, 17 Apr 2007 11:11:06 -0500 From: "Rick C. Petty" To: freebsd-fs@freebsd.org Message-ID: <20070417161106.GA86245@keira.kiwi-computer.com> References: <55456.62.212.122.219.1176733664.squirrel@webmail.ledisez.net> <86ps64nzu3.fsf@dwp.des.no> <20070416221842.GA56883@keira.kiwi-computer.com> <86bqhn9xl4.fsf@dwp.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86bqhn9xl4.fsf@dwp.des.no> User-Agent: Mutt/1.4.2.1i Subject: Re: [ZFS] Problems with SATA disks (SET TRANSFERT MODE ...) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 16:11:08 -0000 On Tue, Apr 17, 2007 at 11:09:11AM +0200, Dag-Erling Sm?rgrav wrote: > "Rick C. Petty" writes: > > My advice: Stay away from Promise, or at least the "Promise PDC40718 > > SATA300 controller" but I've heard the same horror stories with > > numerous other chips. > > What's the alternative? Silicon Image? I can't seem to find a SATA > controller which isn't either Promise or Silicon Image. Pretty much. It's even harder to avoid Promise if you want 4 separate channels on one card (as opposed to 2 shared channels for 4 devices). The ideal solution is to figure out why the Promise doesn't properly reinitialize after a detach/attach.. if that's even possible. -- Rick C. Petty From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 17:30:08 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D88116A407 for ; Tue, 17 Apr 2007 17:30:08 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by mx1.freebsd.org (Postfix) with ESMTP id 3136613C45A for ; Tue, 17 Apr 2007 17:30:08 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so1936048wra for ; Tue, 17 Apr 2007 10:30:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=VHK4L4lglZc+dDhtfRK7zuoZBIdpdBg5ZfhaMNhHC88bzNF0/C796gTvkDym5cuje+O2TKh36qayYBc8Rxs2t0JV6G7uo+dl0kLGhnqkVUCl4EEtDcP9DKASg7HMH10ruH80P1YK+IHBPzXtIvfsRSKnz8qJ04m7HWmS+SuQIhk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=cX57le4VJ3+jNY4tkzjCvcrA6nOJN0GHr2NpRXr/XOHdmJo/mntIizV2QYTpuTOtIhG9w7NstAKQndCWZgg/nAS8BemhqxzIQiHKAN5G9KMlQierHRlK5MBXXDEhBOWCNWO6jC4CYQZlJWc3ILqe7P3xMh6lPBJevdv9jh8T3XE= Received: by 10.114.158.1 with SMTP id g1mr1401032wae.1176829277441; Tue, 17 Apr 2007 10:01:17 -0700 (PDT) Received: by 10.114.241.12 with HTTP; Tue, 17 Apr 2007 10:01:17 -0700 (PDT) Message-ID: Date: Tue, 17 Apr 2007 10:01:17 -0700 From: "Howard Su" To: fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: handle special file type in tmpfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 17:30:08 -0000 I am facing a problem when porting tmpfs. What's the story for FreeBSD to support special type of files, like BLK, CHR, FIFO, SOCKET? I know BLK/CHR will be handled by devfs. How about FIFO & SOCKET? Need any special code to handle them? Or they will be handled by VFS? Even, should tmpfs support them? -- -Howard From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 20:24:11 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 92F9F16A400 for ; Tue, 17 Apr 2007 20:24:11 +0000 (UTC) (envelope-from ml.freebsd-fs@ledisez.net) Received: from ledisez.net (ledisez.net [80.247.230.138]) by mx1.freebsd.org (Postfix) with ESMTP id 5A35A13C4AD for ; Tue, 17 Apr 2007 20:24:11 +0000 (UTC) (envelope-from ml.freebsd-fs@ledisez.net) Received: from webmail.ledisez.net (localhost.localdomain [80.247.230.138]) by ledisez.net (Postfix) with ESMTP id 4953F45AD51 for ; Tue, 17 Apr 2007 22:24:09 +0200 (CEST) Received: from 86.71.19.20 (SquirrelMail authenticated user romain) by webmail.ledisez.net with HTTP; Tue, 17 Apr 2007 22:24:10 +0200 (CEST) Message-ID: <51549.86.71.19.20.1176841450.squirrel@webmail.ledisez.net> In-Reply-To: <20070417161106.GA86245@keira.kiwi-computer.com> References: <55456.62.212.122.219.1176733664.squirrel@webmail.ledisez.net> <86ps64nzu3.fsf@dwp.des.no> <20070416221842.GA56883@keira.kiwi-computer.com> <86bqhn9xl4.fsf@dwp.des.no> <20070417161106.GA86245@keira.kiwi-computer.com> Date: Tue, 17 Apr 2007 22:24:10 +0200 (CEST) From: "Romain LE DISEZ" To: freebsd-fs@freebsd.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [ZFS] Problems with SATA disks (SET TRANSFERT MODE ...) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 20:24:11 -0000 It seems it's a FreeBSD bug because on an other OS, I hadn't any problems (or Linux deals better with bad chipsets ?). The situation is : - Xen 3.0.2 - Dom 0 : Linux (2.6.16) - Dom U : OpenSolaris b44 OpenSolaris access directly to the 3 disk of the ZFS pool. In this case, there is no problems so the bug come from FreeBSD. But it's probably not the place to discuss that. Maybe I should foward this conversation on an other list. freebsd-hardware@ ? -- Romain LE DISEZ 06.78.77.99.18 http://www.ledisez.net/ Le Mar 17 avril 2007 18:11, Rick C. Petty a écrit : > The ideal solution is to figure out why the Promise doesn't properly > reinitialize after a detach/attach.. if that's even possible. > > -- Rick C. Petty From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 20:46:57 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7992A16A400 for ; Tue, 17 Apr 2007 20:46:57 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4E8C713C448 for ; Tue, 17 Apr 2007 20:46:57 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l3HKku1m056362; Tue, 17 Apr 2007 15:46:56 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46253240.7030507@freebsd.org> Date: Tue, 17 Apr 2007 15:46:56 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: Howard Su References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/3110/Tue Apr 17 06:57:27 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: fs@freebsd.org Subject: Re: handle special file type in tmpfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 20:46:57 -0000 On 04/17/07 12:01, Howard Su wrote: > I am facing a problem when porting tmpfs. What's the story for FreeBSD > to support special type of files, like BLK, CHR, FIFO, SOCKET? I know > BLK/CHR will be > handled by devfs. How about FIFO & SOCKET? Need any special code to > handle them? Or they will be handled by VFS? Even, should tmpfs > support them? I'm not certain of all the answers to your questions, but I can say that I think FIFO & SOCKET are the most important ones. Eric From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 21:07:40 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B161116A402 for ; Tue, 17 Apr 2007 21:07:40 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.freebsd.org (Postfix) with ESMTP id 7060913C484 for ; Tue, 17 Apr 2007 21:07:40 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so1475842pyh for ; Tue, 17 Apr 2007 14:07:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kW97EkrHCQ0QMZQeG7rSTAjZNTO7gb7srPNsfmkb5mg9bIRtzUHGLu8wyfF0vzML+SZzOZ7t5kGYBOKxlULVP5qsjwUZfTQftPmgXnZVmJn1dihHQYkpCvDhHHal2OTUUmNl5w5oVoXlM5+QiKl0EnyCbLUQfNdMBYA3nHJ6tNo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aMHN/vQtGMdR7Qw/UMXg0cjakcN4PtqhyRuG6++hHSHCrCVBknBhrdnp0Mumux0sDPktTZvEiTZpImR7LZdgHS6boYijGhS7ruOCsFog7iW6Xh0Qb0kpy4s7V24tG8FjhkTEEkarK2pviqfRQxsV3AUMllUwOyZJl15CsYorgKA= Received: by 10.114.198.1 with SMTP id v1mr2604765waf.1176844059382; Tue, 17 Apr 2007 14:07:39 -0700 (PDT) Received: by 10.114.241.12 with HTTP; Tue, 17 Apr 2007 14:07:39 -0700 (PDT) Message-ID: Date: Tue, 17 Apr 2007 14:07:39 -0700 From: "Howard Su" To: fs@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46253240.7030507@freebsd.org> Cc: Subject: Fwd: handle special file type in tmpfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 21:07:40 -0000 On 4/17/07, Eric Anderson wrote: > I'm not certain of all the answers to your questions, but I can say that > I think FIFO & SOCKET are the most important ones. > I agree. I grep the source and try to figure out what is minimized part to support them in fs-dependent code. Only FFS/UFS, NULL_FS and ISO/UDF reference VFIFO. NULL_FS, NWFS and ISO/UDF reference VSOCK. I am not sure if there is some generic implementation in VFS already. -- -Howard From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 11:01:12 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C132F16A400 for ; Wed, 18 Apr 2007 11:01:12 +0000 (UTC) (envelope-from staalebk@ifi.uio.no) Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) by mx1.freebsd.org (Postfix) with ESMTP id 87CEA13C43E for ; Wed, 18 Apr 2007 11:01:12 +0000 (UTC) (envelope-from staalebk@ifi.uio.no) Received: from eschew.pusen.org (unknown [193.69.145.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.bluecom.no (Postfix) with ESMTP id B8CCF12CDFF for ; Wed, 18 Apr 2007 12:41:32 +0200 (CEST) Received: from chiller by eschew.pusen.org with local (Exim 4.50) id 1He7bn-0002Yc-Bf for fs@freebsd.org; Wed, 18 Apr 2007 12:41:55 +0200 Date: Wed, 18 Apr 2007 12:41:55 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: fs@freebsd.org Message-ID: <20070418104155.GA31727@eschew.pusen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: ZFS + replacing failing hard-drive. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 11:01:12 -0000 Hi! I have been testing ZFS on my fileserver. The data I had in the zpool is not that important so I do not have redundancy. Unfortunately I got a bad hard-drive: Apr 13 22:02:44 fs root: ZFS: vdev I/O failure, zpool=stash path=/dev/ad14s1d offset=336216064000 size=131072 error=5 Apr 13 22:02:56 fs kernel: ad14: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=3013311 I therefor bought a new drive and used dd_rescue to copy the salvageable blocks to the new disk. Booting up and things are looking good, no more DMA-errors and things seems to work. The only problem is that the blocks (24) that could not be copied produce CKSUM errors. This is perfect, but I now wants to delete the files that are touched by the problem, but 'zpool status -v' do not give me a path like in the zfs-handbook: errors: Permanent errors have been detected in the following files: stash/TV:<0x62b> How can I figure out what files are affected? Is there any way to fix this without rebuilding the pool? -- Ståle Kristoffersen staalebk@ifi.uio.no From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 14:15:02 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A77AA16A400 for ; Wed, 18 Apr 2007 14:15:02 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 6723613C458 for ; Wed, 18 Apr 2007 14:15:02 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id BB6EB207E; Wed, 18 Apr 2007 16:14:55 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 1DF942049; Wed, 18 Apr 2007 16:14:55 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 01EA8545E; Wed, 18 Apr 2007 16:14:54 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: rick-freebsd@kiwi-computer.com References: <55456.62.212.122.219.1176733664.squirrel@webmail.ledisez.net> <86ps64nzu3.fsf@dwp.des.no> <20070416221842.GA56883@keira.kiwi-computer.com> <86bqhn9xl4.fsf@dwp.des.no> <20070417161106.GA86245@keira.kiwi-computer.com> Date: Wed, 18 Apr 2007 16:14:54 +0200 In-Reply-To: <20070417161106.GA86245@keira.kiwi-computer.com> (Rick C. Petty's message of "Tue, 17 Apr 2007 11:11:06 -0500") Message-ID: <86lkgplqg1.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: [ZFS] Problems with SATA disks (SET TRANSFERT MODE ...) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 14:15:02 -0000 "Rick C. Petty" writes: > The ideal solution is to figure out why the Promise doesn't properly > reinitialize after a detach/attach.. if that's even possible. It shouldn't detach / attach in the first place. The primary issue (in my view) is the DMA timeout. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 14:18:15 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DDAD516A403 for ; Wed, 18 Apr 2007 14:18:15 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 9EA7A13C484 for ; Wed, 18 Apr 2007 14:18:15 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id E3C7A207E; Wed, 18 Apr 2007 16:18:11 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id D130F2049; Wed, 18 Apr 2007 16:18:11 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id B589B5462; Wed, 18 Apr 2007 16:18:11 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: =?iso-8859-1?Q?St=E5le?= Kristoffersen References: <20070418104155.GA31727@eschew.pusen.org> Date: Wed, 18 Apr 2007 16:18:11 +0200 In-Reply-To: <20070418104155.GA31727@eschew.pusen.org> (=?iso-8859-1?Q?St?= =?iso-8859-1?Q?=E5le?= Kristoffersen's message of "Wed, 18 Apr 2007 12:41:55 +0200") Message-ID: <86hcrdlqak.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: fs@freebsd.org Subject: Re: ZFS + replacing failing hard-drive. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 14:18:15 -0000 St=E5le Kristoffersen writes: > I have been testing ZFS on my fileserver. The data I had in the zpool is > not that important so I do not have redundancy. Unfortunately I got a bad > hard-drive: > Apr 13 22:02:44 fs root: ZFS: vdev I/O failure, zpool=3Dstash path=3D/dev= /ad14s1d offset=3D336216064000 size=3D131072 error=3D5 > Apr 13 22:02:56 fs kernel: ad14: TIMEOUT - WRITE_DMA retrying (1 retry le= ft) LBA=3D3013311 I don't think you do. This appears to be a bug in the ata driver which ZFS is particularly good at triggering. BTW, the message you show is harmless: see where it says "retrying"? No need to worry until it says "FAILURE - WRITE_DMA timed out". DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 14:41:08 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD38916A404 for ; Wed, 18 Apr 2007 14:41:08 +0000 (UTC) (envelope-from staalebk@ifi.uio.no) Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) by mx1.freebsd.org (Postfix) with ESMTP id 43FAD13C487 for ; Wed, 18 Apr 2007 14:41:08 +0000 (UTC) (envelope-from staalebk@ifi.uio.no) Received: from eschew.pusen.org (unknown [193.69.145.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.bluecom.no (Postfix) with ESMTP id D234F16FD9E; Wed, 18 Apr 2007 16:41:06 +0200 (CEST) Received: from chiller by eschew.pusen.org with local (Exim 4.50) id 1HeBLE-0006g1-5j; Wed, 18 Apr 2007 16:41:04 +0200 Date: Wed, 18 Apr 2007 16:41:03 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20070418144103.GB31727@eschew.pusen.org> References: <20070418104155.GA31727@eschew.pusen.org> <86hcrdlqak.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86hcrdlqak.fsf@dwp.des.no> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: fs@freebsd.org Subject: Re: ZFS + replacing failing hard-drive. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 14:41:08 -0000 On 2007-04-18 at 16:18, Dag-Erling Smørgrav wrote: > Ståle Kristoffersen writes: > > I have been testing ZFS on my fileserver. The data I had in the zpool is > > not that important so I do not have redundancy. Unfortunately I got a bad > > hard-drive: > > Apr 13 22:02:44 fs root: ZFS: vdev I/O failure, zpool=stash path=/dev/ad14s1d offset=336216064000 size=131072 error=5 > > Apr 13 22:02:56 fs kernel: ad14: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=3013311 > > I don't think you do. This appears to be a bug in the ata driver > which ZFS is particularly good at triggering. I first noticed the problems running UFS an the first partition, and I have tried the drive on all of the following controllers: atapci0: port 0xcf00-0xcf7f mem 0xfddff000-0xfddff07f,0xfddf8000-0xfddfbfff irq 19 at device 0.0 on pci4 atapci1: port 0xaf00-0xaf07,0xae00-0xae03,0xad00-0xad07,0xac00-0xac03,0xab00-0xab0f mem 0xfd9fe000-0xfd9fffff irq 17 at device 0.0 on pci6 atapci2: port 0xfa00-0xfa07,0xf900-0xf903,0xf800-0xf807,0xf700-0xf703,0xf600-0xf60f,0xf500-0xf50f irq 19 at device 31.2 on pci0 atapci3: port 0xf300-0xf307,0xf200-0xf203,0xf100-0xf107,0xf000-0xf003,0xef00-0xef0f,0xee00-0xee0f irq 19 at device 31.5 on pci0 Same problem on all. And to support my theory that the disk was bad the new disk does not behave badly, even after a zpool scrub. > BTW, the message you show is harmless: see where it says "retrying"? > No need to worry until it says "FAILURE - WRITE_DMA timed out". Just had a quick peek in the logs and did not find any of them the last time, but I do get them: Apr 13 21:17:14 fs kernel: ad14: FAILURE - WRITE_DMA48 timed out LBA=719378349 Apr 13 21:22:23 fs kernel: ad14: FAILURE - WRITE_DMA48 status=51 error=10 LBA=719341415 Another issue is that even if all the drives support SATA300, and all the controllers does so as well, they still come up as SATA150 (except one). (And yeah, I have removed that jumper) ad8: 305245MB at ata4-master SATA300 ad10: 381554MB at ata5-master SATA150 ad14: 305245MB at ata7-master SATA150 ad15: 305245MB at ata7-slave SATA150 ad16: 305245MB at ata8-master SATA150 but this is probably the wrong place for that. -- Ståle Kristoffersen staalebk@ifi.uio.no From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 14:48:39 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 945D616A407 for ; Wed, 18 Apr 2007 14:48:39 +0000 (UTC) (envelope-from dayzofrift@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.224]) by mx1.freebsd.org (Postfix) with ESMTP id 52E9213C484 for ; Wed, 18 Apr 2007 14:48:39 +0000 (UTC) (envelope-from dayzofrift@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so155926nza for ; Wed, 18 Apr 2007 07:48:34 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=IcsaW5Fq8Rg1RqEBjjdl3+CIhoixC2CmJIpKxsqNhH7w8uzE5AuHOZhCgsZODJWisg7fBaF89crrANIMqW6m481kYtL7cc85VFHSCoaIx4h19ZGA34ilPs6NfqXXKEkkZYMcN1VZYbA9HnkwiXbRruTMHVS60byciPBJtyAQL34= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=rSXU730/GSZtvxykJSarUtW7Nx20uIF9NJCi18bwtu/sbGUUT9RVeTNG1uXE7osZNn6EbCHLdHrtLUWP91Y7T865PBmAqKIPMdbJAwHnK0MzWlevtO8Z3iVCu1Xp+2Hhrl3AWpDYWLvvL7V93W0RPpkDPCVACCDOJxdnbiH0Xy8= Received: by 10.115.54.1 with SMTP id g1mr209837wak.1176906138310; Wed, 18 Apr 2007 07:22:18 -0700 (PDT) Received: by 10.114.202.1 with HTTP; Wed, 18 Apr 2007 07:22:18 -0700 (PDT) Message-ID: <87b02eb0704180722q3f45095k5293cfa343ba8514@mail.gmail.com> Date: Wed, 18 Apr 2007 16:22:18 +0200 From: Rift`` To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Unable to umount ext3 partition X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 14:48:39 -0000 Hi, I'am runing on FreeBSD i386 6.2. i have an usb disk with an ext3 partition. I mount the partition with "mount_ext2fs /dev/da0s3 /mnt/ipodlinux", but when I tried to umount the disk i have: "umount: unmount of /mnt/ipodlinux failed: Device busy". I have tried to get who is accessing to the fs, but nothing is accessing to the disk (verified with lsof/ps). Thanks for the answer. Rift From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 15:09:35 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 610BC16A401 for ; Wed, 18 Apr 2007 15:09:35 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3568613C43E for ; Wed, 18 Apr 2007 15:09:35 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l3IF9WRp050467; Wed, 18 Apr 2007 10:09:32 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <462634AC.1000403@freebsd.org> Date: Wed, 18 Apr 2007 10:09:32 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: Rift`` References: <87b02eb0704180722q3f45095k5293cfa343ba8514@mail.gmail.com> In-Reply-To: <87b02eb0704180722q3f45095k5293cfa343ba8514@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/3120/Wed Apr 18 08:00:32 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-fs@freebsd.org Subject: Re: Unable to umount ext3 partition X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 15:09:35 -0000 On 04/18/07 09:22, Rift`` wrote: > Hi, > I'am runing on FreeBSD i386 6.2. > i have an usb disk with an ext3 partition. > I mount the partition with "mount_ext2fs /dev/da0s3 /mnt/ipodlinux", but when > I tried to umount the disk i have: "umount: unmount of /mnt/ipodlinux > failed: Device busy". I have tried to get who is accessing to the fs, > but nothing is accessing to the disk (verified with lsof/ps). > Thanks for the answer. > Rift So doing: fstat | grep ipodlinux returns nothing? Eric From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 15:27:45 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 11EDB16A404 for ; Wed, 18 Apr 2007 15:27:45 +0000 (UTC) (envelope-from dayzofrift@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.233]) by mx1.freebsd.org (Postfix) with ESMTP id C52BC13C4C7 for ; Wed, 18 Apr 2007 15:27:44 +0000 (UTC) (envelope-from dayzofrift@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so191319wra for ; Wed, 18 Apr 2007 08:27:43 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HT0TNTR/MjspirUAZ4Jt3esN9tx8xHHJtYwlKRpjNAjWs1QZi50FWlZ8bWIUHTVDN4juOHg6Q7HJrPQBqlfzx/Y+Hu6HjkwuLLmreZ04gFUT/NcuIbfx8N+xqN4LLRVFucp7k1JP5bFyefDMbq7EaLTGGciAOwMCHeFM0lzdfA4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pnSKBl6VPDfWFWGxDo/Vfo5lDiRGjfJI4/vUwsUQh0plGIL8Ppl2wfe2ehDjYB+nZcf30oCghxJ96XAtccIqjIpnBNVF0CVtFwJB4AuOAKuRTzQ3O3m0l9B6eFKwZTxEv+1J4bEsfgsejUbEU0iUZZClfg72HkL1dJu7Evz6QV8= Received: by 10.115.75.1 with SMTP id c1mr269796wal.1176910056502; Wed, 18 Apr 2007 08:27:36 -0700 (PDT) Received: by 10.114.202.1 with HTTP; Wed, 18 Apr 2007 08:27:36 -0700 (PDT) Message-ID: <87b02eb0704180827k1ea64e0ercedff7f9565983ce@mail.gmail.com> Date: Wed, 18 Apr 2007 17:27:36 +0200 From: Rift`` To: "Eric Anderson" In-Reply-To: <462634AC.1000403@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <87b02eb0704180722q3f45095k5293cfa343ba8514@mail.gmail.com> <462634AC.1000403@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re : Unable to umount ext3 partition X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 15:27:45 -0000 it returns nothing: # fstat | grep ipodlinux # umount /mnt/ipodlinux/ umount: unmount of /mnt/ipodlinux failed: Device busy # Rift 2007/4/18, Eric Anderson : > On 04/18/07 09:22, Rift`` wrote: > > Hi, > > I'am runing on FreeBSD i386 6.2. > > i have an usb disk with an ext3 partition. > > I mount the partition with "mount_ext2fs /dev/da0s3 /mnt/ipodlinux", but > when > > I tried to umount the disk i have: "umount: unmount of /mnt/ipodlinux > > failed: Device busy". I have tried to get who is accessing to the fs, > > but nothing is accessing to the disk (verified with lsof/ps). > > Thanks for the answer. > > Rift > > > So doing: > > fstat | grep ipodlinux > > returns nothing? > > Eric > From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 15:39:22 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19B6816A408 for ; Wed, 18 Apr 2007 15:39:22 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id 91D5E13C4BB for ; Wed, 18 Apr 2007 15:39:21 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 20813 invoked by uid 2001); 18 Apr 2007 15:39:20 -0000 Date: Wed, 18 Apr 2007 10:39:20 -0500 From: "Rick C. Petty" To: freebsd-fs@freebsd.org Message-ID: <20070418153920.GA20441@keira.kiwi-computer.com> References: <55456.62.212.122.219.1176733664.squirrel@webmail.ledisez.net> <86ps64nzu3.fsf@dwp.des.no> <20070416221842.GA56883@keira.kiwi-computer.com> <86bqhn9xl4.fsf@dwp.des.no> <20070417161106.GA86245@keira.kiwi-computer.com> <86lkgplqg1.fsf@dwp.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86lkgplqg1.fsf@dwp.des.no> User-Agent: Mutt/1.4.2.1i Subject: Re: [ZFS] Problems with SATA disks (SET TRANSFERT MODE ...) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 15:39:22 -0000 On Wed, Apr 18, 2007 at 04:14:54PM +0200, Dag-Erling Sm?rgrav wrote: > "Rick C. Petty" writes: > > The ideal solution is to figure out why the Promise doesn't properly > > reinitialize after a detach/attach.. if that's even possible. > > It shouldn't detach / attach in the first place. The primary issue > (in my view) is the DMA timeout. I completely agree that the DMA timeouts should be less sensitive to "disappearing drives" when in fact the drives are just fine. However, it can't hurt to fix the attach/detach problem also, because it's perfectly legitimate to hot-swap SATA drives. -- Rick C. Petty From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 16:18:38 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 99E8116A401 for ; Wed, 18 Apr 2007 16:18:38 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id 399E413C465 for ; Wed, 18 Apr 2007 16:18:38 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 21184 invoked by uid 2001); 18 Apr 2007 15:51:56 -0000 Date: Wed, 18 Apr 2007 10:51:56 -0500 From: "Rick C. Petty" To: St?le Kristoffersen Message-ID: <20070418155156.GB20441@keira.kiwi-computer.com> References: <20070418104155.GA31727@eschew.pusen.org> <86hcrdlqak.fsf@dwp.des.no> <20070418144103.GB31727@eschew.pusen.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070418144103.GB31727@eschew.pusen.org> User-Agent: Mutt/1.4.2.1i Cc: fs@freebsd.org Subject: Re: ZFS + replacing failing hard-drive. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 16:18:38 -0000 On Wed, Apr 18, 2007 at 04:41:03PM +0200, St?le Kristoffersen wrote: > > > > I don't think you do. This appears to be a bug in the ata driver > > which ZFS is particularly good at triggering. > > I first noticed the problems running UFS an the first partition, and I have > tried the drive on all of the following controllers: > atapci0: port 0xcf00-0xcf7f mem 0xfddff000-0xfddff07f,0xfddf8000-0xfddfbfff irq 19 at device 0.0 on pci4 > atapci1: port 0xaf00-0xaf07,0xae00-0xae03,0xad00-0xad07,0xac00-0xac03,0xab00-0xab0f mem 0xfd9fe000-0xfd9fffff irq 17 at device 0.0 on pci6 > atapci2: port 0xfa00-0xfa07,0xf900-0xf903,0xf800-0xf807,0xf700-0xf703,0xf600-0xf60f,0xf500-0xf50f irq 19 at device 31.2 on pci0 > atapci3: port 0xf300-0xf307,0xf200-0xf203,0xf100-0xf107,0xf000-0xf003,0xef00-0xef0f,0xee00-0xee0f irq 19 at device 31.5 on pci0 > > Same problem on all. And to support my theory that the disk was bad the new > disk does not behave badly, even after a zpool scrub. That doesn't prove the disk was/is "bad". Here I'm using the word "bad" to mean the disk has had at least 1 non-recoverable failure (i.e. a bad area on the platter surface was discovered and the drive was unable to remap it). As new as SATA300 is, it is doubtful (although possible) that the drive is "bad"/defective. > > BTW, the message you show is harmless: see where it says "retrying"? > > No need to worry until it says "FAILURE - WRITE_DMA timed out". > > Just had a quick peek in the logs and did not find any of them the last > time, but I do get them: > Apr 13 21:17:14 fs kernel: ad14: FAILURE - WRITE_DMA48 timed out LBA=719378349 > Apr 13 21:22:23 fs kernel: ad14: FAILURE - WRITE_DMA48 status=51 error=10 LBA=719341415 I've noticed rarely that the DMA timeouts aren't always reported before a drive is dropped, and oftentimes DMA timeouts *don't* drop the drive. The latter case is good cuz I'll stop the disk activity and tell gvinum to start the disk again, but the former confounds me-- it's never been reproducable so I couldn't track it down. It could also just be a syslog issue. > Another issue is that even if all the drives support SATA300, and all the > controllers does so as well, they still come up as SATA150 (except one). > (And yeah, I have removed that jumper) > ad8: 305245MB at ata4-master SATA300 > ad10: 381554MB at ata5-master SATA150 > ad14: 305245MB at ata7-master SATA150 > ad15: 305245MB at ata7-slave SATA150 > ad16: 305245MB at ata8-master SATA150 I've noticed this behavior on certain controllers (Intel in particular). Which drives correspond to which controller cards? -- Rick C. Petty From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 18:02:03 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77D0216A400 for ; Wed, 18 Apr 2007 18:02:03 +0000 (UTC) (envelope-from staalebk@ifi.uio.no) Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) by mx1.freebsd.org (Postfix) with ESMTP id 0C51C13C455 for ; Wed, 18 Apr 2007 18:02:02 +0000 (UTC) (envelope-from staalebk@ifi.uio.no) Received: from eschew.pusen.org (unknown [193.69.145.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.bluecom.no (Postfix) with ESMTP id AA30C16FB48; Wed, 18 Apr 2007 20:02:01 +0200 (CEST) Received: from chiller by eschew.pusen.org with local (Exim 4.50) id 1HeETg-0001iD-RI; Wed, 18 Apr 2007 20:02:00 +0200 Date: Wed, 18 Apr 2007 20:02:00 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: "Rick C. Petty" Message-ID: <20070418180200.GA32061@eschew.pusen.org> References: <20070418104155.GA31727@eschew.pusen.org> <86hcrdlqak.fsf@dwp.des.no> <20070418144103.GB31727@eschew.pusen.org> <20070418155156.GB20441@keira.kiwi-computer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070418155156.GB20441@keira.kiwi-computer.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: fs@freebsd.org Subject: Re: ZFS + replacing failing hard-drive. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 18:02:03 -0000 On 2007-04-18 at 10:51, Rick C. Petty wrote: > On Wed, Apr 18, 2007 at 04:41:03PM +0200, St?le Kristoffersen wrote: > > > > > > I don't think you do. This appears to be a bug in the ata driver > > > which ZFS is particularly good at triggering. > > > > I first noticed the problems running UFS an the first partition, and I have > > tried the drive on all of the following controllers: > > atapci0: port 0xcf00-0xcf7f mem 0xfddff000-0xfddff07f,0xfddf8000-0xfddfbfff irq 19 at device 0.0 on pci4 > > atapci1: port 0xaf00-0xaf07,0xae00-0xae03,0xad00-0xad07,0xac00-0xac03,0xab00-0xab0f mem 0xfd9fe000-0xfd9fffff irq 17 at device 0.0 on pci6 > > atapci2: port 0xfa00-0xfa07,0xf900-0xf903,0xf800-0xf807,0xf700-0xf703,0xf600-0xf60f,0xf500-0xf50f irq 19 at device 31.2 on pci0 > > atapci3: port 0xf300-0xf307,0xf200-0xf203,0xf100-0xf107,0xf000-0xf003,0xef00-0xef0f,0xee00-0xee0f irq 19 at device 31.5 on pci0 > > > > Same problem on all. And to support my theory that the disk was bad the new > > disk does not behave badly, even after a zpool scrub. > > That doesn't prove the disk was/is "bad". Here I'm using the word "bad" to > mean the disk has had at least 1 non-recoverable failure (i.e. a bad area > on the platter surface was discovered and the drive was unable to remap > it). As new as SATA300 is, it is doubtful (although possible) that the > drive is "bad"/defective. The drive was new a couple of weeks ago, and it gave me errors almost from the beginning. > > Another issue is that even if all the drives support SATA300, and all the > > controllers does so as well, they still come up as SATA150 (except one). > > (And yeah, I have removed that jumper) > > ad8: 305245MB at ata4-master SATA300 > > ad10: 381554MB at ata5-master SATA150 > > ad14: 305245MB at ata7-master SATA150 > > ad15: 305245MB at ata7-slave SATA150 > > ad16: 305245MB at ata8-master SATA150 > > I've noticed this behavior on certain controllers (Intel in particular). > Which drives correspond to which controller cards? I've been swapping them around but right now: atapci0: port 0xcf00-0xcf7f mem 0xfddff000-0xfddff07f,0xfddf8000-0xfddfbfff irq 19 at device 0.0 on pci4 atapci1: port 0xaf00-0xaf07,0xae00-0xae03,0xad00-0xad07,0xac00-0xac03,0xab00-0xab0f mem 0xfd9fe000-0xfd9fffff irq 17 at device 0.0 on pci6 atapci1: AHCI Version 01.00 controller with 2 ports detected atapci2: port 0xfa00-0xfa07,0xf900-0xf903,0xf800-0xf807,0xf700-0xf703,0xf600-0xf60f,0xf500-0xf50f irq 19 at device 31.2 on pci0 atapci3: port 0xf300-0xf307,0xf200-0xf203,0xf100-0xf107,0xf000-0xf003,0xef00-0xef0f,0xee00-0xee0f irq 19 at device 31.5 on pci0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata2: on atapci0 ata3: on atapci0 ata4: on atapci1 ata5: on atapci1 ata6: on atapci1 ata7: on atapci2 ata8: on atapci2 ata9: on atapci3 ata10: on atapci3 ad8: 305245MB at ata4-master SATA300 ad10: 381554MB at ata5-master SATA150 ad14: 305245MB at ata7-master SATA150 ad15: 305245MB at ata7-slave SATA150 ad16: 305245MB at ata8-master SATA150 -- Ståle Kristoffersen staalebk@ifi.uio.no From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 21:51:28 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A6C016A40F for ; Wed, 18 Apr 2007 21:51:28 +0000 (UTC) (envelope-from antik@bsd.ee) Received: from smtp-gw1.starman.ee (smtp-out5.starman.ee [85.253.0.7]) by mx1.freebsd.org (Postfix) with ESMTP id EE76D13C4C1 for ; Wed, 18 Apr 2007 21:51:27 +0000 (UTC) (envelope-from antik@bsd.ee) Received: from mx1.starman.ee (mx1.starman.ee [62.65.192.16]) by smtp-gw1.starman.ee (Postfix) with ESMTP id B4C9BA219DC for ; Thu, 19 Apr 2007 00:51:26 +0300 (EEST) Received: from [192.168.2.100] (pc158.host1.ida.starman.ee [62.65.240.158]) by mx1.starman.ee (Postfix) with ESMTP id 122F223C573 for ; Thu, 19 Apr 2007 00:51:25 +0300 (EEST) From: Andrei Kolu To: freebsd-fs@freebsd.org Date: Thu, 19 Apr 2007 00:51:25 +0300 User-Agent: KMail/1.9.5 References: <87b02eb0704180722q3f45095k5293cfa343ba8514@mail.gmail.com> <462634AC.1000403@freebsd.org> <87b02eb0704180827k1ea64e0ercedff7f9565983ce@mail.gmail.com> In-Reply-To: <87b02eb0704180827k1ea64e0ercedff7f9565983ce@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704190051.25639.antik@bsd.ee> X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Subject: Re: Unable to umount ext3 partition X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 21:51:28 -0000 On Wednesday 18 April 2007 18:27, Rift`` wrote: > it returns nothing: > > # fstat | grep ipodlinux > # umount /mnt/ipodlinux/ > umount: unmount of /mnt/ipodlinux failed: Device busy > # > # umount -f -f The file system is forcibly unmounted. Active special devices continue to work, but all other files return errors if further accesses are attempted. The root file system cannot be forcibly unmounted. From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 23:53:29 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AEC1816A401 for ; Wed, 18 Apr 2007 23:53:29 +0000 (UTC) (envelope-from amarat@ksu.ru) Received: from zealot.ksu.ru (zealot.ksu.ru [194.85.245.161]) by mx1.freebsd.org (Postfix) with ESMTP id 2C38113C483 for ; Wed, 18 Apr 2007 23:53:28 +0000 (UTC) (envelope-from amarat@ksu.ru) Received: from zealot.ksu.ru (localhost.lnet [127.0.0.1]) by zealot.ksu.ru (8.13.8/8.13.8) with ESMTP id l3INc0QY014691 for ; Thu, 19 Apr 2007 03:38:01 +0400 (MSD) (envelope-from amarat@ksu.ru) Message-ID: <4626ABD8.1020205@ksu.ru> Date: Thu, 19 Apr 2007 03:38:00 +0400 From: "Marat N.Afanasyev" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.2) Gecko/20070418 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: adding a fs to /etc/exports deletes noexec flag from mount output X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 23:53:29 -0000 Hello! How to solve the following problem: I have some very large filesystems that are nfs-exported to some other machines, they are mounted there as noexec to make sure that no executable will be run from them. on machines where this filesystems mounted via nfs with noexec option in /etc/fstab, /etc/periodic/security/100.chksetuid doesn't try to find chuid/suid files on this filesystems. On the host machine i see that as fast as i add filesystem to /etc/exports 'noexec' option disappears from mount output. and i have either to switch off /etc/periodic/security/100.chksetuid completely, or wait for find to traverse entire 2T filesystems with huge amount of files and directories. it locks up my raid device almost completely, and i can read info from device only as fast as 1m per second. It's somehow annoying :( is there any other ways to solve this rather than switching off $daily_status_security_chksetuid_enable in /etc/periodic.conf? -- SY, Marat From owner-freebsd-fs@FreeBSD.ORG Thu Apr 19 04:22:52 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8106E16A404 for ; Thu, 19 Apr 2007 04:22:52 +0000 (UTC) (envelope-from Glen.Leeder@nokia.com) Received: from mgw-ext14.nokia.com (smtp.nokia.com [131.228.20.173]) by mx1.freebsd.org (Postfix) with ESMTP id 0A5B613C4BC for ; Thu, 19 Apr 2007 04:22:51 +0000 (UTC) (envelope-from Glen.Leeder@nokia.com) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3J445oq014080 for ; Thu, 19 Apr 2007 07:04:18 +0300 Received: from siebh101.NOE.Nokia.com ([172.30.195.27]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 07:04:12 +0300 Received: from syebe101.NOE.Nokia.com ([172.30.128.65]) by siebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 12:04:10 +0800 Received: from [172.30.10.229] ([172.30.10.229]) by syebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 14:04:09 +1000 Message-ID: <4626EA38.6010703@nokia.com> Date: Thu, 19 Apr 2007 14:04:08 +1000 From: Glen User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2007 04:04:09.0320 (UTC) FILETIME=[C7F9D680:01C78237] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070419070418-36C48BB0-2705F2BA/0-0/0-0 X-Nokia-AV: Clean Subject: Fwd: handle special file type in tmpfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 04:22:52 -0000 Hi Howard, May I ask if you are using the tmpfs port by Rohit Jalan? A link to his work can be found on this page: http://www.freebsd.org/projects/ideas/ I am currently using the BETA3 tmpfs port and have experienced an issue with the FIFO support for tmpfs. I believe that this is because the tmpfs_fifoops.c specifies an incomplete vnode operations vector (vop_vector) for tmpfs. The vop_vector allows you to specify all the vnode operations for a particular filesystem. If you check out ufs/ufs_vnops.c it specifies a global vop vector for most file types and then a different vop_vector for FIFO file types. Rohit's tmpfs port does a similar thing. I have populated the tmpfs vop_vector in this port and FIFO seems to work a better although I haven't fully tested it yet. Maybe this information helps you get to a solution. I am keen to get tmpfs into the Freebsd tree and have been communicating with Rohit regarding this. He currently doesn't have time to do further improvements and I have offered to help get this tmpfs port into Freebsd. I am awaiting a response to this (we only started talking last week). This port has a few outstanding items: * MP safeness (some locking may be required). I have started testing tmpfs on an MP system. * Security audit (not sure what's required for this) * Quota support, ACL work is pending * Two data I/O mechanisms are benchmarked, deciding which one to use is still pending I may be looking to address these items over the coming weeks. Regards, Glen From owner-freebsd-fs@FreeBSD.ORG Thu Apr 19 04:46:18 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D1C516A403 for ; Thu, 19 Apr 2007 04:46:18 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3D83613C4BC for ; Thu, 19 Apr 2007 04:46:18 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 947A01A4D80; Wed, 18 Apr 2007 21:46:34 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8088051406; Thu, 19 Apr 2007 00:46:17 -0400 (EDT) Date: Thu, 19 Apr 2007 00:46:17 -0400 From: Kris Kennaway To: Glen Message-ID: <20070419044617.GA49749@xor.obsecurity.org> References: <4626EA38.6010703@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4626EA38.6010703@nokia.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@freebsd.org Subject: Re: Fwd: handle special file type in tmpfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 04:46:18 -0000 On Thu, Apr 19, 2007 at 02:04:08PM +1000, Glen wrote: > Hi Howard, > > May I ask if you are using the tmpfs port by Rohit Jalan? A link to his > work can be found on this page: > http://www.freebsd.org/projects/ideas/ Yes, that's what he's fixing ;-) > This port has a few outstanding items: > > * MP safeness (some locking may be required). I have started testing > tmpfs on an MP system. > * Security audit (not sure what's required for this) > * Quota support, ACL work is pending > * Two data I/O mechanisms are benchmarked, deciding which one to use is > still pending > > I may be looking to address these items over the coming weeks. Cool, two people are better than one :D Kris From owner-freebsd-fs@FreeBSD.ORG Thu Apr 19 08:02:26 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7BBA16A400 for ; Thu, 19 Apr 2007 08:02:26 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.225]) by mx1.freebsd.org (Postfix) with ESMTP id 885CB13C458 for ; Thu, 19 Apr 2007 08:02:26 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so397834nza for ; Thu, 19 Apr 2007 01:02:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ryYd2m2bDLZtoC7RB4cwpxGVFQmo/gIvp+QAPxQm3nsXZ57I7zYIf5M3ZOX6vxwdmXO+MTNUUO2DeNdXv9I7RCFyIhvuOaqhaO/sKhYTHTb/GLILIX6Z6tgtsWpmPUAexpHkOYh5OztbR2oR6RUDegEKXck2ovZBv+JbnO4KL3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cK/qM86Lx321QdzbOqEQsBB3ef6/NXwQtOJQg47W4R/Crn35K27UdlkXw/ynKWORssGbweVcPKmzli0WqSpO8NCKXqWKboA3FV56PycFJEfWXyjWLqFavH3ndYU+7aoPjJ4dK6CsayQvtp6kL58XQWAs7jR795n+gbcE+9KyNro= Received: by 10.114.176.1 with SMTP id y1mr623922wae.1176969745550; Thu, 19 Apr 2007 01:02:25 -0700 (PDT) Received: by 10.114.241.12 with HTTP; Thu, 19 Apr 2007 01:02:25 -0700 (PDT) Message-ID: Date: Thu, 19 Apr 2007 01:02:25 -0700 From: "Howard Su" To: Glen , fs@freebsd.org In-Reply-To: <4626F339.5040602@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4626EA38.6010703@nokia.com> <4626F339.5040602@nokia.com> Cc: Subject: Re: handle special file type in tmpfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 08:02:26 -0000 > Glen wrote: > > Hi Howard, > > > > May I ask if you are using the tmpfs port by Rohit Jalan? A link to > > his work can be found on this page: > > http://www.freebsd.org/projects/ideas/ Yes. The ideas page bring me to this working. > > > > I am currently using the BETA3 tmpfs port and have experienced an > > issue with the FIFO support for tmpfs. I believe that this is because > > the tmpfs_fifoops.c specifies an incomplete vnode operations vector > > (vop_vector) for tmpfs. The vop_vector allows you to specify all the > > vnode operations for a particular filesystem. I already fix that in my WIP. you can check the code in the perforce. http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/howardsu/truss/sys/fs/tmpfs My working currently based on Beta3. > > > > If you check out ufs/ufs_vnops.c it specifies a global vop vector for > > most file types and then a different vop_vector for FIFO file types. > > Rohit's tmpfs port does a similar thing. I have populated the tmpfs > > vop_vector in this port and FIFO seems to work a better although I > > haven't fully tested it yet. Maybe this information helps you get to > > a solution. You are right. > > > > I am keen to get tmpfs into the Freebsd tree and have been > > communicating with Rohit regarding this. He currently doesn't have > > time to do further improvements and I have offered to help get this > > tmpfs port into Freebsd. I am awaiting a response to this (we only > > started talking last week). > > > > This port has a few outstanding items: > > > > * MP safeness (some locking may be required). I have started testing > > tmpfs on an MP system. Can you try my WIP?(I can send you the patch against -Current) I add some basic locking stuffs. I am glad to work with you together. Now I don't have a MP system to test. > > * Security audit (not sure what's required for this) > > * Quota support, ACL work is pending Do we really need this? What's user scenerio to use Quota or ACL for a TMPFS? I can be conveienced. > > * Two data I/O mechanisms are benchmarked, deciding which one to use > > is still pending You can help. I really help to see you have interesting. It will be better if we can work together. Besides the locking & fifo fixing, I also working on the following tasks: 1. Catch up the main tree changes related FS after Rohit post his patch. 2. Port regression test cases 3. Remove un-named union so that tmpfs can build in a kernel -- -Howard From owner-freebsd-fs@FreeBSD.ORG Thu Apr 19 08:25:36 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2DA3116A400 for ; Thu, 19 Apr 2007 08:25:36 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id D985213C458 for ; Thu, 19 Apr 2007 08:25:35 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 596C52084; Thu, 19 Apr 2007 10:25:32 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 466612049; Thu, 19 Apr 2007 10:25:32 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 1727D5473; Thu, 19 Apr 2007 10:25:31 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: =?iso-8859-1?Q?St=E5le?= Kristoffersen References: <20070418104155.GA31727@eschew.pusen.org> <86hcrdlqak.fsf@dwp.des.no> <20070418144103.GB31727@eschew.pusen.org> <20070418155156.GB20441@keira.kiwi-computer.com> <20070418180200.GA32061@eschew.pusen.org> Date: Thu, 19 Apr 2007 10:25:31 +0200 In-Reply-To: <20070418180200.GA32061@eschew.pusen.org> (=?iso-8859-1?Q?St?= =?iso-8859-1?Q?=E5le?= Kristoffersen's message of "Wed, 18 Apr 2007 20:02:00 +0200") Message-ID: <86odlku5xg.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Rick C. Petty" , piso@freebsd.org, fs@freebsd.org Subject: Re: ZFS + replacing failing hard-drive. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 08:25:36 -0000 St=E5le Kristoffersen writes: > On 2007-04-18 at 10:51, Rick C. Petty wrote: > > On Wed, Apr 18, 2007 at 04:41:03PM +0200, St?le Kristoffersen wrote: > > > Same problem on all. And to support my theory that the disk was bad t= he new > > > disk does not behave badly, even after a zpool scrub. > > That doesn't prove the disk was/is "bad". [...] > The drive was new a couple of weeks ago, and it gave me errors > almost from the beginning. Yes. I have four brand new disks which are giving me DMA timeouts all the time. There seem to be bugs in (or in relation with) the ata driver which have surfaced only recently. Now that I think about it - could this be related to interrupt filtering? Piso? If the ata driver is losing interrupts, it's no wonder the transfers are timing out. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Thu Apr 19 11:10:36 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E76516A400 for ; Thu, 19 Apr 2007 11:10:36 +0000 (UTC) (envelope-from dayzofrift@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.231]) by mx1.freebsd.org (Postfix) with ESMTP id E03A113C483 for ; Thu, 19 Apr 2007 11:10:35 +0000 (UTC) (envelope-from dayzofrift@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so434701nza for ; Thu, 19 Apr 2007 04:10:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=WqH8W4dB8hj2KB9UbEE6qiqW7WZbu6mxznN7Z7cR3KlnYz4YVLQ7/iLQTDlRr3ZpEgLBFV6N/RgyZUpG691wRbVvi/cNf+PkMfluXqJy45XVnGg6ZBRzmMGiYJ9JAEA5/MKrjops8QBtocoRMTfov3vFpyS/Bg44u46N6Z+Suv8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=fMlW2kE5yNg4DPtd64JlQ+WQz+BReo9amNQnbIjnRE5MZoHh98oW9jOgR9+eidS/+AHwCQ5IQKcq8DUgVV8Nqi3iVDalb2S0jS9dPmPpdmq4j36wGZSphRuZUjqBZ/bb3VJAPwO614pQjTMywT62CbjwKplhxu/ulY4dA6i7+/U= Received: by 10.114.161.11 with SMTP id j11mr683431wae.1176981034948; Thu, 19 Apr 2007 04:10:34 -0700 (PDT) Received: by 10.114.202.1 with HTTP; Thu, 19 Apr 2007 04:10:34 -0700 (PDT) Message-ID: <87b02eb0704190410k4122f115u558df33ac2ed6413@mail.gmail.com> Date: Thu, 19 Apr 2007 13:10:34 +0200 From: Rift`` To: "Andrei Kolu" In-Reply-To: <200704190051.25639.antik@bsd.ee> MIME-Version: 1.0 References: <87b02eb0704180722q3f45095k5293cfa343ba8514@mail.gmail.com> <462634AC.1000403@freebsd.org> <87b02eb0704180827k1ea64e0ercedff7f9565983ce@mail.gmail.com> <200704190051.25639.antik@bsd.ee> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: Unable to umount ext3 partition X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 11:10:36 -0000 Thanks, it work fine. Rift 2007/4/18, Andrei Kolu : > > On Wednesday 18 April 2007 18:27, Rift`` wrote: > > it returns nothing: > > > > # fstat | grep ipodlinux > > # umount /mnt/ipodlinux/ > > umount: unmount of /mnt/ipodlinux failed: Device busy > > # > > > # umount -f > > -f The file system is forcibly unmounted. Active special > devices > continue to work, but all other files return errors if > further > accesses are attempted. The root file system cannot be > forcibly > unmounted. > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Thu Apr 19 14:57:32 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1058B16A401 for ; Thu, 19 Apr 2007 14:57:32 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (grnl-static-02-0046.dsl.iowatelecom.net [69.66.56.110]) by mx1.freebsd.org (Postfix) with ESMTP id 5C12F13C459 for ; Thu, 19 Apr 2007 14:57:31 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id l3JENRPc074849; Thu, 19 Apr 2007 09:23:27 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id l3JENQbw074848; Thu, 19 Apr 2007 09:23:26 -0500 (CDT) (envelope-from brooks) Date: Thu, 19 Apr 2007 09:23:26 -0500 From: Brooks Davis To: Howard Su Message-ID: <20070419142326.GB74693@lor.one-eyed-alien.net> References: <4626EA38.6010703@nokia.com> <4626F339.5040602@nokia.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RASg3xLB4tUQ4RcS" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Thu, 19 Apr 2007 09:23:27 -0500 (CDT) Cc: Glen , fs@freebsd.org Subject: Re: handle special file type in tmpfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 14:57:32 -0000 --RASg3xLB4tUQ4RcS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Apr 19, 2007 at 01:02:25AM -0700, Howard Su wrote: > >Glen wrote: > >> * Quota support, ACL work is pending > Do we really need this? What's user scenerio to use Quota or ACL for a > TMPFS? I can be conveienced. Extended attribute support would be useful on systems that use MAC so you wouldn't lose labels when copying files to the tmpfs (not having this might preclude use). Quotas a very useful on /tmp as a way to keep individual users from DoSing the system. I've had it happen by accident on my cluster where users wrote temporary files and didn't clean them up. At some point they totally ran the volume out of space and as a result PVM and MPI would fail very strangly when they couldn't create various files then needed. Having argued for these features, I don't believe either is critical. For most application neither is needed, but they would be useful in some cases. -- Brooks --RASg3xLB4tUQ4RcS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD4DBQFGJ3teXY6L6fI4GtQRAgStAJkBUt8AXtha9qnRIDcvIbsy/2t+4ACWNWzH B/nd2QZAcRQ76535qcMqZQ== =eu9D -----END PGP SIGNATURE----- --RASg3xLB4tUQ4RcS-- From owner-freebsd-fs@FreeBSD.ORG Thu Apr 19 17:33:21 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A289016A410 for ; Thu, 19 Apr 2007 17:33:21 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id 2E75213C448 for ; Thu, 19 Apr 2007 17:33:20 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 57346 invoked by uid 2001); 19 Apr 2007 17:33:16 -0000 Date: Thu, 19 Apr 2007 12:33:16 -0500 From: "Rick C. Petty" To: Dag-Erling Sm?rgrav Message-ID: <20070419173316.GA57227@keira.kiwi-computer.com> References: <20070418104155.GA31727@eschew.pusen.org> <86hcrdlqak.fsf@dwp.des.no> <20070418144103.GB31727@eschew.pusen.org> <20070418155156.GB20441@keira.kiwi-computer.com> <20070418180200.GA32061@eschew.pusen.org> <86odlku5xg.fsf@dwp.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86odlku5xg.fsf@dwp.des.no> User-Agent: Mutt/1.4.2.1i Cc: piso@freebsd.org, fs@freebsd.org Subject: Re: ZFS + replacing failing hard-drive. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 17:33:21 -0000 On Thu, Apr 19, 2007 at 10:25:31AM +0200, Dag-Erling Sm?rgrav wrote: > > Yes. I have four brand new disks which are giving me DMA timeouts all > the time. > > There seem to be bugs in (or in relation with) the ata driver which > have surfaced only recently. > > Now that I think about it - could this be related to interrupt > filtering? Piso? If the ata driver is losing interrupts, it's no > wonder the transfers are timing out. What do you mean by recently? I've seen this problem which started around 5.4-RELEASE (perhaps earlier) and on, including 6.0-R thru 6.2-stable as of a few weeks ago. Would the interrupt filtering be present on these systems? -- Rick C. Petty From owner-freebsd-fs@FreeBSD.ORG Thu Apr 19 19:10:52 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9687216A404; Thu, 19 Apr 2007 19:10:52 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 538C013C469; Thu, 19 Apr 2007 19:10:52 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id B2FAB2084; Thu, 19 Apr 2007 21:10:48 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 334B72083; Thu, 19 Apr 2007 21:10:48 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 1AA98540C; Thu, 19 Apr 2007 21:10:48 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: rick-freebsd@kiwi-computer.com References: <20070418104155.GA31727@eschew.pusen.org> <86hcrdlqak.fsf@dwp.des.no> <20070418144103.GB31727@eschew.pusen.org> <20070418155156.GB20441@keira.kiwi-computer.com> <20070418180200.GA32061@eschew.pusen.org> <86odlku5xg.fsf@dwp.des.no> <20070419173316.GA57227@keira.kiwi-computer.com> Date: Thu, 19 Apr 2007 21:10:48 +0200 In-Reply-To: <20070419173316.GA57227@keira.kiwi-computer.com> (Rick C. Petty's message of "Thu, 19 Apr 2007 12:33:16 -0500") Message-ID: <863b2w41tz.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: piso@freebsd.org, fs@freebsd.org Subject: Re: ZFS + replacing failing hard-drive. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 19:10:52 -0000 "Rick C. Petty" writes: > What do you mean by recently? I've seen this problem which started around > 5.4-RELEASE (perhaps earlier) and on, including 6.0-R thru 6.2-stable as = of > a few weeks ago. Would the interrupt filtering be present on these > systems? No, and in fact it's not used by the ata driver in -CURRENT, so it's probably not relevant. I said recently because I didn't start having these problems until around early march. However, this could be due to changes in usage patterns. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Thu Apr 19 19:17:25 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E76416A414 for ; Thu, 19 Apr 2007 19:17:25 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id 99C0D13C4AE for ; Thu, 19 Apr 2007 19:17:22 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 59963 invoked by uid 2001); 19 Apr 2007 19:17:21 -0000 Date: Thu, 19 Apr 2007 14:17:21 -0500 From: "Rick C. Petty" To: Dag-Erling Sm?rgrav Message-ID: <20070419191721.GA59824@keira.kiwi-computer.com> References: <20070418104155.GA31727@eschew.pusen.org> <86hcrdlqak.fsf@dwp.des.no> <20070418144103.GB31727@eschew.pusen.org> <20070418155156.GB20441@keira.kiwi-computer.com> <20070418180200.GA32061@eschew.pusen.org> <86odlku5xg.fsf@dwp.des.no> <20070419173316.GA57227@keira.kiwi-computer.com> <863b2w41tz.fsf@dwp.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <863b2w41tz.fsf@dwp.des.no> User-Agent: Mutt/1.4.2.1i Cc: piso@freebsd.org, fs@freebsd.org Subject: Re: ZFS + replacing failing hard-drive. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 19:17:25 -0000 On Thu, Apr 19, 2007 at 09:10:48PM +0200, Dag-Erling Sm?rgrav wrote: > "Rick C. Petty" writes: > > What do you mean by recently? I've seen this problem which started around > > 5.4-RELEASE (perhaps earlier) and on, including 6.0-R thru 6.2-stable as of > > a few weeks ago. Would the interrupt filtering be present on these > > systems? > > No, and in fact it's not used by the ata driver in -CURRENT, so it's > probably not relevant. > > I said recently because I didn't start having these problems until > around early march. However, this could be due to changes in usage > patterns. Oh. :( Okay. I had hoped otherwise... I'm in the process of looking at the commands sent to the PDC chips from linux's sata_promise driver and comparing what's different about ours. Linux properly reinitialized the card (tested with rmmod & modprobe), but the command which is causing the drives to be reprobed may affect the whole card vs. a single channel. I'll have time to play around with the FreeBSD kernel this weekend. Unfortunately, I couldn't figure out a way in linux to drop just a channel and reattach it, and I didn't see anything in their code which handles this case. However, I'd rather have the whole Promise card pause while reinitializing all channels than not be able to bring up a single channel. Still, it would be useful to figure out the cause of the DMA failures and avoid this altogether. Anyone volunteering to help? sos@ ? -- Rick C. Petty From owner-freebsd-fs@FreeBSD.ORG Thu Apr 19 22:42:52 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4E1C16A402; Thu, 19 Apr 2007 22:42:52 +0000 (UTC) (envelope-from david.cecil@nokia.com) Received: from mgw-ext14.nokia.com (smtp.nokia.com [131.228.20.173]) by mx1.freebsd.org (Postfix) with ESMTP id 579D313C483; Thu, 19 Apr 2007 22:42:52 +0000 (UTC) (envelope-from david.cecil@nokia.com) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3JMOwOC011596; Fri, 20 Apr 2007 01:25:10 +0300 Received: from siebh101.NOE.Nokia.com ([172.30.195.27]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 01:24:08 +0300 Received: from syebe101.NOE.Nokia.com ([172.30.128.65]) by siebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 06:24:05 +0800 Received: from [172.30.67.180] ([172.30.67.180]) by syebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 08:24:03 +1000 Message-ID: <4627EC02.8070103@nokia.com> Date: Fri, 20 Apr 2007 08:24:02 +1000 From: David Cecil User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: rick-freebsd@kiwi-computer.com References: <20070418104155.GA31727@eschew.pusen.org> <86hcrdlqak.fsf@dwp.des.no> <20070418144103.GB31727@eschew.pusen.org> <20070418155156.GB20441@keira.kiwi-computer.com> <20070418180200.GA32061@eschew.pusen.org> <86odlku5xg.fsf@dwp.des.no> <20070419173316.GA57227@keira.kiwi-computer.com> In-Reply-To: <20070419173316.GA57227@keira.kiwi-computer.com> X-OriginalArrivalTime: 19 Apr 2007 22:24:03.0939 (UTC) FILETIME=[6FD58B30:01C782D1] X-eXpurgate-Category: 1/4 X-eXpurgate-ID: 149371::070420012513-2CE92BB0-0BFA2208/0-0/0-17 X-Nokia-AV: Clean Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Dag-Erling Sm?rgrav , fs@freebsd.org, piso@freebsd.org Subject: Re: ZFS + replacing failing hard-drive. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 22:42:52 -0000 I would like to second Rick's comments. I've certainly seen the problem in 6.0 and 6.1, and replacing older disks with new ones hasn't rectified the problem. Regards, Dave ext Rick C. Petty wrote: > On Thu, Apr 19, 2007 at 10:25:31AM +0200, Dag-Erling Sm?rgrav wrote: > >> Yes. I have four brand new disks which are giving me DMA timeouts all >> the time. >> >> There seem to be bugs in (or in relation with) the ata driver which >> have surfaced only recently. >> >> Now that I think about it - could this be related to interrupt >> filtering? Piso? If the ata driver is losing interrupts, it's no >> wonder the transfers are timing out. >> > > What do you mean by recently? I've seen this problem which started around > 5.4-RELEASE (perhaps earlier) and on, including 6.0-R thru 6.2-stable as of > a few weeks ago. Would the interrupt filtering be present on these > systems? > > -- Rick C. Petty > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Thu Apr 19 23:12:54 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50C7216A400 for ; Thu, 19 Apr 2007 23:12:54 +0000 (UTC) (envelope-from Glen.Leeder@nokia.com) Received: from mgw-ext14.nokia.com (smtp.nokia.com [131.228.20.173]) by mx1.freebsd.org (Postfix) with ESMTP id CDD1C13C4C6 for ; Thu, 19 Apr 2007 23:12:53 +0000 (UTC) (envelope-from Glen.Leeder@nokia.com) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3JMssfM016604; Fri, 20 Apr 2007 01:54:55 +0300 Received: from siebh102.NOE.Nokia.com ([172.30.195.29]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 01:54:54 +0300 Received: from syebe101.NOE.Nokia.com ([172.30.128.65]) by siebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 06:54:52 +0800 Received: from [172.30.67.179] ([172.30.67.179]) by syebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 08:54:50 +1000 Message-ID: <4627F32C.4030301@nokia.com> Date: Fri, 20 Apr 2007 08:54:36 +1000 From: Glen User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Howard Su References: <4626EA38.6010703@nokia.com> <4626F339.5040602@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2007 22:54:50.0848 (UTC) FILETIME=[BCAD7E00:01C782D5] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070420015455-4088FBB0-4BE65665/0-0/0-0 X-Nokia-AV: Clean Cc: fs@freebsd.org Subject: Re: handle special file type in tmpfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 23:12:54 -0000 ext Howard Su wrote: >> Glen wrote: >> > Hi Howard, >> > >> > May I ask if you are using the tmpfs port by Rohit Jalan? A link to >> > his work can be found on this page: >> > http://www.freebsd.org/projects/ideas/ > Yes. The ideas page bring me to this working. > >> > >> > I am currently using the BETA3 tmpfs port and have experienced an >> > issue with the FIFO support for tmpfs. I believe that this is because >> > the tmpfs_fifoops.c specifies an incomplete vnode operations vector >> > (vop_vector) for tmpfs. The vop_vector allows you to specify all the >> > vnode operations for a particular filesystem. > I already fix that in my WIP. you can check the code in the perforce. > http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/howardsu/truss/sys/fs/tmpfs > > My working currently based on Beta3. >> > >> > If you check out ufs/ufs_vnops.c it specifies a global vop vector for >> > most file types and then a different vop_vector for FIFO file types. >> > Rohit's tmpfs port does a similar thing. I have populated the tmpfs >> > vop_vector in this port and FIFO seems to work a better although I >> > haven't fully tested it yet. Maybe this information helps you get to >> > a solution. > You are right. > >> > >> > I am keen to get tmpfs into the Freebsd tree and have been >> > communicating with Rohit regarding this. He currently doesn't have >> > time to do further improvements and I have offered to help get this >> > tmpfs port into Freebsd. I am awaiting a response to this (we only >> > started talking last week). >> > >> > This port has a few outstanding items: >> > >> > * MP safeness (some locking may be required). I have started testing >> > tmpfs on an MP system. > Can you try my WIP?(I can send you the patch against -Current) I add > some basic locking stuffs. I am glad to work with you together. Now I > don't have a MP system to test. I'll be very happy to try it out and should get a chance to try it today. I think I may need to look for/write some test software to exercise the code in an MP scenario unless you already know of a regression test that does this. >> > * Security audit (not sure what's required for this) >> > * Quota support, ACL work is pending > Do we really need this? What's user scenerio to use Quota or ACL for a > TMPFS? I can be conveienced. I guess not for the first release. I just mentioned this list as I know these things were not yet done. I see that Brook has expressed an interest in some of this stuff but also mentions it is not critical. > >> > * Two data I/O mechanisms are benchmarked, deciding which one to use >> > is still pending > You can help. > > I really help to see you have interesting. It will be better if we can > work together. Besides the locking & fifo fixing, I also working on > the following tasks: > 1. Catch up the main tree changes related FS after Rohit post his patch. > 2. Port regression test cases > 3. Remove un-named union so that tmpfs can build in a kernel I will be glad to help in any way I can. I will start with the MP system testing. Please let me know if you are aware of any other problems or tasks that I can help with. > > From owner-freebsd-fs@FreeBSD.ORG Thu Apr 19 23:24:59 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7042C16A401; Thu, 19 Apr 2007 23:24:59 +0000 (UTC) (envelope-from fbsd-fs@mawer.org) Received: from customer-domains.icp-qv1-irony14.iinet.net.au (customer-domains.icp-qv1-irony14.iinet.net.au [203.59.1.169]) by mx1.freebsd.org (Postfix) with ESMTP id B0B1513C459; Thu, 19 Apr 2007 23:24:58 +0000 (UTC) (envelope-from fbsd-fs@mawer.org) Received: from 203-206-173-235.perm.iinet.net.au (HELO [10.24.1.1]) ([203.206.173.235]) by iinet-mail.icp-qv1-irony14.iinet.net.au with ESMTP; 20 Apr 2007 07:14:13 +0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAByUJ0bLzq3r/2dsb2JhbAAN X-IronPort-AV: i="4.14,429,1170601200"; d="scan'208"; a="56706335:sNHT7364964" Message-ID: <4627F7BE.5090606@mawer.org> Date: Fri, 20 Apr 2007 09:14:06 +1000 From: Antony Mawer User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: David Cecil References: <20070418104155.GA31727@eschew.pusen.org> <86hcrdlqak.fsf@dwp.des.no> <20070418144103.GB31727@eschew.pusen.org> <20070418155156.GB20441@keira.kiwi-computer.com> <20070418180200.GA32061@eschew.pusen.org> <86odlku5xg.fsf@dwp.des.no> <20070419173316.GA57227@keira.kiwi-computer.com> <4627EC02.8070103@nokia.com> In-Reply-To: <4627EC02.8070103@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dag-Erling Sm?rgrav , rick-freebsd@kiwi-computer.com, piso@freebsd.org, fs@freebsd.org Subject: Re: ZFS + replacing failing hard-drive. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 23:24:59 -0000 On 20/04/2007 8:24 AM, David Cecil wrote: > ext Rick C. Petty wrote: >> On Thu, Apr 19, 2007 at 10:25:31AM +0200, Dag-Erling Sm?rgrav wrote: >> >>> Yes. I have four brand new disks which are giving me DMA timeouts all >>> the time. >>> >>> There seem to be bugs in (or in relation with) the ata driver which >>> have surfaced only recently. >>> >>> Now that I think about it - could this be related to interrupt >>> filtering? Piso? If the ata driver is losing interrupts, it's no >>> wonder the transfers are timing out. >>> >> >> What do you mean by recently? I've seen this problem which started >> around >> 5.4-RELEASE (perhaps earlier) and on, including 6.0-R thru 6.2-stable >> as of >> a few weeks ago. Would the interrupt filtering be present on these >> systems? > > I would like to second Rick's comments. I've certainly seen the problem > in 6.0 and 6.1, and replacing older disks with new ones hasn't rectified > the problem. > > Regards, > Dave Just another "me too". I've seen (S)ATA-related problems on 6.x (mostly 6.0) based machines, in some cases these appear to have been physical drive errors, but I haven't been able to verify each individual case. I don't know if quality control is sorely lacking on newer SATA drives or if it's something else... it has caused me to question whether or not there might be a driver/OS level issue... --Antony From owner-freebsd-fs@FreeBSD.ORG Fri Apr 20 00:41:34 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 942B016A404 for ; Fri, 20 Apr 2007 00:41:34 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id 9E67213C4BD for ; Fri, 20 Apr 2007 00:41:33 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 67576 invoked by uid 2001); 20 Apr 2007 00:41:31 -0000 Date: Thu, 19 Apr 2007 19:41:31 -0500 From: "Rick C. Petty" To: Antony Mawer Message-ID: <20070420004131.GA65715@keira.kiwi-computer.com> References: <20070418104155.GA31727@eschew.pusen.org> <86hcrdlqak.fsf@dwp.des.no> <20070418144103.GB31727@eschew.pusen.org> <20070418155156.GB20441@keira.kiwi-computer.com> <20070418180200.GA32061@eschew.pusen.org> <86odlku5xg.fsf@dwp.des.no> <20070419173316.GA57227@keira.kiwi-computer.com> <4627EC02.8070103@nokia.com> <4627F7BE.5090606@mawer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4627F7BE.5090606@mawer.org> User-Agent: Mutt/1.4.2.1i Cc: piso@freebsd.org, fs@freebsd.org Subject: Re: ZFS + replacing failing hard-drive. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 00:41:34 -0000 On Fri, Apr 20, 2007 at 09:14:06AM +1000, Antony Mawer wrote: > > Just another "me too". I've seen (S)ATA-related problems on 6.x (mostly > 6.0) based machines, in some cases these appear to have been physical > drive errors, but I haven't been able to verify each individual case. I > don't know if quality control is sorely lacking on newer SATA drives or > if it's something else... it has caused me to question whether or not > there might be a driver/OS level issue... I'm reluctant to point fingers at the drives (although this is often a good first guess).. I have access to a few dozen disks from two separate SATA batches. I've noticed that when the identical drives are on the same Promise controller, FreeBSD reports DMA timeouts occasionally. I've never seen anything similar on Ubuntu, although since the timeouts are unpredictable it's possible there may be throughput differences between the two OSes. -- Rick C. Petty From owner-freebsd-fs@FreeBSD.ORG Fri Apr 20 03:45:25 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F0CB716A400; Fri, 20 Apr 2007 03:45:25 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id B003B13C484; Fri, 20 Apr 2007 03:45:25 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id D8820207E; Fri, 20 Apr 2007 05:45:21 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 595C52049; Fri, 20 Apr 2007 05:45:21 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 17269545F; Fri, 20 Apr 2007 05:45:21 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: rick-freebsd@kiwi-computer.com References: <20070418104155.GA31727@eschew.pusen.org> <86hcrdlqak.fsf@dwp.des.no> <20070418144103.GB31727@eschew.pusen.org> <20070418155156.GB20441@keira.kiwi-computer.com> <20070418180200.GA32061@eschew.pusen.org> <86odlku5xg.fsf@dwp.des.no> <20070419173316.GA57227@keira.kiwi-computer.com> <4627EC02.8070103@nokia.com> <4627F7BE.5090606@mawer.org> <20070420004131.GA65715@keira.kiwi-computer.com> Date: Fri, 20 Apr 2007 05:45:20 +0200 In-Reply-To: <20070420004131.GA65715@keira.kiwi-computer.com> (Rick C. Petty's message of "Thu, 19 Apr 2007 19:41:31 -0500") Message-ID: <86ejmfbtf3.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: fs@freebsd.org, piso@freebsd.org Subject: Re: ZFS + replacing failing hard-drive. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 03:45:26 -0000 "Rick C. Petty" writes: > I'm reluctant to point fingers at the drives (although this is often a go= od > first guess).. I have access to a few dozen disks from two separate SATA > batches. I've noticed that when the identical drives are on the same > Promise controller, FreeBSD reports DMA timeouts occasionally. Interesting. All my DMA timeout issues have indeed been with groups of identical drives (though different groups from different manufacturers) DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Fri Apr 20 05:28:52 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37F0216A402; Fri, 20 Apr 2007 05:28:52 +0000 (UTC) (envelope-from david.cecil@nokia.com) Received: from mgw-ext14.nokia.com (smtp.nokia.com [131.228.20.173]) by mx1.freebsd.org (Postfix) with ESMTP id AC97713C44B; Fri, 20 Apr 2007 05:28:51 +0000 (UTC) (envelope-from david.cecil@nokia.com) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3K5SE6V023636; Fri, 20 Apr 2007 08:28:46 +0300 Received: from siebh102.NOE.Nokia.com ([172.30.195.29]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 07:52:28 +0300 Received: from syebe101.NOE.Nokia.com ([172.30.128.65]) by siebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 12:52:20 +0800 Received: from [172.30.67.180] ([172.30.67.180]) by syebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 14:52:18 +1000 Message-ID: <46284701.8080107@nokia.com> Date: Fri, 20 Apr 2007 14:52:17 +1000 From: David Cecil User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: rick-freebsd@kiwi-computer.com References: <20070418104155.GA31727@eschew.pusen.org> <86hcrdlqak.fsf@dwp.des.no> <20070418144103.GB31727@eschew.pusen.org> <20070418155156.GB20441@keira.kiwi-computer.com> <20070418180200.GA32061@eschew.pusen.org> <86odlku5xg.fsf@dwp.des.no> <20070419173316.GA57227@keira.kiwi-computer.com> <4627EC02.8070103@nokia.com> <4627F7BE.5090606@mawer.org> <20070420004131.GA65715@keira.kiwi-computer.com> In-Reply-To: <20070420004131.GA65715@keira.kiwi-computer.com> X-OriginalArrivalTime: 20 Apr 2007 04:52:18.0467 (UTC) FILETIME=[AC746F30:01C78307] X-eXpurgate-Category: 1/4 X-eXpurgate-ID: 149371::070420082849-5C0A6BB0-1AF2FD9E/0-0/0-17 X-Nokia-AV: Clean Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: fs@freebsd.org, piso@freebsd.org Subject: Re: ZFS + replacing failing hard-drive. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 05:28:52 -0000 Just to be clear, I've seen these errors for SATA and PATA drives. Dave ext Rick C. Petty wrote: > On Fri, Apr 20, 2007 at 09:14:06AM +1000, Antony Mawer wrote: > >> Just another "me too". I've seen (S)ATA-related problems on 6.x (mostly >> 6.0) based machines, in some cases these appear to have been physical >> drive errors, but I haven't been able to verify each individual case. I >> don't know if quality control is sorely lacking on newer SATA drives or >> if it's something else... it has caused me to question whether or not >> there might be a driver/OS level issue... >> > > I'm reluctant to point fingers at the drives (although this is often a good > first guess).. I have access to a few dozen disks from two separate SATA > batches. I've noticed that when the identical drives are on the same > Promise controller, FreeBSD reports DMA timeouts occasionally. I've never > seen anything similar on Ubuntu, although since the timeouts are > unpredictable it's possible there may be throughput differences between the > two OSes. > > -- Rick C. Petty > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > -- Software Engineer Secure and Mobile Connectivity Enterprise Solutions Nokia +61 7 5553 8307 (office) +61 412 728 222 (cell) From owner-freebsd-fs@FreeBSD.ORG Fri Apr 20 10:59:00 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A38D16A403 for ; Fri, 20 Apr 2007 10:59:00 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from mail04.solnet.ch (mail04.solnet.ch [212.101.4.138]) by mx1.freebsd.org (Postfix) with ESMTP id 8318D13C458 for ; Fri, 20 Apr 2007 10:58:59 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) X-Virus-Scanned: by amavisd-new at mail04.solnet.ch Received: from mail04.solnet.ch ([127.0.0.1]) by localhost (mail04.solnet.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RI8l31Y1Z3Ql for ; Fri, 20 Apr 2007 10:32:36 +0000 (UTC) Received: from [192.168.1.102] (home.bsdunix.ch [82.220.17.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail04.solnet.ch (Postfix) with ESMTP id DA53062834 for ; Fri, 20 Apr 2007 10:32:35 +0000 (UTC) Message-ID: <462896C3.6040402@bsdunix.ch> Date: Fri, 20 Apr 2007 12:32:35 +0200 From: Thomas User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Subject: FS (gjournal?) releated crashes with current? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 10:59:00 -0000 Hello I triggered several crashes with 7-Current from 2007-04-19. The system mostly crashes if I'm syncing data with 4-5 parallel rsync processes. Most debug options are disabled in my kernel and malloc was compiled with MALLOC_PRODUCTION. I use GJournal (/dev/da0.journal) on a SATA Raid6 created with an areca 1230 controller. The Raid status is fine. # mount /dev/ad4s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad4s1g on /disk1 (ufs, local, soft-updates) /dev/ad4s1d on /tmp (ufs, local, soft-updates) /dev/ad4s1f on /usr (ufs, local, soft-updates) /dev/ad4s1e on /var (ufs, local, soft-updates) /dev/da0.journal on /usr/local/data (ufs, asynchronous, local, noatime, gjournal) After every crash /dev/da0.journal is marked as clean but when I do full fsck i got: # umount /usr/local/data # fsck -y /usr/local/data ** /dev/da0.journal ** Last Mounted on /usr/local/data ** Phase 1 - Check Blocks and Sizes PARTIALLY TRUNCATED INODE I=150149446 SALVAGE? yes -4415861736689041919 BAD I=150149446 6180257590692086610 BAD I=150149446 7624567997605723585 BAD I=150149446 8268956604991674674 BAD I=150149446 2342221461849545187 BAD I=150149446 -292497344028865874 BAD I=150149446 -5568323556661920569 BAD I=150149446 -7916380230741665943 BAD I=150149446 4170928977557909368 BAD I=150149446 4450577158601375817 BAD I=150149446 1180086702901020396 BAD I=150149446 EXCESSIVE BAD BLKS I=150149446 CONTINUE? yes INCORRECT BLOCK COUNT I=150149446 (1856 should be 736) CORRECT? yes PARTIALLY TRUNCATED INODE I=151138150 SALVAGE? yes .... .... and many more. I have 2 core dumpes: lisa# cat /var/crash/info.6 Dump header from device /dev/ad4s1b Architecture: i386 Architecture Version: 2 Dump Length: 328253440B (313 MB) Blocksize: 512 Dumptime: Fri Apr 20 08:51:51 2007 Hostname: lisa.mlan.solnet.ch Magic: FreeBSD Kernel Dump Version String: FreeBSD 7.0-CURRENT #0: Thu Apr 19 09:14:51 UTC 2007 root@lisa.mlan.solnet.ch:/usr/obj/usr/src/sys/UP7_SATA Panic String: ffs_valloc: dup alloc Dump Parity: 949538821 Bounds: 6 Dump Status: good lisa# kgdb kernel.debug /var/crash/vmcore.6 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: mode = 0100644, inum = 154219448, fs = /usr/local/data panic: ffs_valloc: dup alloc Uptime: 7h47m45s Physical memory: 3445 MB Dumping 313 MB: 298 282 266 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10 #0 doadump () at pcpu.h:172 172 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:172 #1 0xc0597df8 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0598088 in panic (fmt=0xc0773469 "ffs_valloc: dup alloc") at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc06aa4f8 in ffs_valloc (pvp=0xc7a1daa0, mode=33152, cred=0xcbd66300, vpp=0xe9040888) at /usr/src/sys/ufs/ffs/ffs_alloc.c:966 #4 0xc06d552f in ufs_makeinode (mode=33152, dvp=0xc7a1daa0, vpp=0xe9040b98, cnp=0xe9040bac) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2238 #5 0xc06d24e5 in ufs_create (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:188 #6 0xc0730294 in VOP_CREATE_APV (vop=0x0, a=0xe9040a1c) at vnode_if.c:206 #7 0xc0603644 in vn_open_cred (ndp=0xe9040b84, flagp=0xe9040c84, cmode=384, cred=0xcbd66300, fdidx=0) at vnode_if.h:111 #8 0xc060346a in vn_open (ndp=0x0, flagp=0xe9040c84, cmode=384, fdidx=6) at /usr/src/sys/kern/vfs_vnops.c:93 #9 0xc05fdbc7 in kern_open (td=0xc91026c0, path=0x0, pathseg=UIO_USERSPACE, flags=2563, mode=384) at /usr/src/sys/kern/vfs_syscalls.c:987 #10 0xc05fdb0c in open (td=0xc91026c0, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:954 #11 0xc07200e2 in syscall (frame=0xe9040d38) at /usr/src/sys/i386/i386/trap.c:1016 #12 0xc0710440 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #13 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) lisa# cat /var/crash/info.7 Dump header from device /dev/ad4s1b Architecture: i386 Architecture Version: 2 Dump Length: 298967040B (285 MB) Blocksize: 512 Dumptime: Fri Apr 20 09:55:56 2007 Hostname: lisa.mlan.solnet.ch Magic: FreeBSD Kernel Dump Version String: FreeBSD 7.0-CURRENT #0: Thu Apr 19 09:14:51 UTC 2007 root@lisa.mlan.solnet.ch:/usr/obj/usr/src/sys/UP7_SATA Panic String: sbdrop Dump Parity: 487915010 Bounds: 7 Dump Status: good isa# kgdb kernel.debug /var/crash/vmcore.7 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: panic: sbdrop Uptime: 1h1m12s Physical memory: 3445 MB Dumping 285 MB: 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 #0 doadump () at pcpu.h:172 172 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:172 #1 0xc0597df8 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0598088 in panic (fmt=0xc0768744 "sbdrop") at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc05d8278 in sbdrop_internal (sb=0xc6ecf8ec, len=432) at /usr/src/sys/kern/uipc_sockbuf.c:846 #4 0xc05d8442 in sbdrop_locked (sb=0xc6ecf8ec, len=492) at /usr/src/sys/kern/uipc_sockbuf.c:896 #5 0xc0646828 in tcp_do_segment (m=0xc6a75100, th=0xc6a45824, so=0xc6ecf828, tp=0xccbd616c, drop_hdrlen=40, tlen=0) at /usr/src/sys/netinet/tcp_input.c:2191 #6 0xc0645439 in tcp_input (m=0xc6a75100, off0=20) at /usr/src/sys/netinet/tcp_input.c:994 #7 0xc063def1 in ip_input (m=0xc6a75100) at /usr/src/sys/netinet/ip_input.c:662 #8 0xc06184b8 in netisr_dispatch (num=2, m=0x0) at /usr/src/sys/net/netisr.c:278 #9 0xc06108f1 in ether_demux (ifp=0xc66bdc00, m=0xc6a75100) at /usr/src/sys/net/if_ethersubr.c:843 #10 0xc0610763 in ether_input (ifp=0xc66bdc00, m=0xc6a75100) at /usr/src/sys/net/if_ethersubr.c:701 #11 0xc04dc535 in bge_rxeof (sc=0xc66c8000) at /usr/src/sys/dev/bge/if_bge.c:2949 #12 0xc04dca0c in bge_intr (xsc=0xc66c8000) at /usr/src/sys/dev/bge/if_bge.c:3127 #13 0xc05819c6 in ithread_execute_handlers (p=0xc6682480, ie=0xc65ce600) at /usr/src/sys/kern/kern_intr.c:682 #14 0xc0581ad8 in ithread_loop (arg=0xc66a9a50) at /usr/src/sys/kern/kern_intr.c:766 #15 0xc05809aa in fork_exit (callout=0xc0581a84 , arg=0xc66a9a50, frame=0xe6c6fd38) at /usr/src/sys/kern/kern_fork.c:814 #16 0xc0710450 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 System information: uname -a FreeBSD lisa.mlan.solnet.ch 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Thu Apr 19 09:14:51 UTC 2007 root@lisa.mlan.solnet.ch:/usr/obj/usr/src/sys/UP7_SATA i386 dmesg: Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #0: Thu Apr 19 09:14:51 UTC 2007 root@lisa.mlan.solnet.ch:/usr/obj/usr/src/sys/UP7_SATA module_register: module g_journal already exists! Module g_journal failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.13-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf62 Stepping = 2 Features=0xbfebfbff Features2=0xe41d> AMD Features=0x20100000 AMD Features2=0x1 Logical CPUs per core: 2 real memory = 3622305792 (3454 MB) avail memory = 3545190400 (3380 MB) kbd1 at kbdmux0 cpu0 on motherboard pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 pcib1: irq 10 at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 arcmsr0: > mem 0xdc500000-0xdc500fff,0xdc000000-0xdc3fffff irq 11 at device 14.0 on pci2 ARECA RAID ADAPTER0: Driver Version 1.20.00.14 2007-2-05 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.42 2006-10-13 arcmsr0: [ITHREAD] pcib3: at device 0.2 on pci1 pci3: on pcib3 pcib4: irq 10 at device 28.0 on pci0 pci4: on pcib4 pcib5: at device 28.4 on pci0 pci5: on pcib5 pci5:0:0: bad VPD cksum, remain 14 bge0: mem 0xdc600000-0xdc60ffff irq 10 at device 0.0 on pci5 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:e0:81:5d:b8:7b bge0: [ITHREAD] pcib6: at device 28.5 on pci0 pci6: on pcib6 pci6:0:0: bad VPD cksum, remain 14 bge1: mem 0xdc700000-0xdc70ffff irq 11 at device 0.0 on pci6 miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:e0:81:5d:b8:7c bge1: [ITHREAD] uhci0: port 0x3000-0x301f irq 5 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x3020-0x303f irq 10 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x3040-0x305f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x3060-0x307f irq 10 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xdca00000-0xdca003ff irq 5 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: waiting for BIOS to give up control usb4: timed out waiting for BIOS usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib7: at device 30.0 on pci0 pci10: on pcib7 vgapci0: port 0x4000-0x407f mem 0xd8000000-0xdbffffff,0xdc400000-0xdc43ffff at device 1.0 on pci10 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x30e8-0x30ef,0x30dc-0x30df,0x30e0-0x30e7,0x30d8-0x30db,0x30b0-0x30bf mem 0xdca00400-0xdca007ff irq 10 at device 31.2 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xe0000-0xe17ff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio0: [FILTER] sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio1: [FILTER] vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (memory) unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounter "TSC" frequency 3000130965 Hz quality 800 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert enabled, rule-based forwarding enabled, default to accept, logging limited to 100 packets/entry by default Waiting 5 seconds for SCSI devices to settle The GEOM class JOURNAL is already loaded. acd0: CDROM at ata0-master PIO4 ad4: 238475MB at ata2-master SATA150 da0 at arcmsr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da0: 2097129MB (4294920192 512 byte sectors: 255H 63S/T 267346C) cd0 at ata0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present GEOM_JOURNAL: Journal 1974089085: da0 contains data. GEOM_JOURNAL: Journal 1974089085: da0 contains journal. GEOM_JOURNAL: Journal da0 clean. Trying to mount root from ufs:/dev/ad4s1a bge0: link state changed to UP bge1: link state changed to UP boot/loader.conf: geom_journal_load="YES" kern.dfldsiz="1G" kern.maxdsiz="1G" sysctl.conf: net.inet.ip.random_id=1 net.inet.tcp.blackhole=1 net.inet.udp.blackhole=1 net.inet.icmp.drop_redirect=1 net.inet.ip.fw.one_pass=0 kern.maxfiles=65536 kern.maxfilesperproc=32768 More information needed? Cheers, Thomas From owner-freebsd-fs@FreeBSD.ORG Fri Apr 20 12:44:06 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0A6D16A400 for ; Fri, 20 Apr 2007 12:44:05 +0000 (UTC) (envelope-from mike@nux.co.uk) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5473113C458 for ; Fri, 20 Apr 2007 12:44:05 +0000 (UTC) (envelope-from mike@nux.co.uk) Received: from office.nux.co.uk (unknown [82.133.40.67]) by smtp.nildram.co.uk (Postfix) with ESMTP id 8309A2B7032 for ; Fri, 20 Apr 2007 13:44:01 +0100 (BST) Received: (qmail 47823 invoked by uid 2223); 20 Apr 2007 12:44:03 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Apr 2007 12:44:03 -0000 Date: Fri, 20 Apr 2007 13:44:03 +0100 (BST) From: Mike Wolman X-X-Sender: mike@nux.eros.office To: freebsd-geom@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20070420133854.G45782@nux.eros.office> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-767011191-1177073043=:45782" Cc: Subject: lazy mirror / live backup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 12:44:06 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-767011191-1177073043=:45782 Content-Type: TEXT/PLAIN; charset=uk.cp850.kbd; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi List, I'd like the ability to have gmirror do a more efficient re-silvering (or= =20 re-syncing) of the mirror members when a planned disconnect occurs. This=20 would significantly reduce the mirror rebuild time for any component which= =20 had been deactivated, for network mirrors using ggated devices this would= =20 also reduce network usage and could be used for remote asynced mirrors=20 thus providing a live backup for laptops/workstations. Main Points When a normal mirror breaks this module must keep track of which block in= =20 the mirror have changed. - This can be done by keeping a list/map of just the block which change. - This list/map needs to be stored on a device not provided by the mirror= =20 or in memory. If this list is stored in memory on rebooting the machine any= =20 deattached drive would require a full resync so a way of saving dumping=20 this list to permanent storage would be required as this would be a=20 problem for large mirrors over slow links. Example uses: Usb/Firewire external drive nightly full backup. If a mirror is contracted with 3 components: ad1, umass1 and umass2 umass1 and umass2 are backup devices taken home on alternate nights by=20 different users, always allowing for a device to have a full 1 day old=20 backup at a remote location. This module should be able to use the change log for multiple devices=20 preserving the changes until all components are upto date. Should one of= =20 the usb devices fail and is removed from the mirror the change log should= =20 be cleared (provided all other components are upto date) allowing for=20 drive failers and stopping the block change log growing indefinitely. It= =20 should be possible to use the same change log for more than one device. Normal full backups to usb devices can take many hours, this should reduce= =20 the time to only the amount of data added within the period the device was= =20 last attached to the mirror. Example use for disaster recovery - slow links: If the mirror consist of 2 components ad1 and ggatec1 with component=20 ggatec1 being on a slow link. A flush period tuneable could be used by deactivating the ggatec component= =20 and reactivating it allowing for an asynchronous mirror - =E1 la rsync but= =20 faster as there is no file list etc. A tuneable may be required to only sync blocks which have not been changed= =20 in xx seconds/minutes to prevent the same blocks being transferred too=20 often. A tuneable to specify the speed at which gmirror syncronises the out of=20 sync component will be required - This would possibly be useful for normal= =20 gmirror use on a busy server when rebuilding a drive, as gmirror currently= =20 uses all available write speed to do so - limiting rebuild speed may=20 therefore prevent drive failures. Live backup of laptop/workstation If the mirror is created using a local disk ad0 and a ggated mounted=20 device ggate0 with a balance algorithm preferring ad0. When the network is unavailable gmirror starts to keep track of the=20 changed blocks. On reconnection to the network and activating the ggatec=20 component the list of changed blocks can be flushed. Should the same=20 block have changed more than once only the last change needs to be sent -= =20 reducing network usage. The main problem with mirroring the whole system drive is that any swap=20 changes will need to be ignored. Other Considerations/Suggestions: - Gmirrror will need somehow need to be informed that a drive has actually= =20 failed and is not just temporarily disconnected. - Data structure consideration difference between a list of block numbers= =20 that have changed, and a block bitmap. A block bitmap is perfect for=20 this, and only requires 1bit per block of storage, max. No more. A list= =20 of block numbers can get *HUGE* though, because the block numbers are=20 probably all 64bit numbers, so it will be 64x the amount of space required= =20 to store the list, not to mention the issues of sorting and maintaining it - For determining the size of this 'block change map', you could use the=20 ceiling of the max number of blocks. so, a 100Gb storage mirror, would=20 have roughly 200000000 512b blocks. So, 200million bits (using a bitmap=20 to store when a block needs resyncing or not (0 no sync, 1 sync) is=20 roughly 24MB. You could pretty easily keep that in memory, but if the size= =20 was 1Tb, you'd be at around 240MB, so that starts to get a little much.=20 Since this would be able to be enabled/disabled, it may not be an issue. - Possibly, you could cheat. Instead of marking each storage block=20 (512byte sector) as needing sync or not, you could do it in 16KB chunks.=20 So, if any sector inside that 16KB chunk was written, resync the whole=20 chunk. That reduces your memory footprint for a 100GB mirror down to=20 something less than 1MB! That means a 1Tb mirror would need only 7-10MB.=20 You'll resync a little extra data, but since drives cache and the GEOM=20 layer does requests efficiently in larger sizes anyhow, this might=20 actually perform better anyway. If there is anyone has further suggestions for this idea please let me=20 know and if there are and developers interested in this i may be able to=20 provide/donate some hardware - sorry not new - a laptop, desktop and some= =20 hard drives - and can setup a machine for any network related testing. --0-767011191-1177073043=:45782-- From owner-freebsd-fs@FreeBSD.ORG Fri Apr 20 15:13:55 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19AC316A40A for ; Fri, 20 Apr 2007 15:13:55 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id 9B00113C46C for ; Fri, 20 Apr 2007 15:13:54 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 88207 invoked by uid 2001); 20 Apr 2007 15:13:53 -0000 Date: Fri, 20 Apr 2007 10:13:53 -0500 From: "Rick C. Petty" To: David Cecil Message-ID: <20070420151353.GA88152@keira.kiwi-computer.com> References: <86hcrdlqak.fsf@dwp.des.no> <20070418144103.GB31727@eschew.pusen.org> <20070418155156.GB20441@keira.kiwi-computer.com> <20070418180200.GA32061@eschew.pusen.org> <86odlku5xg.fsf@dwp.des.no> <20070419173316.GA57227@keira.kiwi-computer.com> <4627EC02.8070103@nokia.com> <4627F7BE.5090606@mawer.org> <20070420004131.GA65715@keira.kiwi-computer.com> <46284701.8080107@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46284701.8080107@nokia.com> User-Agent: Mutt/1.4.2.1i Cc: piso@freebsd.org, fs@freebsd.org Subject: Re: ZFS + replacing failing hard-drive. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 15:13:55 -0000 On Fri, Apr 20, 2007 at 02:52:17PM +1000, David Cecil wrote: > Just to be clear, I've seen these errors for SATA and PATA drives. Which controller chipsets? -- Rick C. Petty From owner-freebsd-fs@FreeBSD.ORG Fri Apr 20 20:47:12 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BBEAA16A407 for ; Fri, 20 Apr 2007 20:47:12 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [82.230.37.243]) by mx1.freebsd.org (Postfix) with ESMTP id 702B913C4C4 for ; Fri, 20 Apr 2007 20:47:12 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 92B403B082 for ; Fri, 20 Apr 2007 22:27:37 +0200 (CEST) Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92496-14 for ; Fri, 20 Apr 2007 22:27:37 +0200 (CEST) Received: by keltia.freenix.fr (Postfix/TLS, from userid 101) id 2E91F3B070; Fri, 20 Apr 2007 22:27:37 +0200 (CEST) Date: Fri, 20 Apr 2007 22:27:37 +0200 From: Ollivier Robert To: freebsd-fs@freebsd.org Message-ID: <20070420202737.GA92793@keltia.freenix.fr> References: <20070420133854.G45782@nux.eros.office> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070420133854.G45782@nux.eros.office> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 6.2 / Dell D820 SMP User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Subject: Re: lazy mirror / live backup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 20:47:12 -0000 According to Mike Wolman: > I'd like the ability to have gmirror do a more efficient re-silvering (or > re-syncing) of the mirror members when a planned disconnect occurs. This > would significantly reduce the mirror rebuild time for any component which > had been deactivated, for network mirrors using ggated devices this would > also reduce network usage and could be used for remote asynced mirrors > thus providing a live backup for laptops/workstations. Do you see that you are describing ZFS there? Considering the status of ZFS right now, I think it is not worth really trying to implement such scheme in gmirror. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Darwin sidhe.keltia.net Kernel Version 8.8.2: Thu Sep 28 20:43:26 PDT 2006 i386 From owner-freebsd-fs@FreeBSD.ORG Fri Apr 20 22:40:52 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B2E216A400 for ; Fri, 20 Apr 2007 22:40:52 +0000 (UTC) (envelope-from mike@nux.co.uk) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by mx1.freebsd.org (Postfix) with ESMTP id D9C5913C455 for ; Fri, 20 Apr 2007 22:40:51 +0000 (UTC) (envelope-from mike@nux.co.uk) Received: from office.nux.co.uk (unknown [82.133.40.67]) by smtp.nildram.co.uk (Postfix) with ESMTP id 714C12B59DD for ; Fri, 20 Apr 2007 23:40:46 +0100 (BST) Received: (qmail 6389 invoked by uid 2223); 20 Apr 2007 22:40:50 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Apr 2007 22:40:50 -0000 Date: Fri, 20 Apr 2007 23:40:50 +0100 (BST) From: Mike Wolman X-X-Sender: mike@nux.eros.office To: roberto@keltia.freenix.fr, freebsd-fs@freebsd.org Message-ID: <20070420232209.G4559@nux.eros.office> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: lazy mirror / live backup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 22:40:52 -0000 >> I'd like the ability to have gmirror do a more efficient re-silvering (or >> re-syncing) of the mirror members when a planned disconnect occurs. This >> would significantly reduce the mirror rebuild time for any component which >> had been deactivated, for network mirrors using ggated devices this would >> also reduce network usage and could be used for remote asynced mirrors >> thus providing a live backup for laptops/workstations. >Do you see that you are describing ZFS there? Considering the status of >ZFS right now, I think it is not worth really trying to implement such >scheme in gmirror. The problem with zfs is you cannot layer it as u can with the geom classes. For example if you want to create a failover zfs storage pool, if you make the zfs pool out of gmirror devices with one being a local device and the other being a ggatec device. You would then have your zfs raidz pool replicated on a remote host. I do not think you can do this with zfs by itself as you are not able to layer raidz pool ontop of a load of zfs mirrors. Mike. From owner-freebsd-fs@FreeBSD.ORG Fri Apr 20 22:52:47 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA58B16A401 for ; Fri, 20 Apr 2007 22:52:47 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [82.230.37.243]) by mx1.freebsd.org (Postfix) with ESMTP id 9339613C4BB for ; Fri, 20 Apr 2007 22:52:47 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 3EA4139496 for ; Sat, 21 Apr 2007 00:52:46 +0200 (CEST) Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95031-08 for ; Sat, 21 Apr 2007 00:52:45 +0200 (CEST) Received: by keltia.freenix.fr (Postfix/TLS, from userid 101) id D39833940C; Sat, 21 Apr 2007 00:52:45 +0200 (CEST) Date: Sat, 21 Apr 2007 00:52:45 +0200 From: Ollivier Robert To: freebsd-fs@freebsd.org Message-ID: <20070420225245.GA95270@keltia.freenix.fr> References: <20070420232209.G4559@nux.eros.office> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070420232209.G4559@nux.eros.office> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 6.2 / Dell D820 SMP User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Subject: Re: lazy mirror / live backup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 22:52:47 -0000 According to Mike Wolman: > The problem with zfs is you cannot layer it as u can with the geom > classes. Yes and no. It is not as versatile as all geom classes I believe but on FreeBSD it is a geom provider. > For example if you want to create a failover zfs storage pool, if you make > the zfs pool out of gmirror devices with one being a local device and the > other being a ggatec device. You would then have your zfs raidz pool > replicated on a remote host. I do not think you can do this with zfs by > itself as you are not able to layer raidz pool ontop of a load of zfs > mirrors. On plain zfs yes, you can have that. zpool create tank raidz mirror da0 da1 mirror da2 da3 mirror da4 da5. (not tested) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Darwin sidhe.keltia.net Kernel Version 8.8.2: Thu Sep 28 20:43:26 PDT 2006 i386 From owner-freebsd-fs@FreeBSD.ORG Fri Apr 20 23:12:59 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0015E16A409 for ; Fri, 20 Apr 2007 23:12:58 +0000 (UTC) (envelope-from mike@nux.co.uk) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by mx1.freebsd.org (Postfix) with ESMTP id BE84513C4AD for ; Fri, 20 Apr 2007 23:12:58 +0000 (UTC) (envelope-from mike@nux.co.uk) Received: from office.nux.co.uk (unknown [82.133.40.67]) by smtp.nildram.co.uk (Postfix) with ESMTP id 9757A2B5F1F for ; Sat, 21 Apr 2007 00:12:57 +0100 (BST) Received: (qmail 9320 invoked by uid 2223); 20 Apr 2007 23:12:57 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Apr 2007 23:12:57 -0000 Date: Sat, 21 Apr 2007 00:12:57 +0100 (BST) From: Mike Wolman X-X-Sender: mike@nux.eros.office To: roberto@keltia.freenix.fr, freebsd-fs@freebsd.org In-Reply-To: <20070420232209.G4559@nux.eros.office> Message-ID: <20070421000029.N4559@nux.eros.office> References: <20070420232209.G4559@nux.eros.office> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: lazy mirror / live backup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 23:12:59 -0000 According to Mike Wolman: >> The problem with zfs is you cannot layer it as u can with the geom >> classes. > >Yes and no. It is not as versatile as all geom classes I believe but on >FreeBSD it is a geom provider. I havent played with zfs that much and was unaware that zfs created a device like the geom classes. >> For example if you want to create a failover zfs storage pool, if you make >> the zfs pool out of gmirror devices with one being a local device and the >> other being a ggatec device. You would then have your zfs raidz pool >> replicated on a remote host. I do not think you can do this with zfs by >> itself as you are not able to layer raidz pool ontop of a load of zfs >> mirrors. > >On plain zfs yes, you can have that. > >zpool create tank raidz mirror da0 da1 mirror da2 da3 mirror da4 da5. So could you do: zpool create rank raidz mirror ad0 ggatec0 mirror ad1 ggatec1 mirror ad2 ggatec2 Then should the primary fileserver fail would the backup machine be able to import this zfs pool? Would you also be able to tune zfs to prefer the local disks to the remote ones? Mike. From owner-freebsd-fs@FreeBSD.ORG Sat Apr 21 00:08:23 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F64716A401 for ; Sat, 21 Apr 2007 00:08:23 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 2757013C4AD for ; Sat, 21 Apr 2007 00:08:22 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l3L08HMf019846; Sat, 21 Apr 2007 02:08:17 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l3L087Cd015021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Apr 2007 02:08:07 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l3L086D1064512; Sat, 21 Apr 2007 02:08:06 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l3L086Fj064511; Sat, 21 Apr 2007 02:08:06 +0200 (CEST) (envelope-from ticso) Date: Sat, 21 Apr 2007 02:08:05 +0200 From: Bernd Walter To: Mike Wolman Message-ID: <20070421000805.GA64413@cicely12.cicely.de> References: <20070420232209.G4559@nux.eros.office> <20070421000029.N4559@nux.eros.office> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070421000029.N4559@nux.eros.office> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: freebsd-fs@freebsd.org Subject: Re: lazy mirror / live backup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 00:08:23 -0000 On Sat, Apr 21, 2007 at 12:12:57AM +0100, Mike Wolman wrote: > > According to Mike Wolman: > >>The problem with zfs is you cannot layer it as u can with the geom > >>classes. > > > >Yes and no. It is not as versatile as all geom classes I believe but on > >FreeBSD it is a geom provider. > > I havent played with zfs that much and was unaware that zfs created a > device like the geom classes. > > >>For example if you want to create a failover zfs storage pool, if you make > >>the zfs pool out of gmirror devices with one being a local device and the > >>other being a ggatec device. You would then have your zfs raidz pool > >>replicated on a remote host. I do not think you can do this with zfs by > >>itself as you are not able to layer raidz pool ontop of a load of zfs > >>mirrors. > > > >On plain zfs yes, you can have that. > > > >zpool create tank raidz mirror da0 da1 mirror da2 da3 mirror da4 da5. > > So could you do: > > zpool create rank raidz mirror ad0 ggatec0 mirror ad1 ggatec1 mirror ad2 > ggatec2 AFAIK you can't do raidz over mirror, unless you mirror at disk layer. Just mirror would work for shure. > Then should the primary fileserver fail would the backup machine be able > to import this zfs pool? This is obviously the primary reason for such a mirror, but it also the most insane point about it. While you can import it on another machine you completely loose the state information, since the backup side is modified in an unknown way. That's the case with your gmirror enhancements as well. You completely trust the sync state of an offline disk. > Would you also be able to tune zfs to prefer the local disks to the remote > ones? No, unless you offline them. But the point with ZFS is that you don't neeed such mirror hacks at all. Just create a pool for your data and one or more for backup. The backup pools can be on different machines as well - no need to ggate the disks. Then setup a cron-job to build snapshots on short time regular base. "zfs send" it into the "zfs receive" on the backup host. E.g. by using ssh. This can be done differentially between two snapshots, no need to do a full transfer everytime. In case you need to switch to the backup side, you can easily rool back any side you want to get back in sync. You can also just replace the disks on your primary system with the disks from the backup and just import the pool. This even works for a slow link, because writers don't need to wait for the backup system to keep up, wich would be the case for ggate based mirrors over slow links. And if you still want to disconnect/reconnect drives on the main system you can zpool import/export your backup pool disks and run the zfs send/receive localy. There is no need that the backup disks are of the same size, because you copy based on data not disk blocks. E.g. your backup pool can be much bigger than the primary and keep more snapshots, or it is smaller and keep less snapshots. You can use cheap SATA disks to backup a SCSI system. You can compress the data on the backup pool, while not using compression on the primary pool - or use stronger compression. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-fs@FreeBSD.ORG Sat Apr 21 00:38:32 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF3CD16A402 for ; Sat, 21 Apr 2007 00:38:32 +0000 (UTC) (envelope-from mike@nux.co.uk) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by mx1.freebsd.org (Postfix) with ESMTP id 47E7413C45B for ; Sat, 21 Apr 2007 00:38:32 +0000 (UTC) (envelope-from mike@nux.co.uk) Received: from office.nux.co.uk (unknown [82.133.40.67]) by smtp.nildram.co.uk (Postfix) with ESMTP id E318B2B746E for ; Sat, 21 Apr 2007 01:38:30 +0100 (BST) Received: (qmail 15183 invoked by uid 2223); 21 Apr 2007 00:38:31 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Apr 2007 00:38:31 -0000 Date: Sat, 21 Apr 2007 01:38:31 +0100 (BST) From: Mike Wolman X-X-Sender: mike@nux.eros.office To: ticso@cicely.de In-Reply-To: <20070421000805.GA64413@cicely12.cicely.de> Message-ID: <20070421011716.B4559@nux.eros.office> References: <20070420232209.G4559@nux.eros.office> <20070421000029.N4559@nux.eros.office> <20070421000805.GA64413@cicely12.cicely.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: lazy mirror / live backup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 00:38:32 -0000 >>>> For example if you want to create a failover zfs storage pool, if you make >>>> the zfs pool out of gmirror devices with one being a local device and the >>>> other being a ggatec device. You would then have your zfs raidz pool >>>> replicated on a remote host. I do not think you can do this with zfs by >>>> itself as you are not able to layer raidz pool ontop of a load of zfs >>>> mirrors. >>> >>> On plain zfs yes, you can have that. >>> >>> zpool create tank raidz mirror da0 da1 mirror da2 da3 mirror da4 da5. >> >> So could you do: >> >> zpool create rank raidz mirror ad0 ggatec0 mirror ad1 ggatec1 mirror ad2 >> ggatec2 > > AFAIK you can't do raidz over mirror, unless you mirror at disk layer. > Just mirror would work for shure. > >> Then should the primary fileserver fail would the backup machine be able >> to import this zfs pool? > > This is obviously the primary reason for such a mirror, but it also the > most insane point about it. > While you can import it on another machine you completely loose the state > information, since the backup side is modified in an unknown way. > That's the case with your gmirror enhancements as well. > You completely trust the sync state of an offline disk. > >> Would you also be able to tune zfs to prefer the local disks to the remote >> ones? > > No, unless you offline them. > > But the point with ZFS is that you don't neeed such mirror hacks at all. > Just create a pool for your data and one or more for backup. > The backup pools can be on different machines as well - no need to > ggate the disks. > Then setup a cron-job to build snapshots on short time regular base. > "zfs send" it into the "zfs receive" on the backup host. > E.g. by using ssh. > This can be done differentially between two snapshots, no need to do > a full transfer everytime. > In case you need to switch to the backup side, you can easily rool back > any side you want to get back in sync. > You can also just replace the disks on your primary system with the > disks from the backup and just import the pool. > This even works for a slow link, because writers don't need to wait > for the backup system to keep up, wich would be the case for ggate > based mirrors over slow links. > And if you still want to disconnect/reconnect drives on the main system > you can zpool import/export your backup pool disks and run the > zfs send/receive localy. > There is no need that the backup disks are of the same size, because > you copy based on data not disk blocks. > E.g. your backup pool can be much bigger than the primary and keep > more snapshots, or it is smaller and keep less snapshots. > You can use cheap SATA disks to backup a SCSI system. > You can compress the data on the backup pool, while not using > compression on the primary pool - or use stronger compression. > Thank you for enlightening me on the zfs send and receive stuff, for the above example i can see how well suited zfs is. My only concern is zfs is quite heavy weight (memory wise) compared to gmirror and ufs for a simple laptop/desktop setup which you may just want to replicate the entire drive and grab the ggatec device and be ready to run should anything happen to the machine. Im sure there are other situations where running zfs on the available hardware is not an option compared to gmirror - im not sure what the recommended amount for freebsd but as far as i can rember the suggested about for solaris is 1Gb - comparing to gmirror i think i have run it on a machine doing simple home fileserving with 128Mb. Mike. From owner-freebsd-fs@FreeBSD.ORG Sat Apr 21 01:07:47 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8D1E16A401 for ; Sat, 21 Apr 2007 01:07:47 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 1FCE613C45B for ; Sat, 21 Apr 2007 01:07:46 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l3L17i49020861; Sat, 21 Apr 2007 03:07:44 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l3L17ZCL015452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Apr 2007 03:07:36 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l3L17ZtF064938; Sat, 21 Apr 2007 03:07:35 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l3L17ZfN064937; Sat, 21 Apr 2007 03:07:35 +0200 (CEST) (envelope-from ticso) Date: Sat, 21 Apr 2007 03:07:35 +0200 From: Bernd Walter To: Mike Wolman Message-ID: <20070421010734.GD64413@cicely12.cicely.de> References: <20070420232209.G4559@nux.eros.office> <20070421000029.N4559@nux.eros.office> <20070421000805.GA64413@cicely12.cicely.de> <20070421011716.B4559@nux.eros.office> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070421011716.B4559@nux.eros.office> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: freebsd-fs@freebsd.org, ticso@cicely.de Subject: Re: lazy mirror / live backup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 01:07:47 -0000 On Sat, Apr 21, 2007 at 01:38:31AM +0100, Mike Wolman wrote: > My only concern is zfs is quite heavy weight (memory wise) compared to > gmirror and ufs for a simple laptop/desktop setup which you may just want > to replicate the entire drive and grab the ggatec device and be ready to > run should anything happen to the machine. Yes - that's unfortunately true. > Im sure there are other situations where running zfs on the available > hardware is not an option compared to gmirror - im not sure what the > recommended amount for freebsd but as far as i can rember the suggested > about for solaris is 1Gb - comparing to gmirror i think i have run it on a > machine doing simple home fileserving with 128Mb. Ever thought about UFS snapshots backed with rsync? You get a consitent pseudo image of your running filesystem with unallocated blocks represented as zeros. rsync now allows comparing file chunks and copies only differences. Still every block need to be read, though. vbackup from devel/plan9port stores checksums and allows offering only different blocks to the other side. venti - the backing store behind vbackup - allows compression and single storage of different blocks with same data, which reduces the required backup capacity very impressive. My expirience with vbackup is that this mechanism is fast enough as long as there are no hughe differences. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-fs@FreeBSD.ORG Sat Apr 21 01:25:49 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F6B016A400 for ; Sat, 21 Apr 2007 01:25:49 +0000 (UTC) (envelope-from mike@nux.co.uk) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by mx1.freebsd.org (Postfix) with ESMTP id EAFC713C4BF for ; Sat, 21 Apr 2007 01:25:48 +0000 (UTC) (envelope-from mike@nux.co.uk) Received: from office.nux.co.uk (unknown [82.133.40.67]) by smtp.nildram.co.uk (Postfix) with ESMTP id 807402B6B5E for ; Sat, 21 Apr 2007 02:25:47 +0100 (BST) Received: (qmail 18226 invoked by uid 2223); 21 Apr 2007 01:25:47 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Apr 2007 01:25:47 -0000 Date: Sat, 21 Apr 2007 02:25:47 +0100 (BST) From: Mike Wolman X-X-Sender: mike@nux.eros.office To: ticso@cicely.de In-Reply-To: <20070421010734.GD64413@cicely12.cicely.de> Message-ID: <20070421021529.R16230@nux.eros.office> References: <20070420232209.G4559@nux.eros.office> <20070421000029.N4559@nux.eros.office> <20070421000805.GA64413@cicely12.cicely.de> <20070421011716.B4559@nux.eros.office> <20070421010734.GD64413@cicely12.cicely.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: lazy mirror / live backup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 01:25:49 -0000 On Sat, 21 Apr 2007, Bernd Walter wrote: > On Sat, Apr 21, 2007 at 01:38:31AM +0100, Mike Wolman wrote: >> My only concern is zfs is quite heavy weight (memory wise) compared to >> gmirror and ufs for a simple laptop/desktop setup which you may just want >> to replicate the entire drive and grab the ggatec device and be ready to >> run should anything happen to the machine. > > Yes - that's unfortunately true. > >> Im sure there are other situations where running zfs on the available >> hardware is not an option compared to gmirror - im not sure what the >> recommended amount for freebsd but as far as i can rember the suggested >> about for solaris is 1Gb - comparing to gmirror i think i have run it on a >> machine doing simple home fileserving with 128Mb. > > Ever thought about UFS snapshots backed with rsync? > You get a consitent pseudo image of your running filesystem with > unallocated blocks represented as zeros. > rsync now allows comparing file chunks and copies only differences. > Still every block need to be read, though. Yea i use rsync and snapshots quite a bit, but unfortunately rsync works at the filesystem level so you cant really get a bootable image of the whole device. It would be nice if this could be done without user interaction, ie if the ggatec component of a mirror disappears and reappears gmirror justs gets to work syncing things up. > > vbackup from devel/plan9port stores checksums and allows offering > only different blocks to the other side. > venti - the backing store behind vbackup - allows compression and > single storage of different blocks with same data, which reduces > the required backup capacity very impressive. > My expirience with vbackup is that this mechanism is fast enough > as long as there are no hughe differences. > I'll take a peek as it sounds interesting, Mike. From owner-freebsd-fs@FreeBSD.ORG Sat Apr 21 02:04:16 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C56116A401 for ; Sat, 21 Apr 2007 02:04:16 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id D295D13C44C for ; Sat, 21 Apr 2007 02:04:15 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [192.168.42.21] (andersonbox1.centtech.com [192.168.42.21]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l3L24BUn074195; Fri, 20 Apr 2007 21:04:12 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <4629711B.9070902@freebsd.org> Date: Fri, 20 Apr 2007 21:04:11 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: Mike Wolman References: <20070420232209.G4559@nux.eros.office> <20070421000029.N4559@nux.eros.office> <20070421000805.GA64413@cicely12.cicely.de> <20070421011716.B4559@nux.eros.office> <20070421010734.GD64413@cicely12.cicely.de> <20070421021529.R16230@nux.eros.office> In-Reply-To: <20070421021529.R16230@nux.eros.office> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/3141/Fri Apr 20 15:23:13 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-fs@freebsd.org, ticso@cicely.de Subject: Re: lazy mirror / live backup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 02:04:16 -0000 On 04/20/07 20:25, Mike Wolman wrote: > > On Sat, 21 Apr 2007, Bernd Walter wrote: > >> On Sat, Apr 21, 2007 at 01:38:31AM +0100, Mike Wolman wrote: >>> My only concern is zfs is quite heavy weight (memory wise) compared to >>> gmirror and ufs for a simple laptop/desktop setup which you may just want >>> to replicate the entire drive and grab the ggatec device and be ready to >>> run should anything happen to the machine. >> Yes - that's unfortunately true. >> >>> Im sure there are other situations where running zfs on the available >>> hardware is not an option compared to gmirror - im not sure what the >>> recommended amount for freebsd but as far as i can rember the suggested >>> about for solaris is 1Gb - comparing to gmirror i think i have run it on a >>> machine doing simple home fileserving with 128Mb. >> Ever thought about UFS snapshots backed with rsync? >> You get a consitent pseudo image of your running filesystem with >> unallocated blocks represented as zeros. >> rsync now allows comparing file chunks and copies only differences. >> Still every block need to be read, though. > > Yea i use rsync and snapshots quite a bit, but unfortunately rsync works > at the filesystem level so you cant really get a bootable image of the whole > device. It would be nice if this could be done without user interaction, > ie if the ggatec component of a mirror disappears and reappears gmirror > justs gets to work syncing things up. rsync and it's like are great tools, but traversing the tree every time is not only slow and heavy handed, but it takes an enormous amount of memory (akin to fsck) for large file systems. rsync isn't the right tool for lazy syncing. >> vbackup from devel/plan9port stores checksums and allows offering >> only different blocks to the other side. >> venti - the backing store behind vbackup - allows compression and >> single storage of different blocks with same data, which reduces >> the required backup capacity very impressive. >> My expirience with vbackup is that this mechanism is fast enough >> as long as there are no hughe differences. >> > > I'll take a peek as it sounds interesting, Eric From owner-freebsd-fs@FreeBSD.ORG Sat Apr 21 02:09:15 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F63216A401 for ; Sat, 21 Apr 2007 02:09:15 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id 5656413C457 for ; Sat, 21 Apr 2007 02:09:15 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.47] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id l3L1qRm2067152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Apr 2007 18:52:28 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <46296E0F.2070202@FreeBSD.org> Date: Fri, 20 Apr 2007 18:51:11 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "current@freebsd.org" , freebsd-fs@FreeBSD.org Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Bug in the unmounting code X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 02:09:15 -0000 Hi, I have noticed that there is a bug in unmounting code which could make filesystem unmountable when its parent filesystem has been forcefully unmounted. Following is quick way to reproduce the problem: [sobomax@pioneer ~]$ sudo mkdir -p /tmp/1/2 [sobomax@pioneer ~]$ sudo mkdir /tmp/3 [sobomax@pioneer ~]$ sudo mount_nullfs /tmp/1 /tmp/3 [sobomax@pioneer ~]$ sudo mount_nullfs /tmp/1 /tmp/3/2 [sobomax@pioneer ~]$ sudo umount -f /tmp/3 [sobomax@pioneer ~]$ sudo mount -v /tmp/1 on /tmp/3/2 (nullfs, local, fsid 03ff000202000000) [sobomax@pioneer ~]$ sudo umount 03ff000202000000 umount: unmount of /tmp/3/2 failed: No such file or directory umount: retrying using path instead of file system ID umount: unmount of /tmp/3/2 failed: No such file or directory Investigation has revealed that in this case vn_lock() call fails with ENOENT due to the following piece of code: vn_lock() [...] if (error == 0 && vp->v_iflag & VI_DOOMED && (flags & LK_RETRY) == 0) { VOP_UNLOCK(vp, 0, td); error = ENOENT; break; } [...] Addition of LK_RETRY flag fixed the problem, but my knowledge of VFS is quite limited so that I would appreciate if somebody could verify that the fix below won't have any undesirable effects. -Maxim --- vfs_mount.c 2007/04/21 01:40:53 1.1 +++ vfs_mount.c 2007/04/21 01:41:09 @@ -1155,7 +1155,7 @@ mnt_gen_r = mp->mnt_gen; VI_LOCK(coveredvp); vholdl(coveredvp); - error = vn_lock(coveredvp, LK_EXCLUSIVE | LK_INTERLOCK, td); + error = vn_lock(coveredvp, LK_EXCLUSIVE | LK_INTERLOCK | LK_RETRY, td); vdrop(coveredvp); /* * Check for mp being unmounted while waiting for the From owner-freebsd-fs@FreeBSD.ORG Sat Apr 21 02:09:16 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22BB716A402; Sat, 21 Apr 2007 02:09:16 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id DD03913C459; Sat, 21 Apr 2007 02:09:15 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from [192.168.1.47] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id l3L1pjCg067120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Apr 2007 18:51:51 -0700 (PDT) (envelope-from sobomax@sippysoft.com) Message-ID: <46296DE1.4090408@sippysoft.com> Date: Fri, 20 Apr 2007 18:50:25 -0700 From: Maxim Sobolev Organization: Sippy Software User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "current@freebsd.org" , freebsd-fs@FreeBSD.org Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Bug in the unmounting code X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 02:09:16 -0000 Hi, I have noticed that there is a bug in unmounting code which could make filesystem unmountable when its parent filesystem has been forcefully unmounted. Following is quick way to reproduce the problem: [sobomax@pioneer ~]$ sudo mkdir -p /tmp/1/2 [sobomax@pioneer ~]$ sudo mkdir /tmp/3 [sobomax@pioneer ~]$ sudo mount_nullfs /tmp/1 /tmp/3 [sobomax@pioneer ~]$ sudo mount_nullfs /tmp/1 /tmp/3/2 [sobomax@pioneer ~]$ sudo umount -f /tmp/3 [sobomax@pioneer ~]$ sudo mount -v /tmp/1 on /tmp/3/2 (nullfs, local, fsid 03ff000202000000) [sobomax@pioneer ~]$ sudo umount 03ff000202000000 umount: unmount of /tmp/3/2 failed: No such file or directory umount: retrying using path instead of file system ID umount: unmount of /tmp/3/2 failed: No such file or directory Investigation has revealed that in this case vn_lock() call fails with ENOENT due to the following piece of code: vn_lock() [...] if (error == 0 && vp->v_iflag & VI_DOOMED && (flags & LK_RETRY) == 0) { VOP_UNLOCK(vp, 0, td); error = ENOENT; break; } [...] Addition of LK_RETRY flag fixed the problem, but my knowledge of VFS is quite limited so that I would appreciate if somebody could verify that the fix below won't have any undesirable effects. -Maxim --- vfs_mount.c 2007/04/21 01:40:53 1.1 +++ vfs_mount.c 2007/04/21 01:41:09 @@ -1155,7 +1155,7 @@ mnt_gen_r = mp->mnt_gen; VI_LOCK(coveredvp); vholdl(coveredvp); - error = vn_lock(coveredvp, LK_EXCLUSIVE | LK_INTERLOCK, td); + error = vn_lock(coveredvp, LK_EXCLUSIVE | LK_INTERLOCK | LK_RETRY, td); vdrop(coveredvp); /* * Check for mp being unmounted while waiting for the From owner-freebsd-fs@FreeBSD.ORG Sat Apr 21 02:13:52 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D5F416A402; Sat, 21 Apr 2007 02:13:52 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0966A13C43E; Sat, 21 Apr 2007 02:13:52 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id D853C1A4D95; Fri, 20 Apr 2007 19:14:10 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 4640751428; Fri, 20 Apr 2007 22:13:51 -0400 (EDT) Date: Fri, 20 Apr 2007 22:13:51 -0400 From: Kris Kennaway To: Maxim Sobolev Message-ID: <20070421021351.GA45020@xor.obsecurity.org> References: <46296E0F.2070202@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <46296E0F.2070202@FreeBSD.org> User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@FreeBSD.org, "current@freebsd.org" Subject: Re: Bug in the unmounting code X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 02:13:52 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 20, 2007 at 06:51:11PM -0700, Maxim Sobolev wrote: > Hi, >=20 > I have noticed that there is a bug in unmounting code which could make > filesystem unmountable when its parent filesystem has been forcefully > unmounted. Following is quick way to reproduce the problem: >=20 > [sobomax@pioneer ~]$ sudo mkdir -p /tmp/1/2 > [sobomax@pioneer ~]$ sudo mkdir /tmp/3 > [sobomax@pioneer ~]$ sudo mount_nullfs /tmp/1 /tmp/3 > [sobomax@pioneer ~]$ sudo mount_nullfs /tmp/1 /tmp/3/2 > [sobomax@pioneer ~]$ sudo umount -f /tmp/3 > [sobomax@pioneer ~]$ sudo mount -v > /tmp/1 on /tmp/3/2 (nullfs, local, fsid 03ff000202000000) > [sobomax@pioneer ~]$ sudo umount 03ff000202000000 > umount: unmount of /tmp/3/2 failed: No such file or directory > umount: retrying using path instead of file system ID > umount: unmount of /tmp/3/2 failed: No such file or directory Thanks for tracking this down, I have seen (and reported) these unmountable filesystems myself but had not found a way to reproduce it. Kris > Investigation has revealed that in this case vn_lock() call fails with > ENOENT due to the following piece of code: >=20 > vn_lock() > [...] > if (error =3D=3D 0 && vp->v_iflag & VI_DOOMED && > (flags & LK_RETRY) =3D=3D 0) { > VOP_UNLOCK(vp, 0, td); > error =3D ENOENT; > break; > } > [...] >=20 > Addition of LK_RETRY flag fixed the problem, but my knowledge of VFS is > quite limited so that I would appreciate if somebody could verify that > the fix below won't have any undesirable effects. >=20 > -Maxim >=20 > --- vfs_mount.c 2007/04/21 01:40:53 1.1 > +++ vfs_mount.c 2007/04/21 01:41:09 > @@ -1155,7 +1155,7 @@ > mnt_gen_r =3D mp->mnt_gen; > VI_LOCK(coveredvp); > vholdl(coveredvp); > - error =3D vn_lock(coveredvp, LK_EXCLUSIVE | LK_INTERLOCK,= td); > + error =3D vn_lock(coveredvp, LK_EXCLUSIVE | LK_INTERLOCK | > LK_RETRY, td); > vdrop(coveredvp); > /* > * Check for mp being unmounted while waiting for the >=20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >=20 --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGKXNeWry0BWjoQKURAv3HAKDGKaUnUBKClBVCJwQRi7k+myIjygCeOcnC 3zRzMUkJj0Nh/RNOJuy5PuM= =w8no -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-fs@FreeBSD.ORG Sat Apr 21 02:56:07 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D50916A404 for ; Sat, 21 Apr 2007 02:56:07 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 32F2613C48A for ; Sat, 21 Apr 2007 02:56:07 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id ED16C5BA9; Fri, 20 Apr 2007 19:38:32 -0700 (PDT) To: Mike Wolman In-reply-to: Your message of "Sat, 21 Apr 2007 02:25:47 BST." <20070421021529.R16230@nux.eros.office> Date: Fri, 20 Apr 2007 19:38:32 -0700 From: Bakul Shah Message-Id: <20070421023832.ED16C5BA9@mail.bitblocks.com> Cc: freebsd-fs@freebsd.org, ticso@cicely.de Subject: Re: lazy mirror / live backup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 02:56:07 -0000 > >> My only concern is zfs is quite heavy weight (memory wise) compared to > >> gmirror and ufs for a simple laptop/desktop setup which you may just want > >> to replicate the entire drive and grab the ggatec device and be ready to > >> run should anything happen to the machine. If you are using a mirrored device, you just need to keep track of changed block numbers -- no need to get down to sector numbers or even fragments. Assuming 16KB block size you need to find disksize/16384 bytes somewhere for a bitmap of changed blocks. This is not too onerous. Probably a variation of ggatec. And you can let a user mode program send them to a remote site. > > vbackup from devel/plan9port stores checksums and allows offering > > only different blocks to the other side. > > venti - the backing store behind vbackup - allows compression and > > single storage of different blocks with same data, which reduces > > the required backup capacity very impressive. > > My expirience with vbackup is that this mechanism is fast enough > > as long as there are no hughe differences. vbackup is a good replacement for dump. But it will read all the blocks in use (even if after the initial dump most of them won't be written to venti). This means for very large disks it will take a long time. For instance, on my laptop vbackup does a little over 1GB/minute. If we can combine vbackup with a bitmap of changed blocks it can go much faster! From owner-freebsd-fs@FreeBSD.ORG Sat Apr 21 08:29:00 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 59CA516A402 for ; Sat, 21 Apr 2007 08:29:00 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from mail03.solnet.ch (mail03.solnet.ch [212.101.4.137]) by mx1.freebsd.org (Postfix) with ESMTP id 80D1813C44B for ; Sat, 21 Apr 2007 08:28:59 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) X-Virus-Scanned: by amavisd-new at mail03.solnet.ch Received: from mail03.solnet.ch ([127.0.0.1]) by localhost (mail03.solnet.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9YPEcSVApLC7 for ; Sat, 21 Apr 2007 08:28:54 +0000 (UTC) Received: from 192.168.1.102.local.home (home.bsdunix.ch [82.220.17.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail03.solnet.ch (Postfix) with ESMTP id 9C0C060F94 for ; Sat, 21 Apr 2007 08:28:54 +0000 (UTC) Message-ID: <4629CB46.4010102@bsdunix.ch> Date: Sat, 21 Apr 2007 10:28:54 +0200 From: Thomas User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: fs@freebsd.org References: <462896C3.6040402@bsdunix.ch> In-Reply-To: <462896C3.6040402@bsdunix.ch> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Subject: Re: FS (gjournal?) releated crashes with current? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 08:29:00 -0000 Hello I recompiled the kernel with witness an all other debug options. Now I see several errors. login: Apr 21 01:51:53 lisa proftpd[680]: lisa.mlan.solnet.ch - error: unable to accept an incoming connection (Software caused connection abort) fsync: giving up on dirty 0xc6944220: tag devfs, type VCHR usecount 1, writecount 0, refcount 1415 mountedhere 0xc68ee600 flags () v_object 0xc1036ac8 ref 0 pages 32986 lock type devfs: EXCL (count 1) by thread 0xc65d5bd0 (pid 37) dev da0.journal GEOM_JOURNAL: Cannot suspend file system /usr/local/data (error=35). fsync: giving up on dirty 0xc6944220: tag devfs, type VCHR usecount 1, writecount 0, refcount 1139 mountedhere 0xc68ee600 flags () v_object 0xc1036ac8 ref 0 pages 32986 lock type devfs: EXCL (count 1) by thread 0xc65d5bd0 (pid 37) dev da0.journal GEOM_JOURNAL: Cannot suspend file system /usr/local/data (error=35). fsync: giving up on dirty 0xc6944220: tag devfs, type VCHR usecount 1, writecount 0, refcount 1298 mountedhere 0xc68ee600 flags () v_object 0xc1036ac8 ref 0 pages 33098 lock type devfs: EXCL (count 1) by thread 0xc65d5bd0 (pid 37) dev da0.journal I created the FS with newfs -J /dev/da0.journal. The raid controller and smarttools doesn't show any problems on the disks which helds /usr/local/data Ch01 Raid Set # 00 400.1GB WDC WD4000KS-00MNB0 Ch02 Raid Set # 00 400.1GB WDC WD4000YS-01MPB1 Ch03 Raid Set # 00 400.1GB WDC WD4000KS-00MNB0 Ch04 Raid Set # 00 400.1GB WDC WD4000YS-01MPB1 Ch05 Raid Set # 00 400.1GB WDC WD4000KS-00MNB0 Ch06 Raid Set # 00 400.1GB WDC WD4000KS-00MNB0 Ch07 Raid Set # 00 400.1GB WDC WD4000YS-01MPB1 Ch08 Raid Set # 00 400.1GB WDC WD4000KS-00MNB0 The WD4000YS-01MPB1 are brand new. Does someone have any experience with such issue? Cheers, Tom Thomas wrote: > Hello > > I triggered several crashes with 7-Current from 2007-04-19. The system > mostly crashes if I'm syncing data with 4-5 parallel rsync processes. > > Most debug options are disabled in my kernel and malloc was compiled > with MALLOC_PRODUCTION. I use GJournal (/dev/da0.journal) on a SATA > Raid6 created with an areca 1230 controller. The Raid status is fine. > > # mount > /dev/ad4s1a on / (ufs, local) > devfs on /dev (devfs, local) > /dev/ad4s1g on /disk1 (ufs, local, soft-updates) > /dev/ad4s1d on /tmp (ufs, local, soft-updates) > /dev/ad4s1f on /usr (ufs, local, soft-updates) > /dev/ad4s1e on /var (ufs, local, soft-updates) > /dev/da0.journal on /usr/local/data (ufs, asynchronous, local, noatime, > gjournal) > > > After every crash /dev/da0.journal is marked as clean but when I do full > fsck i got: > > # umount /usr/local/data > # fsck -y /usr/local/data > ** /dev/da0.journal > ** Last Mounted on /usr/local/data > ** Phase 1 - Check Blocks and Sizes > PARTIALLY TRUNCATED INODE I=150149446 > SALVAGE? yes > > -4415861736689041919 BAD I=150149446 > 6180257590692086610 BAD I=150149446 > 7624567997605723585 BAD I=150149446 > 8268956604991674674 BAD I=150149446 > 2342221461849545187 BAD I=150149446 > -292497344028865874 BAD I=150149446 > -5568323556661920569 BAD I=150149446 > -7916380230741665943 BAD I=150149446 > 4170928977557909368 BAD I=150149446 > 4450577158601375817 BAD I=150149446 > 1180086702901020396 BAD I=150149446 > EXCESSIVE BAD BLKS I=150149446 > CONTINUE? yes > > INCORRECT BLOCK COUNT I=150149446 (1856 should be 736) > CORRECT? yes > > PARTIALLY TRUNCATED INODE I=151138150 > SALVAGE? yes > .... > .... > and many more. > > > > I have 2 core dumpes: > lisa# cat /var/crash/info.6 > Dump header from device /dev/ad4s1b > Architecture: i386 > Architecture Version: 2 > Dump Length: 328253440B (313 MB) > Blocksize: 512 > Dumptime: Fri Apr 20 08:51:51 2007 > Hostname: lisa.mlan.solnet.ch > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 7.0-CURRENT #0: Thu Apr 19 09:14:51 UTC 2007 > root@lisa.mlan.solnet.ch:/usr/obj/usr/src/sys/UP7_SATA > Panic String: ffs_valloc: dup alloc > Dump Parity: 949538821 > Bounds: 6 > Dump Status: good > > lisa# kgdb kernel.debug /var/crash/vmcore.6 > kgdb: kvm_nlist(_stopped_cpus): > kgdb: kvm_nlist(_stoppcbs): > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd". > > Unread portion of the kernel message buffer: > mode = 0100644, inum = 154219448, fs = /usr/local/data > panic: ffs_valloc: dup alloc > Uptime: 7h47m45s > Physical memory: 3445 MB > Dumping 313 MB: 298 282 266 250 234 218 202 186 170 154 138 122 106 90 > 74 58 42 26 10 > > #0 doadump () at pcpu.h:172 > 172 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) backtrace > #0 doadump () at pcpu.h:172 > #1 0xc0597df8 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc0598088 in panic (fmt=0xc0773469 "ffs_valloc: dup alloc") > at /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xc06aa4f8 in ffs_valloc (pvp=0xc7a1daa0, mode=33152, cred=0xcbd66300, > vpp=0xe9040888) at /usr/src/sys/ufs/ffs/ffs_alloc.c:966 > #4 0xc06d552f in ufs_makeinode (mode=33152, dvp=0xc7a1daa0, > vpp=0xe9040b98, > cnp=0xe9040bac) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2238 > #5 0xc06d24e5 in ufs_create (ap=0x0) at > /usr/src/sys/ufs/ufs/ufs_vnops.c:188 > #6 0xc0730294 in VOP_CREATE_APV (vop=0x0, a=0xe9040a1c) at vnode_if.c:206 > #7 0xc0603644 in vn_open_cred (ndp=0xe9040b84, flagp=0xe9040c84, > cmode=384, > cred=0xcbd66300, fdidx=0) at vnode_if.h:111 > #8 0xc060346a in vn_open (ndp=0x0, flagp=0xe9040c84, cmode=384, fdidx=6) > at /usr/src/sys/kern/vfs_vnops.c:93 > #9 0xc05fdbc7 in kern_open (td=0xc91026c0, path=0x0, > pathseg=UIO_USERSPACE, > flags=2563, mode=384) at /usr/src/sys/kern/vfs_syscalls.c:987 > #10 0xc05fdb0c in open (td=0xc91026c0, uap=0x0) > at /usr/src/sys/kern/vfs_syscalls.c:954 > #11 0xc07200e2 in syscall (frame=0xe9040d38) > at /usr/src/sys/i386/i386/trap.c:1016 > #12 0xc0710440 in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:196 > #13 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > > > lisa# cat /var/crash/info.7 > Dump header from device /dev/ad4s1b > Architecture: i386 > Architecture Version: 2 > Dump Length: 298967040B (285 MB) > Blocksize: 512 > Dumptime: Fri Apr 20 09:55:56 2007 > Hostname: lisa.mlan.solnet.ch > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 7.0-CURRENT #0: Thu Apr 19 09:14:51 UTC 2007 > root@lisa.mlan.solnet.ch:/usr/obj/usr/src/sys/UP7_SATA > Panic String: sbdrop > Dump Parity: 487915010 > Bounds: 7 > Dump Status: good > > isa# kgdb kernel.debug /var/crash/vmcore.7 > kgdb: kvm_nlist(_stopped_cpus): > kgdb: kvm_nlist(_stoppcbs): > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd". > > Unread portion of the kernel message buffer: > panic: sbdrop > Uptime: 1h1m12s > Physical memory: 3445 MB > Dumping 285 MB: 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 > 30 14 > > #0 doadump () at pcpu.h:172 > 172 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) backtrace > #0 doadump () at pcpu.h:172 > #1 0xc0597df8 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc0598088 in panic (fmt=0xc0768744 "sbdrop") at > /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xc05d8278 in sbdrop_internal (sb=0xc6ecf8ec, len=432) at > /usr/src/sys/kern/uipc_sockbuf.c:846 > #4 0xc05d8442 in sbdrop_locked (sb=0xc6ecf8ec, len=492) at > /usr/src/sys/kern/uipc_sockbuf.c:896 > #5 0xc0646828 in tcp_do_segment (m=0xc6a75100, th=0xc6a45824, > so=0xc6ecf828, tp=0xccbd616c, drop_hdrlen=40, tlen=0) > at /usr/src/sys/netinet/tcp_input.c:2191 > #6 0xc0645439 in tcp_input (m=0xc6a75100, off0=20) at > /usr/src/sys/netinet/tcp_input.c:994 > #7 0xc063def1 in ip_input (m=0xc6a75100) at > /usr/src/sys/netinet/ip_input.c:662 > #8 0xc06184b8 in netisr_dispatch (num=2, m=0x0) at > /usr/src/sys/net/netisr.c:278 > #9 0xc06108f1 in ether_demux (ifp=0xc66bdc00, m=0xc6a75100) at > /usr/src/sys/net/if_ethersubr.c:843 > #10 0xc0610763 in ether_input (ifp=0xc66bdc00, m=0xc6a75100) at > /usr/src/sys/net/if_ethersubr.c:701 > #11 0xc04dc535 in bge_rxeof (sc=0xc66c8000) at > /usr/src/sys/dev/bge/if_bge.c:2949 > #12 0xc04dca0c in bge_intr (xsc=0xc66c8000) at > /usr/src/sys/dev/bge/if_bge.c:3127 > #13 0xc05819c6 in ithread_execute_handlers (p=0xc6682480, ie=0xc65ce600) > at /usr/src/sys/kern/kern_intr.c:682 > #14 0xc0581ad8 in ithread_loop (arg=0xc66a9a50) at > /usr/src/sys/kern/kern_intr.c:766 > #15 0xc05809aa in fork_exit (callout=0xc0581a84 , > arg=0xc66a9a50, frame=0xe6c6fd38) > at /usr/src/sys/kern/kern_fork.c:814 > #16 0xc0710450 in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:205 > > > > System information: > > uname -a > FreeBSD lisa.mlan.solnet.ch 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Thu Apr > 19 09:14:51 UTC 2007 > root@lisa.mlan.solnet.ch:/usr/obj/usr/src/sys/UP7_SATA i386 > > dmesg: > Copyright (c) 1992-2007 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.0-CURRENT #0: Thu Apr 19 09:14:51 UTC 2007 > root@lisa.mlan.solnet.ch:/usr/obj/usr/src/sys/UP7_SATA > module_register: module g_journal already exists! > Module g_journal failed to register: 17 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.13-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf62 Stepping = 2 > > Features=0xbfebfbff > Features2=0xe41d> > AMD Features=0x20100000 > AMD Features2=0x1 > Logical CPUs per core: 2 > real memory = 3622305792 (3454 MB) > avail memory = 3545190400 (3380 MB) > kbd1 at kbdmux0 > cpu0 on motherboard > pcib0: pcibus 0 on motherboard > pir0: on motherboard > pci0: on pcib0 > pcib1: irq 10 at device 1.0 on pci0 > pci1: on pcib1 > pcib2: at device 0.0 on pci1 > pci2: on pcib2 > arcmsr0: >> mem 0xdc500000-0xdc500fff,0xdc000000-0xdc3fffff irq 11 at device 14.0 > on pci2 > ARECA RAID ADAPTER0: Driver Version 1.20.00.14 2007-2-05 > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.42 2006-10-13 > arcmsr0: [ITHREAD] > pcib3: at device 0.2 on pci1 > pci3: on pcib3 > pcib4: irq 10 at device 28.0 on pci0 > pci4: on pcib4 > pcib5: at device 28.4 on pci0 > pci5: on pcib5 > pci5:0:0: bad VPD cksum, remain 14 > bge0: > mem 0xdc600000-0xdc60ffff irq 10 at device 0.0 on pci5 > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge0: Ethernet address: 00:e0:81:5d:b8:7b > bge0: [ITHREAD] > pcib6: at device 28.5 on pci0 > pci6: on pcib6 > pci6:0:0: bad VPD cksum, remain 14 > bge1: > mem 0xdc700000-0xdc70ffff irq 11 at device 0.0 on pci6 > miibus1: on bge1 > brgphy1: PHY 1 on miibus1 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge1: Ethernet address: 00:e0:81:5d:b8:7c > bge1: [ITHREAD] > uhci0: port 0x3000-0x301f irq 5 at > device 29.0 on pci0 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0x3020-0x303f irq 10 at > device 29.1 on pci0 > uhci1: [GIANT-LOCKED] > uhci1: [ITHREAD] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0x3040-0x305f irq 11 at > device 29.2 on pci0 > uhci2: [GIANT-LOCKED] > uhci2: [ITHREAD] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: on usb2 > uhub2: 2 ports with 2 removable, self powered > uhci3: port 0x3060-0x307f irq 10 at > device 29.3 on pci0 > uhci3: [GIANT-LOCKED] > uhci3: [ITHREAD] > usb3: on uhci3 > usb3: USB revision 1.0 > uhub3: on usb3 > uhub3: 2 ports with 2 removable, self powered > ehci0: mem > 0xdca00000-0xdca003ff irq 5 at device 29.7 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb4: waiting for BIOS to give up control > usb4: timed out waiting for BIOS > usb4: EHCI version 1.0 > usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 > usb4: on ehci0 > usb4: USB revision 2.0 > uhub4: on usb4 > uhub4: 8 ports with 8 removable, self powered > pcib7: at device 30.0 on pci0 > pci10: on pcib7 > vgapci0: port 0x4000-0x407f mem > 0xd8000000-0xdbffffff,0xdc400000-0xdc43ffff at device 1.0 on pci10 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > atapci1: port > 0x30e8-0x30ef,0x30dc-0x30df,0x30e0-0x30e7,0x30d8-0x30db,0x30b0-0x30bf > mem 0xdca00400-0xdca007ff irq 10 at device 31.2 on pci0 > atapci1: [ITHREAD] > ata2: on atapci1 > ata2: [ITHREAD] > ata3: on atapci1 > ata3: [ITHREAD] > pci0: at device 31.3 (no driver attached) > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xc7fff,0xe0000-0xe17ff pnpid > ORM0000 on isa0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 > on isa0 > fdc0: [FILTER] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > ppbus0: on ppc0 > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ppc0: [GIANT-LOCKED] > ppc0: [ITHREAD] > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A, console > sio0: [FILTER] > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > sio1: [FILTER] > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > unknown: can't assign resources (memory) > unknown: can't assign resources (port) > unknown: can't assign resources (memory) > unknown: can't assign resources (memory) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > Timecounter "TSC" frequency 3000130965 Hz quality 800 > Timecounters tick every 1.000 msec > ipfw2 (+ipv6) initialized, divert enabled, rule-based forwarding > enabled, default to accept, logging limited to 100 packets/entry by default > Waiting 5 seconds for SCSI devices to settle > The GEOM class JOURNAL is already loaded. > acd0: CDROM at ata0-master PIO4 > ad4: 238475MB at ata2-master SATA150 > da0 at arcmsr0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da0: 2097129MB (4294920192 512 byte sectors: 255H 63S/T 267346C) > cd0 at ata0 bus 0 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 16.000MB/s transfers > cd0: Attempt to query device size failed: NOT READY, Medium not present > GEOM_JOURNAL: Journal 1974089085: da0 contains data. > GEOM_JOURNAL: Journal 1974089085: da0 contains journal. > GEOM_JOURNAL: Journal da0 clean. > Trying to mount root from ufs:/dev/ad4s1a > bge0: link state changed to UP > bge1: link state changed to UP > > boot/loader.conf: > geom_journal_load="YES" > kern.dfldsiz="1G" > kern.maxdsiz="1G" > > sysctl.conf: > net.inet.ip.random_id=1 > net.inet.tcp.blackhole=1 > net.inet.udp.blackhole=1 > net.inet.icmp.drop_redirect=1 > net.inet.ip.fw.one_pass=0 > kern.maxfiles=65536 > kern.maxfilesperproc=32768 > > > More information needed? > > Cheers, > Thomas > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Sat Apr 21 10:02:52 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 46A6516A40B for ; Sat, 21 Apr 2007 10:02:52 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id CA65013C4C1 for ; Sat, 21 Apr 2007 10:02:51 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l3LA2n4g025601; Sat, 21 Apr 2007 12:02:50 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l3LA2Ycd018465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Apr 2007 12:02:35 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l3LA2YXN066281; Sat, 21 Apr 2007 12:02:34 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l3LA2YYJ066280; Sat, 21 Apr 2007 12:02:34 +0200 (CEST) (envelope-from ticso) Date: Sat, 21 Apr 2007 12:02:34 +0200 From: Bernd Walter To: Eric Anderson Message-ID: <20070421100233.GE64413@cicely12.cicely.de> References: <20070420232209.G4559@nux.eros.office> <20070421000029.N4559@nux.eros.office> <20070421000805.GA64413@cicely12.cicely.de> <20070421011716.B4559@nux.eros.office> <20070421010734.GD64413@cicely12.cicely.de> <20070421021529.R16230@nux.eros.office> <4629711B.9070902@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4629711B.9070902@freebsd.org> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: freebsd-fs@freebsd.org, Mike Wolman , ticso@cicely.de Subject: Re: lazy mirror / live backup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 10:02:52 -0000 On Fri, Apr 20, 2007 at 09:04:11PM -0500, Eric Anderson wrote: > On 04/20/07 20:25, Mike Wolman wrote: > > > >On Sat, 21 Apr 2007, Bernd Walter wrote: > > > >>On Sat, Apr 21, 2007 at 01:38:31AM +0100, Mike Wolman wrote: > > > >Yea i use rsync and snapshots quite a bit, but unfortunately rsync works > >at the filesystem level so you cant really get a bootable image of the > >whole device. It would be nice if this could be done without user > >interaction, ie if the ggatec component of a mirror disappears and > >reappears gmirror justs gets to work syncing things up. > > rsync and it's like are great tools, but traversing the tree every time > is not only slow and heavy handed, but it takes an enormous amount of > memory (akin to fsck) for large file systems. rsync isn't the right > tool for lazy syncing. Thich file tree? I was talking about a snapshot, which is a single file. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de