From owner-freebsd-geom@FreeBSD.ORG Sun Mar 2 06:20:56 2008 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89209106568F; Sun, 2 Mar 2008 06:20:56 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 60A0B8FC2B; Sun, 2 Mar 2008 06:20:56 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m226KuN9071506; Sun, 2 Mar 2008 06:20:56 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m226Kus8071502; Sun, 2 Mar 2008 06:20:56 GMT (envelope-from linimon) Date: Sun, 2 Mar 2008 06:20:56 GMT Message-Id: <200803020620.m226Kus8071502@freefall.freebsd.org> To: trasz@pin.if.uz.zgora.lp, linimon@FreeBSD.org, freebsd-geom@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/105390: [geli] filesystem on a md backed by sparse file with softupdates enabled leads to wdrain livelock. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 06:20:56 -0000 Synopsis: [geli] filesystem on a md backed by sparse file with softupdates enabled leads to wdrain livelock. State-Changed-From-To: feedback->closed State-Changed-By: linimon State-Changed-When: Sun Mar 2 06:20:40 UTC 2008 State-Changed-Why: Feedback timeout (> 6 months). http://www.freebsd.org/cgi/query-pr.cgi?pr=105390 From owner-freebsd-geom@FreeBSD.ORG Mon Mar 3 11:07:07 2008 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2932106573D for ; Mon, 3 Mar 2008 11:07:07 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AC1678FC13 for ; Mon, 3 Mar 2008 11:07:07 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m23B778D022040 for ; Mon, 3 Mar 2008 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m23B77mn022036 for freebsd-geom@FreeBSD.org; Mon, 3 Mar 2008 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Mar 2008 11:07:07 GMT Message-Id: <200803031107.m23B77mn022036@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-geom@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 11:07:07 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/73177 geom kldload geom_* causes panic due to memory exhaustion o kern/76538 geom [gbde] nfs-write on gbde partition stalls and continue o kern/83464 geom [geom] [patch] Unhandled malloc failures within libgeo o kern/84556 geom [geom] GBDE-encrypted swap causes panic at shutdown o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo s kern/89102 geom [geom_vfs] [panic] panic when forced unmount FS from u o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/90582 geom [geom_mirror] [panic] Restore cause panic string (ffs_ o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/113419 geom [geom] geom fox multipathing not failing back o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/115572 geom [gbde] [patch] gbde partitions fail at 28bit/48bit LBA o kern/120021 geom net-p2p/qbittorrent crashes system when it works thoug o kern/120231 geom [geom] GEOM_CONCAT error adding second drive 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/78131 geom gbde "destroy" not working. o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to p bin/110705 geom gmirror control utility does not exit with correct exi o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113885 geom [geom] [patch] improved gmirror balance algorithm o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/119743 geom [geom] geom label for cds is keeped after dismount and o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis f kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass 12 problems total. From owner-freebsd-geom@FreeBSD.ORG Wed Mar 5 02:51:37 2008 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0D99106566B; Wed, 5 Mar 2008 02:51:37 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 84DB58FC1E; Wed, 5 Mar 2008 02:51:37 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m252pbla018639; Wed, 5 Mar 2008 02:51:37 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m252pbEA018635; Wed, 5 Mar 2008 02:51:37 GMT (envelope-from vwe) Date: Wed, 5 Mar 2008 02:51:37 GMT Message-Id: <200803050251.m252pbEA018635@freefall.freebsd.org> To: vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/121364: [gmirror] Removing all providers create a "zombie" mirror X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 02:51:37 -0000 Synopsis: [gmirror] Removing all providers create a "zombie" mirror Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: vwe Responsible-Changed-When: Wed Mar 5 02:50:55 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=121364 From owner-freebsd-geom@FreeBSD.ORG Wed Mar 5 03:38:45 2008 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BE92106566C; Wed, 5 Mar 2008 03:38:45 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2D1158FC16; Wed, 5 Mar 2008 03:38:45 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m253cjPr022317; Wed, 5 Mar 2008 03:38:45 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m253cj5r022313; Wed, 5 Mar 2008 03:38:45 GMT (envelope-from vwe) Date: Wed, 5 Mar 2008 03:38:45 GMT Message-Id: <200803050338.m253cj5r022313@freefall.freebsd.org> To: kena@vodka-pomme.net, vwe@FreeBSD.org, freebsd-geom@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/121364: [gmirror] Removing all providers create a "zombie" mirror X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 03:38:45 -0000 Synopsis: [gmirror] Removing all providers create a "zombie" mirror State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Wed Mar 5 03:36:46 UTC 2008 State-Changed-Why: Please provide output of `gmirror list' http://www.freebsd.org/cgi/query-pr.cgi?pr=121364 From owner-freebsd-geom@FreeBSD.ORG Wed Mar 5 07:30:04 2008 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C017106566B for ; Wed, 5 Mar 2008 07:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 57F998FC13 for ; Wed, 5 Mar 2008 07:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m257U3fb042663 for ; Wed, 5 Mar 2008 07:30:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m257U3cF042662; Wed, 5 Mar 2008 07:30:03 GMT (envelope-from gnats) Date: Wed, 5 Mar 2008 07:30:03 GMT Message-Id: <200803050730.m257U3cF042662@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: Kena Cc: Subject: Re: kern/121364: [gmirror] Removing all providers create a "zombie" mirror X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kena List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 07:30:04 -0000 The following reply was made to PR kern/121364; it has been noted by GNATS. From: Kena To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/121364: [gmirror] Removing all providers create a "zombie" mirror Date: Wed, 5 Mar 2008 08:26:24 +0100 Hi, since the two aforementioned disks (da0 and da1) are now in production elsewhere, I am repeating the test with ggate. I believe the results are similar as in my previous report. 0. for i in 0 1; do dd if=/dev/zero of=d$i bs=1024 count=100k; ggatel create d$i; done 1. gmirror label -h test1 ggate0 ggate1; gmirror list Geom name: test1 State: COMPLETE Components: 2 Balance: split Slice: 4096 Flags: NONE GenID: 0 SyncID: 1 ID: 538186880 Providers: 1. Name: mirror/test1 Mediasize: 104857088 (100M) Sectorsize: 512 Mode: r0w0e0 Consumers: 1. Name: ggate0 Mediasize: 104857600 (100M) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 731206240 2. Name: ggate1 Mediasize: 104857600 (100M) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 1 Flags: NONE GenID: 0 SyncID: 1 ID: 501776423 At this point dmesg reports: GEOM_MIRROR: Device mirror/test1 launched (2/2). 2. gmirror remove test1 ggate1 ; gmirror insert test1 ggate1 ; gmirror remove test1 ggate0; gmirror list (no output from gmirror list) At this point dmesg reports: GEOM_MIRROR: Device test1: provider ggate1 destroyed. GEOM_MIRROR: Device test1: rebuilding provider ggate1. GEOM_MIRROR: Device test1: provider ggate0 destroyed. GEOM_MIRROR: Device test1: provider mirror/test1 destroyed. GEOM_MIRROR: Device test1: rebuilding provider ggate1 stopped. GEOM_MIRROR: Synchronization request failed (error=6). ggate1[WRITE(offset=917504, length=131072)] GEOM_MIRROR: Device test1: provider ggate1 disconnected. GEOM_MIRROR: Device test1 destroyed. 3. (intending to "re-activate" the mirror from provider ggate0, which should be "clean"): # gmirror rebuild test1 ggate0 gmirror: No such device: test1. # gmirror activate test1 ggate0 Cannot read metadata from ggate0: Invalid argument. gmirror: Not fully done. (note: gmirror label was done with -h, so I would expect that the metadata is there?) 4. Rebooting the system (for a fresh start), then # ggatel create d0; ggatel create d1; gmirror load On the console, dmesg reports: GEOM_MIRROR: Device test1 destroyed. Let me know if you need anything else. -- kena From owner-freebsd-geom@FreeBSD.ORG Fri Mar 7 09:56:30 2008 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B8BB1065676 for ; Fri, 7 Mar 2008 09:56:30 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id 2B05C8FC16 for ; Fri, 7 Mar 2008 09:56:29 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 8DF2019E023 for ; Fri, 7 Mar 2008 10:39:33 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTP id 4361D19E019 for ; Fri, 7 Mar 2008 10:39:29 +0100 (CET) Message-ID: <47D10D60.3010207@quip.cz> Date: Fri, 07 Mar 2008 10:39:44 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: freebsd-geom@FreeBSD.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: GEOM_JOURNAL: Cannot suspend file system /vol0 (error=35) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 09:56:30 -0000 Hi, today I saw this error in messages: : fsync: giving up on dirty : 0xc5564110: tag devfs, type VCHR : usecount 1, writecount 0, refcount 78 mountedhere 0xc54ef800 : flags () : v_object 0xc556645c ref 0 pages 1146 : lock type devfs: EXCL (count 1) by thread 0xc5236a50 (pid 39) : dev mirror/gm0s2e.journal : GEOM_JOURNAL: Cannot suspend file system /vol0 (error=35). Is it something harmful, or is it "normal" behavior? It was in time when generating backup (high disk I/O). Gjournal is on top of gmirrored SATA disks. mirror/gm0s2d is 2GB journal provider mirror/gm0s2e.journal is 380GB data provider Miroslav Lachman From owner-freebsd-geom@FreeBSD.ORG Fri Mar 7 13:10:54 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8B791065673 for ; Fri, 7 Mar 2008 13:10:54 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.ltdomains.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 28B878FC2E for ; Fri, 7 Mar 2008 13:10:53 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.storspeed.com (209-163-168-124.static.tenantsolutions.com [209.163.168.124] (may be forged)) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id m27CXUGp071930; Fri, 7 Mar 2008 06:33:33 -0600 (CST) (envelope-from anderson@freebsd.org) Message-ID: <47D1361A.7080204@freebsd.org> Date: Fri, 07 Mar 2008 06:33:30 -0600 From: Eric Anderson User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz> References: <47D10D60.3010207@quip.cz> In-Reply-To: <47D10D60.3010207@quip.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: freebsd-geom@freebsd.org Subject: Re: GEOM_JOURNAL: Cannot suspend file system /vol0 (error=35) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 13:10:55 -0000 Miroslav Lachman wrote: > Hi, > > today I saw this error in messages: > > : fsync: giving up on dirty > : 0xc5564110: tag devfs, type VCHR > : usecount 1, writecount 0, refcount 78 mountedhere 0xc54ef800 > : flags () > : v_object 0xc556645c ref 0 pages 1146 > : lock type devfs: EXCL (count 1) by thread 0xc5236a50 (pid 39) > : dev mirror/gm0s2e.journal > : GEOM_JOURNAL: Cannot suspend file system /vol0 (error=35). > > Is it something harmful, or is it "normal" behavior? It was in time when > generating backup (high disk I/O). > Gjournal is on top of gmirrored SATA disks. > > mirror/gm0s2d is 2GB journal provider > mirror/gm0s2e.journal is 380GB data provider This shouldn't be a problem really. If these are on SCSI disks, you might try increasing the queue depth using camcontrol (see the 'tags' command in the camcontrol man page). You could also try reducing the journal flush time (I can't recall the sysctl to set right now - I think the default is 10s). Eric From owner-freebsd-geom@FreeBSD.ORG Fri Mar 7 14:25:58 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 375CF10656A1 for ; Fri, 7 Mar 2008 14:25:58 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id E68D58FC24 for ; Fri, 7 Mar 2008 14:25:52 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 3837319E02D; Fri, 7 Mar 2008 15:25:51 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTP id E50D419E027; Fri, 7 Mar 2008 15:25:48 +0100 (CET) Message-ID: <47D1507B.4090002@quip.cz> Date: Fri, 07 Mar 2008 15:26:03 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Eric Anderson References: <47D10D60.3010207@quip.cz> <47D1361A.7080204@freebsd.org> In-Reply-To: <47D1361A.7080204@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: GEOM_JOURNAL: Cannot suspend file system /vol0 (error=35) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 14:25:58 -0000 Eric Anderson wrote: > Miroslav Lachman wrote: > >> Hi, >> >> today I saw this error in messages: >> >> : fsync: giving up on dirty >> : 0xc5564110: tag devfs, type VCHR >> : usecount 1, writecount 0, refcount 78 mountedhere 0xc54ef800 >> : flags () >> : v_object 0xc556645c ref 0 pages 1146 >> : lock type devfs: EXCL (count 1) by thread 0xc5236a50 (pid 39) >> : dev mirror/gm0s2e.journal >> : GEOM_JOURNAL: Cannot suspend file system /vol0 (error=35). >> >> Is it something harmful, or is it "normal" behavior? It was in time >> when generating backup (high disk I/O). >> Gjournal is on top of gmirrored SATA disks. >> >> mirror/gm0s2d is 2GB journal provider >> mirror/gm0s2e.journal is 380GB data provider > > > > This shouldn't be a problem really. If these are on SCSI disks, you > might try increasing the queue depth using camcontrol (see the 'tags' > command in the camcontrol man page). You could also try reducing the > journal flush time (I can't recall the sysctl to set right now - I think > the default is 10s). It is on SATA II drives (Hitachi HDP725050GLA360). Do you mean kern.geom.journal.switch_time ? (I have set it to default = 10s) I can try to lower it to 5s, but I think 10s is enough for 2GB journal. (10s is default for default 1GB journal size, or am I wrong?) Miroslav Lachman From owner-freebsd-geom@FreeBSD.ORG Fri Mar 7 23:27:40 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D4201065674 for ; Fri, 7 Mar 2008 23:27:40 +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 AD0C78FC18 for ; Fri, 7 Mar 2008 23:27:39 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 9233 invoked by uid 2001); 7 Mar 2008 23:00:58 -0000 Date: Fri, 7 Mar 2008 17:00:58 -0600 From: "Rick C. Petty" To: freebsd-geom@freebsd.org Message-ID: <20080307230058.GA8902@keira.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: geom_vinum platform-independent brokenness X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 23:27:40 -0000 Since no one seems to be working on fixing gvinum, I've decided to investigate and address some problems I have encountered recently. *** There is an incompatibility in geom_vinum with respect to i386/amd64. In particular, the following structure (in geom_vinum_var.h) is stored as-is on each disk (or provider): struct gv_hdr { uint64_t magic; #define GV_MAGIC 22322600044678729LL #define GV_NOMAGIC 22322600044678990LL int config_length; struct gv_label label; }; The problem is the "struct gv_label" is not aligned properly against the int. On i386 and amd64 system, this corresponds to these offsets: i386 amd64 field ---- ----- ----- 0 0 magic 8 8 config_length - - from struct gv_label : 12 16 sysname 44 48 name (of drive) 76 80 date_of_birth 84 96 last_update 92 112 drive_size = = 100 120 = total header size Because of this, someone who has volumes created with i386 gvinum cannot put those volumes onto an amd64 system, and vice-versa! My proposal is to change the type for config_length to either uint32_t or uint64_t and the fields in the struct timeval to uint32_t (which would be converted to/from long as necessary). I think going forward, this should be our on-disk structure. The problem is that both i386 and amd64 versions are currently in existence. I further propose that we "read" both types of headers (converting to the in-memory structure) and that the proposed unambiguous on-disk structure be used in *all* write operations. That way, an admin can selectively perform a one-way "upgrade" of their vinum volumes by calling "gvinum start" followed by "gvinum saveconfig". This solution needs careful attention because although you can check bytes 12-15 for zero to detect whether it's a legacy amd64 on-disk structure, it is valid to have sysname be empty (sysname is essentially hostname). The legacy amd64 partition is also guaranteed to have zeros in particular places (do to structure misalignment issues), at bytes 12-15, 84-87, 92-95, 100-103, and 108-111. Because the legacy i386 structure is only 100 bytes, the zero checks should probably apply only to the first three. Henceforth, I propose the following algorithm for reads: if bytes 12-15 are not all zero: assume legacy i386 on-disk structure else if byte 16 is not zero: assume legacy amd64 on-disk structure else if bytes 84-87 and 92-95 are all zero: assume legacy amd64 on-disk structure else: assume legacy i386 on-disk structure In addition, I propose that magic for the new on-disk structure be changed slightly from the original magic, in case the new structure is put into a machine with an older kernel. I am willing to write all this code and provide a patch this weekend. I just wanted to throw this problem at the GEOM list and get some feedback. *** Similar to the previous problem, geom_vinum code is very endian-centric. Although FreeBSD's tier-1 platforms are all little-endian, some care could be added to the gvinum code to work on big-endian systems. This problem is not as bad as the first because the magic will not match on such systems. Still, I can imagine a big-endian system that supports the same drives. I'm willing to rewrite the read/write header code to use the appropriate htonl/htons-type macros, unless there are objections. The good news is that vinum stores its configuration in a text format, so such a fix would only affect code which reads and writes the gv_hdr. *** I would like to hear any constructive feedback on these issues before I dive into the code. Once I have a diff, should I send-pr or query this list first? Also, since I don't have an 8.x system, would a patch against 7x. be acceptable? I don't imagine there's much difference between the branches... -- Rick C. Petty From owner-freebsd-geom@FreeBSD.ORG Sat Mar 8 02:49:56 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5D1C1065670 for ; Sat, 8 Mar 2008 02:49:56 +0000 (UTC) (envelope-from dwiest@vailsys.com) Received: from dprobd02.vailsys.com (dprobd02.vailsys.com [63.149.73.146]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA968FC23 for ; Sat, 8 Mar 2008 02:49:56 +0000 (UTC) (envelope-from dwiest@vailsys.com) Received: from dpfuser01.vail (dpfuser01.vail [192.168.129.103]) by dprobd02.vailsys.com (Postfix) with ESMTP id CD9CA8A5D91 for ; Fri, 7 Mar 2008 20:49:54 -0600 (CST) Received: from dfwdamian.vail (dfwdamian.vail [192.168.129.233]) by dpfuser01.vail (Postfix) with ESMTP id A57805C5C for ; Fri, 7 Mar 2008 20:49:54 -0600 (CST) Received: (from dwiest@localhost) by dfwdamian.vail (8.13.8/8.13.8/Submit) id m282nsPQ016904 for freebsd-geom@freebsd.org; Fri, 7 Mar 2008 20:49:54 -0600 (CST) (envelope-from dwiest@vailsys.com) X-Authentication-Warning: dfwdamian.vail: dwiest set sender to dwiest@vailsys.com using -f Date: Fri, 7 Mar 2008 20:49:54 -0600 From: Damian Wiest To: freebsd-geom@freebsd.org Message-ID: <20080308024954.GF15859@dfwdamian.vail> References: <20080307230058.GA8902@keira.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080307230058.GA8902@keira.kiwi-computer.com> User-Agent: Mutt/1.4.2.3i Subject: Re: geom_vinum platform-independent brokenness X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2008 02:49:56 -0000 On Fri, Mar 07, 2008 at 05:00:58PM -0600, Rick C. Petty wrote: > Since no one seems to be working on fixing gvinum, I've decided to > investigate and address some problems I have encountered recently. > > *** > > There is an incompatibility in geom_vinum with respect to i386/amd64. > In particular, the following structure (in geom_vinum_var.h) is stored > as-is on each disk (or provider): > > struct gv_hdr { > uint64_t magic; > #define GV_MAGIC 22322600044678729LL > #define GV_NOMAGIC 22322600044678990LL > > int config_length; > struct gv_label label; > }; > > The problem is the "struct gv_label" is not aligned properly against the > int. On i386 and amd64 system, this corresponds to these offsets: > > i386 amd64 field > ---- ----- ----- > 0 0 magic > 8 8 config_length > - - from struct gv_label : > 12 16 sysname > 44 48 name (of drive) > 76 80 date_of_birth > 84 96 last_update > 92 112 drive_size > = = > 100 120 = total header size > > Because of this, someone who has volumes created with i386 gvinum cannot > put those volumes onto an amd64 system, and vice-versa! So you're saying that you should be able to remove a disk (or set of disks) from an x86 system, install it in a system running the amd64 release and have things just work? I would imagine that most people would simply use dump/restore, but I agree that it would be nice if one didn't have to do this. How is this scenario handled for basic disks? Can an amd64 system handle a disk that was labeled on an x86 system? I haven't ever tried this, but the manpage for bsdlabel suggests that it won't work unless you originally wrote an amd64 label by using the -m option. Aren't you going to run into issues with your filesystems when moving from one architecture to another that uses a different bus width? -Damian From owner-freebsd-geom@FreeBSD.ORG Sat Mar 8 06:44:56 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E46E51065671 for ; Sat, 8 Mar 2008 06:44:56 +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 82D178FC1E for ; Sat, 8 Mar 2008 06:44:56 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 13834 invoked by uid 2001); 8 Mar 2008 06:44:55 -0000 Date: Sat, 8 Mar 2008 00:44:55 -0600 From: "Rick C. Petty" To: Damian Wiest Message-ID: <20080308064455.GA13341@keira.kiwi-computer.com> References: <20080307230058.GA8902@keira.kiwi-computer.com> <20080308024954.GF15859@dfwdamian.vail> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080308024954.GF15859@dfwdamian.vail> User-Agent: Mutt/1.4.2.3i Cc: freebsd-geom@freebsd.org Subject: Re: geom_vinum platform-independent brokenness X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2008 06:44:57 -0000 On Fri, Mar 07, 2008 at 08:49:54PM -0600, Damian Wiest wrote: > > So you're saying that you should be able to remove a disk (or set of disks) > from an x86 system, install it in a system running the amd64 release and > have things just work? That is the plan. At work, we have a couple of machines on which we wanted to try amd64, but couldn't boot since the root fs is in gvinum. It makes sense for people who want perhaps to dual boot or otherwise want to migrate their data. > I would imagine that most people would simply use > dump/restore, but I agree that it would be nice if one didn't have to do > this. That solution obviously requires twice the disk space. It's especially worse if you're using RAID5. At home I'm considering upgrading to amd64 (since it's only a file server), but I don't have 4 TB of spare disks lying around for the migration. > How is this scenario handled for basic disks? I'm not sure I understand your question. > Can an amd64 system > handle a disk that was labeled on an x86 system? No, that was exactly the problem I am describing. It noticed that there were vinum disks, but the configuration was all screwed up. > I haven't ever tried > this, but the manpage for bsdlabel suggests that it won't work unless > you originally wrote an amd64 label by using the -m option. I'm not talking about the disklabel here. geom_vinum takes up the first 265 sectors (512 bytes each) to store its configuration. These are straight-up disks that aren't needed in Windoze or other OS-- just plain FreeBSD, so we use the full disks without labels or MBR partitions. > Aren't you going to run into issues with your filesystems when moving > from one architecture to another that uses a different bus width? How so? Are you saying there are bugs in UFS which will prevent this from working? If so, this is a much bigger problem than I anticipated. Looking at sys/ufs/ffs/fs.h, I do see a bunch of pointers in the superblock structure ("struct fs"), but all other superblock fields and other on-disk structures have fixed size values. Also there's a sanity test on the size of the "struct fs". Someone clearly has thought of this problem (McKusick ?). After some minimal testing of mounting i386-created UFS2 volumes on amd64, everything seems to work just fine. I've also investigated geom_mirror, and the on-disk structure seems clean. There may be others that are broken, but geom_vinum is what I've noticed and that is what I intend to fix. If UFS *is* broken, it should be fixed also. Thank you for reminding me to test the filesystem! -- Rick C. Petty