From owner-freebsd-geom@FreeBSD.ORG Mon Feb 5 11:11:14 2007 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53EE216A4A0 for ; Mon, 5 Feb 2007 11:11:14 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id E692813C4C7 for ; Mon, 5 Feb 2007 11:11:12 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l15BBChJ025898 for ; Mon, 5 Feb 2007 11:11:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l15BB9l1025863 for freebsd-geom@FreeBSD.org; Mon, 5 Feb 2007 11:11:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Feb 2007 11:11:09 GMT Message-Id: <200702051111.l15BB9l1025863@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-geom@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2007 11:11:14 -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 o 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 10 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 f kern/105390 geom [geli] filesystem on a md backed by sparse file with s o kern/107707 geom [geom] [patch] add new class geom_xbox360 to slice up 5 problems total. From owner-freebsd-geom@FreeBSD.ORG Tue Feb 6 06:20:21 2007 Return-Path: X-Original-To: freebsd-geom@FreeBSD.ORG Delivered-To: freebsd-geom@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B878E16A400 for ; Tue, 6 Feb 2007 06:20: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 473D913C478 for ; Tue, 6 Feb 2007 06:20:21 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 50829 invoked by uid 2001); 6 Feb 2007 06:20:17 -0000 Date: Tue, 6 Feb 2007 00:20:17 -0600 From: "Rick C. Petty" To: Hansa Message-ID: <20070206062017.GA50717@keira.kiwi-computer.com> References: <20070129153115.GA36446@keira.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd geom Subject: Re: How do I gmirror slices? 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: Tue, 06 Feb 2007 06:20:21 -0000 On Mon, Jan 29, 2007 at 05:28:38PM +0100, Hansa wrote: > > > > It's not really outside the file system, it appears at the > > beginning of the > > file system. It's 8KB for UFS1 and 64KB for UFS2. Not only > > that, but that > > 8K or 64K chunk is open/unused at the front of every superblock, that is: > > for every cylinder group, IIRC. > > Is that why fdisk doesn't touches the first 8/64KB before the first slice? > > Offset Size(ST) End Name PType Desc Subtype Flags > > 0 63 62 - 12 unused 0 > 63 12578832 12578894 ad4s1 8 freebsd 165 No, that's actually 63 * 512 = 31.5k. This space is reserved for legacy boot code. FreeBSD skips 8/64KB starting on the slice, in addition to wasted space by the MBR, etc. Actually I think the reason for the 63 is the maximum number of heads times sectors, so the slice is on an even cylinder. Nowadays cylinder/heads/sectors are meaningless. -- Rick C. Petty From owner-freebsd-geom@FreeBSD.ORG Tue Feb 6 06:56:05 2007 Return-Path: X-Original-To: geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 603B416A40A for ; Tue, 6 Feb 2007 06:56:05 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.177]) by mx1.freebsd.org (Postfix) with ESMTP id 4A82413C4B9 for ; Tue, 6 Feb 2007 06:56:05 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout07/MantshX 4.0) with ESMTP id l166gNIi016857 for ; Mon, 5 Feb 2007 22:42:23 -0800 (PST) Received: from [192.168.1.2] (c-67-164-11-148.hsd1.ca.comcast.net [67.164.11.148]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id l166gKm0014972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 5 Feb 2007 22:42:22 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: geom@FreeBSD.org From: Marcel Moolenaar Date: Mon, 5 Feb 2007 22:40:52 -0800 X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: Subject: New g_part class X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2007 06:56:05 -0000 All, I sent a diff to re@ for review, but I figured this is also a good place. The diff can be found here: http://mail.xcllnt.net/~marcel/g_part.diff The g_part class is a generic partitioning class with a rich set of g_ctl verbs for creating and modifying partition schemes. Currently only GPT (GUID Partition Table) and APM (Apple Partition Map) are implemented, but the KOBJ interface makes it easy to add other schemes like MBR, BSD, SUN and/or PC98. The diff only contains the kernel part. A userland tool is forthcoming. A description of the g_ctl verbs can be found here: http://wiki.freebsd.org/MarcelMoolenaar Thoughts and suggestions are welcome, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Tue Feb 6 07:53:35 2007 Return-Path: X-Original-To: geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5B3AB16A40A for ; Tue, 6 Feb 2007 07:53:35 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 1C97313C494 for ; Tue, 6 Feb 2007 07:53:34 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id C37E71747B; Tue, 6 Feb 2007 07:36:16 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l167aFpX089490; Tue, 6 Feb 2007 07:36:16 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 05 Feb 2007 22:40:52 PST." Date: Tue, 06 Feb 2007 07:36:15 +0000 Message-ID: <89489.1170747375@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: geom@FreeBSD.org Subject: Re: New g_part class X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2007 07:53:35 -0000 In message , Marcel Moolenaar wri tes: >All, > >I sent a diff to re@ for review, but I figured this is also a good >place. >The diff can be found here: > http://mail.xcllnt.net/~marcel/g_part.diff > >The g_part class is a generic partitioning class with a rich set of >g_ctl verbs for creating and modifying partition schemes. I did think about doing things this way originally, but I couldn't convince myself that it would make more sense to do so and I'm still not convinced I see a net benefit from sticking all the slice edititing code into the kernel. First there is obviously the size/bloat argument. Currently the slicers only have to have the taste functionality. Writing new layouts can generally reuse the same code for the permission check, Although MS-DOS extended partition tables are an example that cannot. Considering the fact that editing can be done equally well in userland, what is the rationale or benefit of putting the code into the kernel, to deal with very infrequent operations to change the disk-layout ? My second concern is if we might still have to replicate all the error detection in userland, if we want to retain the option for atomic changes, ie: allowing users to specify a set of changes (with disklabel -e for instance) before committing them all ? Third, I doubt this will prove as useful as expected in writing partitioning tools. For instance, how will the partitioning tool know about the geometry/alignment restrictions of MBR ? If you study libdisk, you will find that there are a couple of DWIW functiosn that translate the users wish for a NN MB size thing into a properly aligned and sized thing for the MBR. Where does that functionality live in this situation ? Does the kernel return "no good, try these parameters instead ?" or does it silently truncate and align ? So I would advocate that you try to implement the MBR method next and then do a prototype disk-editor utility, so we can see if this actually makes life easier or not. >schemes like MBR, BSD, SUN and/or PC98. BSD labels represent a particular nasty case, because of the possibility that the label sector is inside on a partition. I will advocate that if we go this direction, we should not migrate BSD, but leave it behind to die, eventually. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Tue Feb 6 10:32:39 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5236916A40A for ; Tue, 6 Feb 2007 10:32:39 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id D7CF313C471 for ; Tue, 6 Feb 2007 10:32:33 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HENcZ-0003n8-4L for freebsd-geom@freebsd.org; Tue, 06 Feb 2007 11:32:19 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Feb 2007 11:32:19 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Feb 2007 11:32:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Tue, 06 Feb 2007 11:32:11 +0100 Lines: 11 Message-ID: References: <89489.1170747375@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.9 (X11/20070110) In-Reply-To: <89489.1170747375@critter.freebsd.dk> Sender: news Subject: Re: New g_part class X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2007 10:32:39 -0000 Poul-Henning Kamp wrote: > Considering the fact that editing can be done equally well in > userland, what is the rationale or benefit of putting the code into > the kernel, to deal with very infrequent operations to change the > disk-layout ? Hmm, editing partition in userland... isn't there some well known problem with editing partitions in userland requiring setting kern.geom.debugflags to 16 before continuing? I might be wrong, but I think this was one of the problems with geom_gpt? From owner-freebsd-geom@FreeBSD.ORG Tue Feb 6 10:35:32 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C933716A400 for ; Tue, 6 Feb 2007 10:35:32 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8E9D913C441 for ; Tue, 6 Feb 2007 10:35:32 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 08D781747B; Tue, 6 Feb 2007 10:35:30 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l16AZOl8091006; Tue, 6 Feb 2007 10:35:24 GMT (envelope-from phk@critter.freebsd.dk) To: Ivan Voras From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 06 Feb 2007 11:32:11 +0100." Date: Tue, 06 Feb 2007 10:35:24 +0000 Message-ID: <91005.1170758124@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-geom@freebsd.org Subject: Re: New g_part class X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2007 10:35:32 -0000 In message , Ivan Voras writes: >Poul-Henning Kamp wrote: > >> Considering the fact that editing can be done equally well in >> userland, what is the rationale or benefit of putting the code into >> the kernel, to deal with very infrequent operations to change the >> disk-layout ? > >Hmm, editing partition in userland... isn't there some well known >problem with editing partitions in userland requiring setting >kern.geom.debugflags to 16 before continuing? I might be wrong, but I >think this was one of the problems with geom_gpt? If the geom classes are implemented correctly, you should never need to set kern.geom.debugflags. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Tue Feb 6 10:53:34 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F36CE16A400 for ; Tue, 6 Feb 2007 10:53:33 +0000 (UTC) (envelope-from F.Haarman@giessen.nl) Received: from mail02.net.giessen.nl (mail.giessen.nl [213.53.114.21]) by mx1.freebsd.org (Postfix) with SMTP id 472BF13C46B for ; Tue, 6 Feb 2007 10:53:33 +0000 (UTC) (envelope-from F.Haarman@giessen.nl) Received: (qmail 17657 invoked from network); 6 Feb 2007 12:07:15 -0000 Received: from unknown (HELO dg-exch1.giessen.nl) (172.16.10.11) by 0 with SMTP; 6 Feb 2007 12:07:15 -0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Tue, 6 Feb 2007 11:26:49 +0100 Importance: normal Priority: normal Message-ID: <2DC959620A73E842969792F5B47FCA0102AE4AEA@dg-exch1.giessen.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ggate or nfs thread-index: AcdJ2U+qwt+EjPXhRvaIhMWCpjnIpQ== From: "Frans Haarman" To: Subject: ggate or nfs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2007 10:53:34 -0000 Hi, we are running a pretty intesive Backup solution which stores the contents of the backup in 256KB files on NFS. We are often loosing our NFS mounts, and suspect more troubles with NFS. I was wondering: a) Would you use ggate instead of NFS b) How good this ggatec & ggated is running in production c) What tests you would recommend Any pointers are welcome! Gr. FH Frans Haarman De Giessen Automatisering B.V. Technische Dienst Telefoon : (0184) 67 53 75 Fax : (0184) 61 12 46 E-mail : servicedesk@giessen.nl Website : www.giessen.nl Algemeen Tel : (0184) 67 54 00 d u i d e l i j k e t a a l ! From owner-freebsd-geom@FreeBSD.ORG Tue Feb 6 11:30:45 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 233E116A400 for ; Tue, 6 Feb 2007 11:30:45 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30312.mail.mud.yahoo.com (web30312.mail.mud.yahoo.com [209.191.69.74]) by mx1.freebsd.org (Postfix) with SMTP id C85D813C481 for ; Tue, 6 Feb 2007 11:30:44 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: (qmail 48379 invoked by uid 60001); 6 Feb 2007 11:30:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Zu/MpGfJeIlTlxIgdpcDBH6isUcSUokOlcMqPZcP3TtouQ9WWRwrR2tk0AHVvFKzva0uknX4YYy3Hg6al7EmRYOijm6vtzv42i4TwisCz+SgCIhYqiBiLxvqzD1uQ/whBq/lp/kTDn8mS5yAHvlWccFKDHXjGn9U2wwtN2gTQ1k=; X-YMail-OSG: 2IEek0wVM1l.SSdUUgucDF3u3HAVBmoYbkaRW8Gi.U4Icn6g5azU7CXGVtpy_ID3xD2cZQI750vRHemW82Ibx.oD7LbU.OFPPPulS2Lr95G4lfKDd4v9vHb3Z5Lj7bDFCnvN.yot9LTaBIo- Received: from [213.54.172.133] by web30312.mail.mud.yahoo.com via HTTP; Tue, 06 Feb 2007 03:30:44 PST Date: Tue, 6 Feb 2007 03:30:44 -0800 (PST) From: "R. B. Riddick" To: Frans Haarman , freebsd-geom@freebsd.org In-Reply-To: <2DC959620A73E842969792F5B47FCA0102AE4AEA@dg-exch1.giessen.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <219218.46894.qm@web30312.mail.mud.yahoo.com> Cc: Subject: Re: ggate or nfs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2007 11:30:45 -0000 --- Frans Haarman wrote: > Hi, we are running a pretty intesive Backup solution which stores the > contents of the backup in 256KB files on NFS. > We are often loosing our NFS mounts, and suspect more troubles with NFS. > Ohoh > I was wondering: > a) Would you use ggate instead of NFS > Nope... :-) Because: If NFS fails, ggate might have the same problem... Somehow I would try to find out, why NFS fails... And finally: NFS allows multiple write access, while ggate can only allow one single write access... > b) How good this ggatec & ggated is running in production > The ggate code is newer than the NFS implementation... ggate's approach is much easier, but might react more funny on ur special situation. > c) What tests you would recommend > Setup a reference (test) system and try to use it as ur backup file server (BUT: Do not forget ur real (production) backup during the test)... :) -Arne ____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ From owner-freebsd-geom@FreeBSD.ORG Tue Feb 6 17:39:46 2007 Return-Path: X-Original-To: geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43F2516A4CF for ; Tue, 6 Feb 2007 17:39:46 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.173]) by mx1.freebsd.org (Postfix) with ESMTP id 2EFBF13C4AC for ; Tue, 6 Feb 2007 17:39:44 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout03/MantshX 4.0) with ESMTP id l16HdiD1008887; Tue, 6 Feb 2007 09:39:44 -0800 (PST) Received: from [192.168.1.2] (c-67-164-11-148.hsd1.ca.comcast.net [67.164.11.148]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id l16HdeBD017334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Feb 2007 09:39:42 -0800 (PST) In-Reply-To: <89489.1170747375@critter.freebsd.dk> References: <89489.1170747375@critter.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <835A2C66-BBEB-4A19-B6A3-A60E17572604@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Tue, 6 Feb 2007 09:38:13 -0800 To: Poul-Henning Kamp X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: geom@FreeBSD.org Subject: Re: New g_part class X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2007 17:39:47 -0000 On Feb 5, 2007, at 11:36 PM, Poul-Henning Kamp wrote: > Considering the fact that editing can be done equally well in > userland, what is the rationale or benefit of putting the code into > the kernel, to deal with very infrequent operations to change the > disk-layout ? Editing is of course still done in user space. The application is responsible for providing the right values to the kernel and the kernel will simply fail the operation if something is not correct. The reason why the kernel supports the application with these verbs is simple: the kernel needs to be involved because the application cannot write to disk directly in all cases. With the kernel involved, we can have as many ad-hoc verbs as there are partitioning schemes or we can have a single partitioning GEOM capable of handling various on-disk schemes. Since every partitioning scheme has the same fundamental purpose, a single GEOM maximizes code-reuse and allows us to have a single tool to handle all known schemes. This latter is already a need: sysinstall. > My second concern is if we might still have to replicate all the > error detection in userland, if we want to retain the option for > atomic changes, ie: allowing users to specify a set of changes (with > disklabel -e for instance) before committing them all ? The verbs change the in-memory data only. A commit is needed to write the data to disk. An undo verb exists to revert the in- memory data to match what's on disk. This not only allows complex operations to be written to disk in an atomic fashion, but also supports applications like sysinstall, where everything is prepared up-front and disks are being written after the user gives the final go-ahead. The added complexity to support this is minimal. The benefits are numerous. Atomicity is one of them. > Third, I doubt this will prove as useful as expected in writing > partitioning tools. For instance, how will the partitioning tool > know about the geometry/alignment restrictions of MBR ? A simple query is all that it takes. The application does not have to know about geometry, only about partition alignment. The GEOM can provide this to the application at runtime, based on the geometry of the disk. > If you study libdisk, you will find that there are a couple of DWIW > functiosn that translate the users wish for a NN MB size thing into > a properly aligned and sized thing for the MBR. Where does that > functionality live in this situation ? Libdisk is badly designed (if at all) and badly implemented, but the DWIM/DWIW functionality is in the right place in libdisk. It's the application that should exhibit artificial intelligence (if at all), not the kernel. > Does the kernel return "no > good, try these parameters instead ?" or does it silently truncate > and align ? I think the kernel will error. There's no use-case for this because APM and GPT don't have this restriction. Obvious is that the MBR partitioning scheme will have to enforce this. It can return an error or round the start up and the size down to make it all aligned. I favor erroring. > So I would advocate that you try to implement the MBR method next > and then do a prototype disk-editor utility, so we can see if this > actually makes life easier or not. I will write an application first. There's no partitioning tool for PowerPC and I have a PR open to rewrite gpt(8) to use ctl requests for a while now. That drove me to implement g_part in the first place. >> schemes like MBR, BSD, SUN and/or PC98. > > BSD labels represent a particular nasty case, because of the > possibility that the label sector is inside on a partition. I will > advocate that if we go this direction, we should not migrate BSD, > but leave it behind to die, eventually. I wouldn't mind if BSD labels die. At this time the g_part class already supports the notion of leaf partitioning schemes, of which BSD will be one. Leaf schemes cannot have sub-partitions. This would be enough to prevent infinite nesting. That the metadata can be within the first partition is not a problem for the g_part class proper. It doesn't know how the on-disk meta data looks like. It only knows the beginning and end of usable disk space that can be partitioned and it doesn't care if the beginning is at offset 0. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Tue Feb 6 18:00:22 2007 Return-Path: X-Original-To: geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80F9A16A400 for ; Tue, 6 Feb 2007 18:00:22 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 1C49F13C441 for ; Tue, 6 Feb 2007 18:00:21 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 5F4221747B; Tue, 6 Feb 2007 18:00:20 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l16I0Jcn094030; Tue, 6 Feb 2007 18:00:19 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 06 Feb 2007 09:38:13 PST." <835A2C66-BBEB-4A19-B6A3-A60E17572604@mac.com> Date: Tue, 06 Feb 2007 18:00:19 +0000 Message-ID: <94029.1170784819@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: geom@FreeBSD.org Subject: Re: New g_part class X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2007 18:00:22 -0000 In message <835A2C66-BBEB-4A19-B6A3-A60E17572604@mac.com>, Marcel Moolenaar wri tes: >Editing is of course still done in user space. The application >is responsible for providing the right values to the kernel and >the kernel will simply fail the operation if something is not >correct. > >The reason why the kernel supports the application with these >verbs is simple: the kernel needs to be involved because the >application cannot write to disk directly in all cases. Right, but the current scheme handles this by asking the kernel to write the finished metadata image, which the kernels taste functionality can be used to validate and parse. That way, the kernel doesn't have very rarely used code for editing the metadata, only the necessary code to parse and configure based on the on-disk metadata. >Libdisk is badly designed (if at all) and badly implemented [...] No argument there, and that's from the guy who slapped it together between changing diapers :-) >It's the application that should exhibit artificial intelligence >(if at all), not the kernel. So what is the advantage of editing the metadata in the kernel instead of userland ? Userland still needs to know about the entrails of each slicer method, so what is the benefit of your scheme, compared to editing the metadata in userland and just having a "write new metadata" verb ? If you could have writte a generic partitioning tool that didn't know about the different formats, then I could see the point, but having to have the code both in userland and in the kernel makes little no sense to me, in particular given how seldom it is used. >> BSD labels represent a particular nasty case, because of the >> possibility that the label sector is inside on a partition. I will >> advocate that if we go this direction, we should not migrate BSD, >> but leave it behind to die, eventually. > >I wouldn't mind if BSD labels die. At this time the g_part class >already supports the notion of leaf partitioning schemes, of >which BSD will be one. Leaf schemes cannot have sub-partitions. I'm not sure I understand the need for this restriction ? The problem with BSD labels is that you need to intercept writes to the metadata part if one of the partitions allows this to happen. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Tue Feb 6 19:16:56 2007 Return-Path: X-Original-To: geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B00916A407 for ; Tue, 6 Feb 2007 19:16:56 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.175]) by mx1.freebsd.org (Postfix) with ESMTP id 2CAFF13C471 for ; Tue, 6 Feb 2007 19:16:56 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/8.12.11/smtpout05/MantshX 4.0) with ESMTP id l16JGtp2019802; Tue, 6 Feb 2007 11:16:55 -0800 (PST) Received: from [172.24.104.147] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id l16JGXYv016459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Feb 2007 11:16:50 -0800 (PST) In-Reply-To: <94029.1170784819@critter.freebsd.dk> References: <94029.1170784819@critter.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Tue, 6 Feb 2007 11:15:06 -0800 To: Poul-Henning Kamp X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: geom@FreeBSD.org Subject: Re: New g_part class X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2007 19:16:56 -0000 On Feb 6, 2007, at 10:00 AM, Poul-Henning Kamp wrote: > In message <835A2C66-BBEB-4A19-B6A3-A60E17572604@mac.com>, Marcel > Moolenaar wri > tes: > >> Editing is of course still done in user space. The application >> is responsible for providing the right values to the kernel and >> the kernel will simply fail the operation if something is not >> correct. >> >> The reason why the kernel supports the application with these >> verbs is simple: the kernel needs to be involved because the >> application cannot write to disk directly in all cases. > > Right, but the current scheme handles this by asking the kernel to > write the finished metadata image, which the kernels taste > functionality can be used to validate and parse. This is in effect a replacement oriented approach that is based on retasting. One cannot change the partition table by adding a new partition when an existing partition is already mounted without circumventing permissions and other checks, right? What if I want to replace a MBR with a GPT without actually changing the meta-data? This doesn't work when each partition scheme has its own image-oriented verbs, but it is supported by g_part. With g_part the least important and most discriminating aspect of partitioning is abstracted: the on-disk format for storing the meta-data. This, I believe, is the right approach. > That way, the kernel doesn't have very rarely used code for > editing the metadata, only the necessary code to parse and > configure based on the on-disk metadata. The ctlreq functions will indeed be rarely used. However, the ctlreq functions don't actually have to be present in the kernel to make g_part functional for dealing with partitions. If space is a concern, then it should be possible to put the ctlreq functions in a separate module. I don't see this as a problem so I don't give it any attention. >> Libdisk is badly designed (if at all) and badly implemented [...] > > No argument there, and that's from the guy who slapped it together > between changing diapers :-) :-) It's worth noting that the introduction of GEOM brought along some additional, and unsexy, work that had to be finished in time for the next release. I recall that sysinstall and libdisk were among the last components that had to be made to work with geom and that time was of the essence. It's a commendable achievement that you delivered. That said: libdisk is now at the root of various forms of evil, including sysinstall(8) and its deadbeat offspring sade(8). Something needs to be done, and done right, if we want to stop this madness... >> It's the application that should exhibit artificial intelligence >> (if at all), not the kernel. > > So what is the advantage of editing the metadata in the kernel > instead of userland ? Abstraction. Userland does not know or care what the on-disk meta-data looks like. It performs elementary operations that every partitioning scheme supports (modulo "extensions") and since the kernel needs to be involved anyway, it makes sense to have it involved at the basic level to simplify checks and to increase flexibility. Giving the kernel an image of what it needs to write to disk leaves a big gap between the current state and the new state and checking whether the new state is at all possible becomes very hard if not impossible in cases. But when the kernel is aware of every step on the way from the old to the new state, it can check if each step is possible and as such will know that the new state is valid when asked to write to disk. Error reporting to the user will also be improved. With an image approach the kernel has very few error conditions to report to the user with a single errno. That can only be improved if the kernel provides better error reporting. The kernel can return error strings, but that's fundamentally the wrong thing to do, because that would mean that you need to add i18n or l10n to the kernel. When the kernel is involved for each step and checks each step, the user will have direct feedback to its actions and as such will be able to understand better what went wrong and will therefore be able to take appropriate action. > If you could have writte a generic partitioning tool that didn't > know about the different formats, then I could see the point, > but having to have the code both in userland and in the kernel > makes little no sense to me, in particular given how seldom > it is used. That's the point. A single partitioning tool will be written and it will not know about the on-disk format of the meta-data. > The problem with BSD labels is that you need to intercept writes > to the metadata part if one of the partitions allows this to > happen. I personally don't worry about that. If the meta-data is within a partition, then the user (e.g. file system) of that partition needs to be aware of that anyway. The responsibility of keeping the BSD label intact is automatically delegated to the user of that partition and cannot in general be enforced anywhere else. The seperation between meta-data and data is gone so the checks can logically only happen by the owner of the data, not the owner of the meta-data. This is especially true when the file system puts it's own meta-data in the sector that contains meta-data for partitioning. Think fsize, bsize and bps/cpg... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Tue Feb 6 19:43:32 2007 Return-Path: X-Original-To: geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 154B316A401 for ; Tue, 6 Feb 2007 19:43:32 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8303613C4AA for ; Tue, 6 Feb 2007 19:43:31 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id DF7CB1747B; Tue, 6 Feb 2007 19:43:29 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l16JhT05094383; Tue, 6 Feb 2007 19:43:29 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 06 Feb 2007 11:15:06 PST." Date: Tue, 06 Feb 2007 19:43:29 +0000 Message-ID: <94382.1170791009@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: geom@FreeBSD.org Subject: Re: New g_part class X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2007 19:43:32 -0000 In message , Marcel Moolenaar wri tes: >> Right, but the current scheme handles this by asking the kernel to >> write the finished metadata image, which the kernels taste >> functionality can be used to validate and parse. > >This is in effect a replacement oriented approach that is >based on retasting. One cannot change the partition table >by adding a new partition when an existing partition is >already mounted without circumventing permissions and other >checks, right? Sure you can, works fine for at least MBR and BSD. >What if I want to replace a MBR with a GPT without actually >changing the meta-data? This doesn't work when each partition >scheme has its own image-oriented verbs, but it is supported >by g_part. The MBR to GPT migration is a nasty corner case, in particular if you want to do it while partitions are open. To the MBR method, the GPT would look like bootcode, so one way to do it without catering to open partitions is to write the GPT via the MBR geom and reboot (or retaste). >With g_part the least important and most discriminating aspect >of partitioning is abstracted: the on-disk format for storing >the meta-data. This, I believe, is the right approach. But couldn't this be equally well abstracted in userland ? I'm trying to find out what the benefit of stuffing it into the kernel is, and the only thing I can think of would be "it doesn't have to live in userland then". But if it still has to live in userland, then what's the point ? >The ctlreq functions will indeed be rarely used. However, >the ctlreq functions don't actually have to be present in >the kernel to make g_part functional for dealing with >partitions. If space is a concern, then it should be possible >to put the ctlreq functions in a separate module. I don't >see this as a problem so I don't give it any attention. Ok, that addresses at least that part. This is a concern for the embedded space. >It's worth noting that the introduction of GEOM brought along >some additional, and unsexy, work that had to be finished in >time for the next release. Ohh, the damage to libdisk happened much earlier, does "On Track Disk Manager" and "Dangerously Dedicated Mode" ring a bell with anybody ? >That said: libdisk is now at the root of various forms of evil, >including sysinstall(8) and its deadbeat offspring sade(8). >Something needs to be done, and done right, if we want to stop >this madness... I fully agree, I'm just trying to make sure I understand where you're headed, having been there myself, I know how many nasty corners there are. >>> It's the application that should exhibit artificial intelligence >>> (if at all), not the kernel. >> >> So what is the advantage of editing the metadata in the kernel >> instead of userland ? > >Abstraction. Userland does not know or care what the on-disk >meta-data looks like. It performs elementary operations that >every partitioning scheme supports (modulo "extensions") and >since the kernel needs to be involved anyway, it makes sense >to have it involved at the basic level to simplify checks >and to increase flexibility. Well, this is where I don't fully agree. Userland will need to know about the on-disk metadata differences, because partition-id's UUID's and similar has to come from somewhere, and somebody needs to know to align MBR:s1 on the second track etc etc. >Giving the kernel an image of what it needs to write to disk >leaves a big gap between the current state and the new state >and checking whether the new state is at all possible becomes >very hard if not impossible in cases. Works for the classes I've written: The taste function gets called before the write to validate the new metadata, and afterwards to instantiate it. What or where is this an impossible plan ? >Error reporting to the user will also be improved. With an >image approach the kernel has very few error conditions to >report to the user with a single errno. g_ctl allows for a string error, so this is no longer a limitation execpt in the legacy ioctls (which we should concentrate on killing) >The kernel can return error strings, but that's fundamentally >the wrong thing to do, because that would mean that you need >to add i18n or l10n to the kernel. This is probably a more political question than anything. All the people I asked agreed that english errormessages were way bettern than an EINVAL that could mean 12 different things. >When the kernel is involved for each step and checks each >step, the user will have direct feedback to its actions >and as such will be able to understand better what went >wrong and will therefore be able to take appropriate >action. These same checks could be carried out in userland, where i18n is much easier ? Why bother the kernel with a check userland can do ? >> If you could have writte a generic partitioning tool that didn't >> know about the different formats, then I could see the point, >> but having to have the code both in userland and in the kernel >> makes little no sense to me, in particular given how seldom >> it is used. > >That's the point. A single partitioning tool will be written >and it will not know about the on-disk format of the meta-data. But it will know about meta-data idosyncracies like parition ID, alignment, size restrictions, uuids etc etc, so now, instead of having it all collected on place, we get it spread with half in the kernel and half in userland ? >> The problem with BSD labels is that you need to intercept writes >> to the metadata part if one of the partitions allows this to >> happen. > >I personally don't worry about that. If the meta-data is within >a partition, then the user (e.g. file system) of that partition >needs to be aware of that anyway. Yeah, well, that's why I have changed our defaults to not create partitions covering the metadata (part table + boot code). I guess this bugwards compat code could die now, but I'd rather that all of BSD dies. >The responsibility of keeping >the BSD label intact is automatically delegated to the user of >that partition and cannot in general be enforced anywhere else. Not quite. Today the BSD geom will fail the write if it does not contain valid BSD label metadata. This has saved quite a lot of people from losing their paritioning when they put non-UFS filesystems on a ...a partition. It's a major bit of complication on the BSD class, but it was necessary. Summary: I'm not against what you are proposing, but I doubt that it turn out as clean as you expect. I predict that you will find, as you add the legacy parition types like MBR, that you will not avoid knowing about their warts in userland. In particular, you will need facilites for writing boot code and other non-partition metadata, and those are, by definition type specific. The alternative to what you are proposing is marginally saner: a per-class object in libgeom, loaded by a disk-edit library or application. But it would at least keep all the magic source for editing each class in one place, and require less code in the kernel. You're doing the work, you decide, you get the blame :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Tue Feb 6 23:12:44 2007 Return-Path: X-Original-To: geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0967916A401 for ; Tue, 6 Feb 2007 23:12:43 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.178]) by mx1.freebsd.org (Postfix) with ESMTP id E9C1F13C48E for ; Tue, 6 Feb 2007 23:12:42 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/8.12.11/smtpout08/MantshX 4.0) with ESMTP id l16NCgJm009945; Tue, 6 Feb 2007 15:12:42 -0800 (PST) Received: from [172.24.104.147] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id l16NCMDd003835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Feb 2007 15:12:38 -0800 (PST) In-Reply-To: <94382.1170791009@critter.freebsd.dk> References: <94382.1170791009@critter.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5CDE358B-864C-41D9-A3A0-952A49A93218@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Tue, 6 Feb 2007 15:10:55 -0800 To: Poul-Henning Kamp X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: geom@FreeBSD.org Subject: Re: New g_part class X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2007 23:12:44 -0000 On Feb 6, 2007, at 11:43 AM, Poul-Henning Kamp wrote: >> With g_part the least important and most discriminating aspect >> of partitioning is abstracted: the on-disk format for storing >> the meta-data. This, I believe, is the right approach. > > But couldn't this be equally well abstracted in userland ? So far we are unsuccessful. Every partitioning scheme has its own tool, so we don't even abstract there. The user is faced with the differences. Sysinstall is supposed to abstract the details from the user but has turned into a non-portable obstinate piece of code that is so hard to maintain that new partitioning schemes are simply not added anymore: it's too difficult. Not to mention that it's impossible to label a disk other than the single one supported for that particular architecture. As an example, people seem to like GPT to partition big disks on i486/amd64 and only use MBR for booting purposes. This cannot be done in sysinstall at all. On the other hand, Linux has parted. This seems to be an example of where it is successful. At least, to certain extend. Unfortunately, parted likes to write the data to disk itself and as such has knowledge about each and every partitioning scheme itself. This then is an example of having the abstraction in userland. Since GEOM has the ctlreq interface for this and disk access is generally speaking not allowed, it's not an example that fits our use case entirely. Also, we share files between kernel and userland for encoding and decoding MBRs and BSD labels. This is the immediate result of having detailed knowledge in two places: the kernel and the tool that works with the partitioning scheme. Since we do need the knowledge in the kernel to begin with, the logical step to avoid duplication is to eliminate the need for this knowledge from userland. This is the g_part approach. With g_part, the on-disk layout is kept in the kernel so that detailed knowledge resides in one place and the elementary operations are the handshake between kernel and userland. The handshake already provides the abstraction. > I'm trying to find out what the benefit of stuffing it into > the kernel is, and the only thing I can think of would be > "it doesn't have to live in userland then". But if it > still has to live in userland, then what's the point ? It doesn't have to live in userland anymore. >> That said: libdisk is now at the root of various forms of evil, >> including sysinstall(8) and its deadbeat offspring sade(8). >> Something needs to be done, and done right, if we want to stop >> this madness... > > I fully agree, I'm just trying to make sure I understand where > you're headed, having been there myself, I know how many nasty > corners there are. Understood. If I cannot defend my self in this discussion, we know that I'm headed for disaster. >>>> It's the application that should exhibit artificial intelligence >>>> (if at all), not the kernel. >>> >>> So what is the advantage of editing the metadata in the kernel >>> instead of userland ? >> >> Abstraction. Userland does not know or care what the on-disk >> meta-data looks like. It performs elementary operations that >> every partitioning scheme supports (modulo "extensions") and >> since the kernel needs to be involved anyway, it makes sense >> to have it involved at the basic level to simplify checks >> and to increase flexibility. > > Well, this is where I don't fully agree. Userland will > need to know about the on-disk metadata differences, because > partition-id's UUID's and similar has to come from somewhere, > and somebody needs to know to align MBR:s1 on the second > track etc etc. The g_part class works with with aliases. A partition type of @freebsd-ufs translates to different scheme-dependent codes that represent the type. For GPT this is the corresponding UUID, for APM it's the corresponding string and for the BSD disklabel this translates to FS_FFS. However, the g_part class does not itself deal with partition types. It's handled by the scheme-specific code. This means that tools can pass scheme-specific codes. Typically these scheme-specific codes are used only when the user wants to create partitions foreign to FreeBSD. >> Giving the kernel an image of what it needs to write to disk >> leaves a big gap between the current state and the new state >> and checking whether the new state is at all possible becomes >> very hard if not impossible in cases. > > Works for the classes I've written: The taste function > gets called before the write to validate the new metadata, > and afterwards to instantiate it. > > What or where is this an impossible plan ? It's not impossible. Just not reusable and/or scalable. Every partitioning scheme has to support the act of adding one or more partitions, but only 1 partitioning scheme will need to support the writing of a MBR. Adding support for a new partitioning scheme will therefore result in copying both some GEOM class as well as the tool to define and/or modify partitions and subsequently modified for the new scheme. This has already resulted in naming conflicts and forced us to make dsklabel a link to bsdlabel or sunlabel (or something like that). >> The kernel can return error strings, but that's fundamentally >> the wrong thing to do, because that would mean that you need >> to add i18n or l10n to the kernel. > > This is probably a more political question than anything. All the > people I asked agreed that english errormessages were way bettern > than an EINVAL that could mean 12 different things. I'm sure they all understand english and don't localize their systems (if at all possible). >> When the kernel is involved for each step and checks each >> step, the user will have direct feedback to its actions >> and as such will be able to understand better what went >> wrong and will therefore be able to take appropriate >> action. > > These same checks could be carried out in userland, where i18n > is much easier ? Why bother the kernel with a check userland > can do ? Not all checks can be performed in userland. Things like whether devices are opened (and thus whether a partition can be removed) need kernel involvement. Also consider concurrency: keeping the work local to the process creates big race conditions when some other sysadmin is doing the same thing. What about devices that went away or different devices that replaced a disk you're working on? >>> If you could have writte a generic partitioning tool that didn't >>> know about the different formats, then I could see the point, >>> but having to have the code both in userland and in the kernel >>> makes little no sense to me, in particular given how seldom >>> it is used. >> >> That's the point. A single partitioning tool will be written >> and it will not know about the on-disk format of the meta-data. > > But it will know about meta-data idosyncracies like parition ID, > alignment, size restrictions, uuids etc etc, so now, instead of > having it all collected on place, we get it spread with half > in the kernel and half in userland ? Knowledge is either in the kernel or in userland. Ideally no piece of knowledge is present in both. See also below. > In particular, you will need facilites for writing boot code and > other non-partition metadata, and those are, by definition type > specific. Yes. Boot code handling has not been implemented. I considered the implications and came to the conclusion that the kernel cannot validate the correctness of boot-code; only whether the size fits the space. This means that the responsibility lies with the tool to help out the user. As such, it will be the tool who has the knowledge and not the kernel. The only thing the kernel provides is a verb to allow a BLOB to be passed to the partitioning scheme and its the partitioning scheme that deposits the blob in the right space. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Wed Feb 7 06:25:31 2007 Return-Path: X-Original-To: geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF21E16A402 for ; Wed, 7 Feb 2007 06:25:31 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 93A3B13C491 for ; Wed, 7 Feb 2007 06:25:31 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id E71801747B; Wed, 7 Feb 2007 06:25:29 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l176PTHc096650; Wed, 7 Feb 2007 06:25:29 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 06 Feb 2007 15:10:55 PST." <5CDE358B-864C-41D9-A3A0-952A49A93218@mac.com> Date: Wed, 07 Feb 2007 06:25:29 +0000 Message-ID: <96649.1170829529@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: geom@FreeBSD.org Subject: Re: New g_part class 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, 07 Feb 2007 06:25:31 -0000 In message <5CDE358B-864C-41D9-A3A0-952A49A93218@mac.com>, Marcel Moolenaar wri tes: >> I fully agree, I'm just trying to make sure I understand where >> you're headed, having been there myself, I know how many nasty >> corners there are. > >Understood. If I cannot defend my self in this discussion, we >know that I'm headed for disaster. Tag! You're it! :-) Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Wed Feb 7 09:14:46 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 06CE816A488 for ; Wed, 7 Feb 2007 09:14:45 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 2DF8913C4A5 for ; Wed, 7 Feb 2007 09:14:44 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 798801747B; Wed, 7 Feb 2007 09:14:42 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l179EfUE099018; Wed, 7 Feb 2007 09:14:41 GMT (envelope-from phk@critter.freebsd.dk) To: Ender From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 07 Feb 2007 03:34:58 EST." <45C98F32.20308@enderzone.com> Date: Wed, 07 Feb 2007 09:14:41 +0000 Message-ID: <99017.1170839681@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-geom@freebsd.org Subject: Re: New g_part class 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, 07 Feb 2007 09:14:46 -0000 In message <45C98F32.20308@enderzone.com>, Ender writes: >Poul-Henning Kamp wrote: >> If the geom classes are implemented correctly, you should never >> need to set kern.geom.debugflags. >> >> >What about setting up a gmirror on a running server? > >http://www.onlamp.com/pub/a/bsd/2005/11/10/FreeBSD_Basics.html You mean writing to sectors which mounted filesystems belive they have exclusive use of ? No, GEOM doesn't support or allow that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Wed Feb 7 21:16:55 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65D7916A402 for ; Wed, 7 Feb 2007 21:16:55 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2186D13C4A8 for ; Wed, 7 Feb 2007 21:16:54 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HEu9p-0004L4-U6 for freebsd-geom@freebsd.org; Wed, 07 Feb 2007 22:16:50 +0100 Received: from 83-131-166-46.adsl.net.t-com.hr ([83.131.166.46]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Feb 2007 22:16:49 +0100 Received: from ivoras by 83-131-166-46.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Feb 2007 22:16:49 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Wed, 07 Feb 2007 22:16:38 +0100 Lines: 37 Message-ID: References: <45C98F32.20308@enderzone.com> <99017.1170839681@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCB3B51D03E9F314FA6FC99D6" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 83-131-166-46.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) In-Reply-To: <99017.1170839681@critter.freebsd.dk> X-Enigmail-Version: 0.94.1.2 Sender: news Subject: Re: New g_part class 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, 07 Feb 2007 21:16:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCB3B51D03E9F314FA6FC99D6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Poul-Henning Kamp wrote: > You mean writing to sectors which mounted filesystems belive they > have exclusive use of ? >=20 > No, GEOM doesn't support or allow that. Ok, the need for sysctl kern.geom.debugflags=3D16 arises because the live= system to be used as master has mounted partitions, and those partitions span the whole disk, thus conflict with gmirror which wants to use the last sector. Since using the last sector for metadata is The Official Way, how about making such conflicts easy to avoid, like for example building additional logic in g_part to create partitions one sector smaller than the container? --------------enigCB3B51D03E9F314FA6FC99D6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFykG2ldnAQVacBcgRAmESAJ44wUpRZvh0Epc5/pABOFwtY+0TnQCeL4KS k1F39Vn4eIwaMfV3HxedB0g= =JgGc -----END PGP SIGNATURE----- --------------enigCB3B51D03E9F314FA6FC99D6-- From owner-freebsd-geom@FreeBSD.ORG Wed Feb 7 21:36:42 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9CBB516A400 for ; Wed, 7 Feb 2007 21:36:42 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.freebsd.org (Postfix) with ESMTP id 57E1F13C481 for ; Wed, 7 Feb 2007 21:36:41 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id 18C032D7A0C; Wed, 7 Feb 2007 21:36:07 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id E0E181141D; Wed, 7 Feb 2007 22:36:40 +0100 (CET) Date: Wed, 7 Feb 2007 22:36:40 +0100 From: "Simon L. Nielsen" To: Ivan Voras Message-ID: <20070207213640.GB988@zaphod.nitro.dk> References: <45C98F32.20308@enderzone.com> <99017.1170839681@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Cc: freebsd-geom@freebsd.org Subject: Re: New g_part class 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, 07 Feb 2007 21:36:42 -0000 On 2007.02.07 22:16:38 +0100, Ivan Voras wrote: > Poul-Henning Kamp wrote: > > > You mean writing to sectors which mounted filesystems belive they > > have exclusive use of ? > > > > No, GEOM doesn't support or allow that. > > Ok, the need for sysctl kern.geom.debugflags=16 arises because the live > system to be used as master has mounted partitions, and those partitions > span the whole disk, thus conflict with gmirror which wants to use the > last sector. Since using the last sector for metadata is The Official > Way, how about making such conflicts easy to avoid, like for example > building additional logic in g_part to create partitions one sector > smaller than the container? Eh, gmirror already does the right thing... : [root@eddie:simon] gmirror status gmd0 Name Status Components mirror/gmd0 COMPLETE ad18 ad20 [root@eddie:simon] diskinfo -v /dev/mirror/gmd0 /dev/mirror/gmd0 512 # sectorsize 200049647104 # mediasize in bytes (186G) 390721967 # mediasize in sectors [root@eddie:simon] diskinfo -v /dev/ad18 /dev/ad18 512 # sectorsize 200049647616 # mediasize in bytes (186G) 390721968 # mediasize in sectors 387621 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. IE. the gmirror device is one sector smaller than the disk device. -- Simon L. Nielsen From owner-freebsd-geom@FreeBSD.ORG Wed Feb 7 21:49:50 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB88C16A485 for ; Wed, 7 Feb 2007 21:49:50 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 96A3A13C4AC for ; Wed, 7 Feb 2007 21:49:50 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HEufj-000830-LH for freebsd-geom@freebsd.org; Wed, 07 Feb 2007 22:49:47 +0100 Received: from 83-131-166-46.adsl.net.t-com.hr ([83.131.166.46]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Feb 2007 22:49:47 +0100 Received: from ivoras by 83-131-166-46.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Feb 2007 22:49:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Wed, 07 Feb 2007 22:49:41 +0100 Lines: 44 Message-ID: References: <45C98F32.20308@enderzone.com> <99017.1170839681@critter.freebsd.dk> <20070207213640.GB988@zaphod.nitro.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig12F72EC869AA2EBAFDECA6D5" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 83-131-166-46.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) In-Reply-To: <20070207213640.GB988@zaphod.nitro.dk> X-Enigmail-Version: 0.94.1.2 Sender: news Subject: Re: New g_part class 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, 07 Feb 2007 21:49:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig12F72EC869AA2EBAFDECA6D5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Simon L. Nielsen wrote: > IE. the gmirror device is one sector smaller than the disk device. That's not the problem - the problem is: who handles that sector? For example, a simple partition layout might be: ad0 - first drive of size X ad0s1 - of size Y ad1 - second drive of size X ad1s1 - of size Y When creating a mirror of ad0s1 and ad1s1, gmirror writes its metadata on the last sector of both partitions, and creates the mirror device one sector smaller than Y. It can't write this sector if either of the partitions are in use (e.g. mounted). Actually, while writing it all down like this, it occured to me this can't be elegantly solved on the partition level, so sorry for the noise = :) --------------enig12F72EC869AA2EBAFDECA6D5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFykl1ldnAQVacBcgRAnRSAJ9wOscTIQXWpfqwVW4iGa01UkSdfwCcCHbx 4PsmJornd1ehrMHTRK/4cyY= =uEEo -----END PGP SIGNATURE----- --------------enig12F72EC869AA2EBAFDECA6D5-- From owner-freebsd-geom@FreeBSD.ORG Wed Feb 7 21:50:15 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2772016A400 for ; Wed, 7 Feb 2007 21:50:15 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.184]) by mx1.freebsd.org (Postfix) with ESMTP id CCC3913C494 for ; Wed, 7 Feb 2007 21:50:14 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout14/MantshX 4.0) with ESMTP id l17LXi9O015963; Wed, 7 Feb 2007 13:33:44 -0800 (PST) Received: from [192.168.1.2] (c-67-164-11-148.hsd1.ca.comcast.net [67.164.11.148]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id l17LXfBw022020 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Feb 2007 13:33:43 -0800 (PST) In-Reply-To: References: <45C98F32.20308@enderzone.com> <99017.1170839681@critter.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A84E040-670F-456F-BA3B-338FC815B0A6@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Wed, 7 Feb 2007 13:32:13 -0800 To: Ivan Voras X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: freebsd-geom@freebsd.org Subject: Re: New g_part class 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, 07 Feb 2007 21:50:15 -0000 On Feb 7, 2007, at 1:16 PM, Ivan Voras wrote: > Ok, the need for sysctl kern.geom.debugflags=16 arises because the > live > system to be used as master has mounted partitions, and those > partitions > span the whole disk, thus conflict with gmirror which wants to use the > last sector. Since using the last sector for metadata is The Official > Way, how about making such conflicts easy to avoid, like for example > building additional logic in g_part to create partitions one sector > smaller than the container? This cannot generally be done. The GPT partition scheme puts a backup of the header sector in the very last sector on disk, as per the specs. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Wed Feb 7 21:51:07 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0A3016A400 for ; Wed, 7 Feb 2007 21:51:07 +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 5376613C4A6 for ; Wed, 7 Feb 2007 21:51:06 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id BF80F487FF; Wed, 7 Feb 2007 22:51:04 +0100 (CET) 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 2AFE9487F3; Wed, 7 Feb 2007 22:50:50 +0100 (CET) Date: Wed, 7 Feb 2007 22:49:54 +0100 From: Pawel Jakub Dawidek To: Ivan Voras Message-ID: <20070207214954.GA48483@garage.freebsd.pl> References: <45C98F32.20308@enderzone.com> <99017.1170839681@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-geom@freebsd.org Subject: Re: New g_part class 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, 07 Feb 2007 21:51:07 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 07, 2007 at 10:16:38PM +0100, Ivan Voras wrote: > Poul-Henning Kamp wrote: >=20 > > You mean writing to sectors which mounted filesystems belive they > > have exclusive use of ? > >=20 > > No, GEOM doesn't support or allow that. >=20 > Ok, the need for sysctl kern.geom.debugflags=3D16 arises because the live > system to be used as master has mounted partitions, and those partitions > span the whole disk, thus conflict with gmirror which wants to use the > last sector. Since using the last sector for metadata is The Official > Way, how about making such conflicts easy to avoid, like for example > building additional logic in g_part to create partitions one sector > smaller than the container? I wouldn't call it an official way... I can easly imagine a GEOM class that needs much more room than one sector for its metadata. Creating gmirror with kern.geom.debugflags=3D16 on a running partitions is done by the users on their own risk. I don't advice this method by myself - even if very rarely can be unsafe, it is just not elegant:) --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFykmCForvXbEpPzQRAg7YAKDiuj7IgsQjWJXu4H156AIOUXF1FACePQPy pDyhJ+blYeV7lerQzIFIR8o= =eF3a -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-geom@FreeBSD.ORG Wed Feb 7 22:43:37 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57A9916A401 for ; Wed, 7 Feb 2007 22:43:37 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 1A7DC13C4A5 for ; Wed, 7 Feb 2007 22:43:37 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 0EB9C1747D; Wed, 7 Feb 2007 22:43:36 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l17MhZcs002154; Wed, 7 Feb 2007 22:43:35 GMT (envelope-from phk@critter.freebsd.dk) To: Ivan Voras From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 07 Feb 2007 22:16:38 +0100." Date: Wed, 07 Feb 2007 22:43:35 +0000 Message-ID: <2153.1170888215@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-geom@freebsd.org Subject: Re: New g_part class 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, 07 Feb 2007 22:43:37 -0000 In message , Ivan Voras writes: > >Poul-Henning Kamp wrote: > >> You mean writing to sectors which mounted filesystems belive they >> have exclusive use of ? >> >> No, GEOM doesn't support or allow that. > >Ok, the need for sysctl kern.geom.debugflags=16 arises because the live > >system to be used as master has mounted partitions, and those partitions >span the whole disk, thus conflict with gmirror which wants to use the >last sector. And just how does "the last sector" not occupy the same sector as the last sector of the last mounted partition ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Thu Feb 8 07:52:07 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA37B16A400 for ; Thu, 8 Feb 2007 07:52:06 +0000 (UTC) (envelope-from jp@bsdgroup.de) Received: from digitiminimi.de (digitiminimi.de [80.242.136.80]) by mx1.freebsd.org (Postfix) with ESMTP id 8839D13C471 for ; Thu, 8 Feb 2007 07:52:06 +0000 (UTC) (envelope-from jp@bsdgroup.de) Received: from localhost (digitiminimi.de [80.242.136.80]) by digitiminimi.de (Postfix) with ESMTP id 0140ADA9C0 for ; Thu, 8 Feb 2007 08:23:36 +0100 (CET) X-Virus-Scanned: amavisd-new at digitiminimi.de Received: from digitiminimi.de ([80.242.136.80]) by localhost (main.digitiminimi.de [80.242.136.80]) (amavisd-new, port 10024) with ESMTP id 6suI2xE5+2e6 for ; Thu, 8 Feb 2007 08:23:34 +0100 (CET) Received: from loki.starkstrom.lan (p57B570AB.dip.t-dialin.net [87.181.112.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by digitiminimi.de (Postfix) with ESMTP id 9E682DA80E for ; Thu, 8 Feb 2007 08:23:32 +0100 (CET) Date: Thu, 8 Feb 2007 08:21:16 +0100 From: Joerg Pernfuss To: freebsd-geom@freebsd.org Message-ID: <20070208082116.5ac22bee@loki.starkstrom.lan> In-Reply-To: <91005.1170758124@critter.freebsd.dk> References: <91005.1170758124@critter.freebsd.dk> Followup-To: freebsd-geom@freebsd.org X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_bu=Zjhoe7+W+qDKH+G_uX2a"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Subject: Re: New g_part class X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2007 07:52:07 -0000 --Sig_bu=Zjhoe7+W+qDKH+G_uX2a Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 06 Feb 2007 10:35:24 +0000 "Poul-Henning Kamp" wrote: >=20 > If the geom classes are implemented correctly, you should never > need to set kern.geom.debugflags. So in theory, the following should work? - set up a server with 2 160g sata drives (standard example that i hope everyone can relate to) - gmirror them - set up one slice covering the whole gmirror - create a disklabel for example with: a 2g / b 4g swap c voodoo d 4g /tmp e 16g /var f 20g /usr g 54g /jails This leaves the h partition and around 56g free for "later usage" in case something comes up/happens or g needs to be grown. - add the 'h' partition later on while the system is running Because currently this does not work. I am not very fluent in C, but wouldn't this require a flag to pass down to tell it, it is ok to modify a bsdlabel from which partitions are mounted, because none of the mounted ones have been changed? Is there such a mechanism in place but unused? I haven't stumpled upon any, but I might have easily missed it. Regards, Joerg --=20 | SPECIAL ADVERTISMENT | NEW KEY AS OF 02/01/2007 - GET IT | +----------------------+------------------------------------------+ | /"\ ASCII ribbon | GnuPG Key ID | 6902 3fc0 64c3 a56e a8b4 | | \ / campaign against | 0xab439348 | c8de d555 c2cd ab43 9348 | | X HTML in email | .the next sentence is true. | | / \ and news | .the previous sentence was a lie. | --Sig_bu=Zjhoe7+W+qDKH+G_uX2a Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFFys911VXCzatDk0gRAtEkAJ9M8e6RA2HHwrpA9n3J64zO5RzO1gCaAjJ5 JBXKgpwKwLSAPDGk98eWlqY= =SJAb -----END PGP SIGNATURE----- --Sig_bu=Zjhoe7+W+qDKH+G_uX2a-- From owner-freebsd-geom@FreeBSD.ORG Thu Feb 8 07:54:14 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E252B16A418 for ; Thu, 8 Feb 2007 07:54:02 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A3EE813C474 for ; Thu, 8 Feb 2007 07:54:02 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 14FBE1747B; Thu, 8 Feb 2007 07:54:01 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l187s07H004222; Thu, 8 Feb 2007 07:54:00 GMT (envelope-from phk@critter.freebsd.dk) To: Joerg Pernfuss From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 08 Feb 2007 08:21:16 +0100." <20070208082116.5ac22bee@loki.starkstrom.lan> Date: Thu, 08 Feb 2007 07:54:00 +0000 Message-ID: <4221.1170921240@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-geom@freebsd.org Subject: Re: New g_part class X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2007 07:54:14 -0000 In message <20070208082116.5ac22bee@loki.starkstrom.lan>, Joerg Pernfuss writes : >So in theory, the following should work? > >- set up a server with 2 160g sata drives (standard example that i > hope everyone can relate to) >- gmirror them >- set up one slice covering the whole gmirror >- create a disklabel for example with: > a 2g / > b 4g swap > c voodoo > d 4g /tmp > e 16g /var > f 20g /usr > g 54g /jails > This leaves the h partition and around 56g free for "later usage" > in case something comes up/happens or g needs to be grown. >- add the 'h' partition later on while the system is running It works if you leave gmirror out of the picture, so what gmirror does wrong I don't know. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Thu Feb 8 10:25:07 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CCA5616A4D7 for ; Thu, 8 Feb 2007 10:24:48 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from lara.cc.fer.hr (lara.cc.fer.hr [161.53.72.113]) by mx1.freebsd.org (Postfix) with ESMTP id 4007B13C4A5 for ; Thu, 8 Feb 2007 10:24:46 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from [127.0.0.1] (localhost.cc.fer.hr [127.0.0.1]) by lara.cc.fer.hr (8.13.8/8.13.8) with ESMTP id l18AOci9001353; Thu, 8 Feb 2007 11:24:39 +0100 (CET) (envelope-from ivoras@fer.hr) Message-ID: <45CAFA66.3030800@fer.hr> Date: Thu, 08 Feb 2007 11:24:38 +0100 From: Ivan Voras User-Agent: Thunderbird 1.5.0.9 (X11/20070110) MIME-Version: 1.0 To: Poul-Henning Kamp References: <2153.1170888215@critter.freebsd.dk> In-Reply-To: <2153.1170888215@critter.freebsd.dk> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: New g_part class X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2007 10:25:08 -0000 Poul-Henning Kamp wrote: > In message , Ivan Voras writes: >> span the whole disk, thus conflict with gmirror which wants to use the >> last sector. > > And just how does "the last sector" not occupy the same sector as > the last sector of the last mounted partition ? A joke? :) (in case it isn't: that's the point: it DOES, so people can't create mirrors of live paritions. But, like I said, I realize there's no elegant solution). From owner-freebsd-geom@FreeBSD.ORG Thu Feb 8 10:33:28 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2110E16A400 for ; Thu, 8 Feb 2007 10:33:28 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D871313C4A5 for ; Thu, 8 Feb 2007 10:33:27 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 65DF31747B; Thu, 8 Feb 2007 10:33:26 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l18AXP5G009224; Thu, 8 Feb 2007 10:33:25 GMT (envelope-from phk@critter.freebsd.dk) To: Ivan Voras From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 08 Feb 2007 11:24:38 +0100." <45CAFA66.3030800@fer.hr> Date: Thu, 08 Feb 2007 10:33:25 +0000 Message-ID: <9223.1170930805@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-geom@freebsd.org Subject: Re: New g_part class X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2007 10:33:29 -0000 In message <45CAFA66.3030800@fer.hr>, Ivan Voras writes: >Poul-Henning Kamp wrote: >> In message , Ivan Voras writes: >>> span the whole disk, thus conflict with gmirror which wants to use the >>> last sector. >> >> And just how does "the last sector" not occupy the same sector as >> the last sector of the last mounted partition ? > >A joke? :) > >(in case it isn't: that's the point: it DOES, so people can't create >mirrors of live paritions. But, like I said, I realize there's no >elegant solution). The correct solution is a lot of code, and all you gain is that you save a single reboot. Ideal Computer Science Method: * use mount to tell filesystem to avoid last sector. * use gctl to tell slicer to reduce parition by last sector * implement new API so slicer can ask consumer (filesystem) if reducing size is OK. * use gctl to tell slicer to avoid last sector. * use gctl to insert mirror class below slicer * use gctl to tell mirror class to write metadata Practically Sensible Method: * boot single user (possibly from CD) * use fsdb or growfs to reduce filesystem size * reduce partition size * use gmirror to write metadata * reboot -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Thu Feb 8 12:55:07 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E27416A40F for ; Thu, 8 Feb 2007 12:55:06 +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 9A09C13C494 for ; Thu, 8 Feb 2007 12:55:05 +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 l18Csv8M031366; Thu, 8 Feb 2007 06:55:00 -0600 (CST) (envelope-from anderson@freebsd.org) Message-ID: <45CB1DA1.3060003@freebsd.org> Date: Thu, 08 Feb 2007 06:54:57 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5.0.9 (X11/20070204) MIME-Version: 1.0 To: Poul-Henning Kamp References: <9223.1170930805@critter.freebsd.dk> In-Reply-To: <9223.1170930805@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2534/Wed Feb 7 21:28:17 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: Ivan Voras , freebsd-geom@freebsd.org Subject: Re: New g_part class X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2007 12:55:07 -0000 On 02/08/07 04:33, Poul-Henning Kamp wrote: > In message <45CAFA66.3030800@fer.hr>, Ivan Voras writes: >> Poul-Henning Kamp wrote: >>> In message , Ivan Voras writes: >>>> span the whole disk, thus conflict with gmirror which wants to use the >>>> last sector. >>> And just how does "the last sector" not occupy the same sector as >>> the last sector of the last mounted partition ? >> A joke? :) >> >> (in case it isn't: that's the point: it DOES, so people can't create >> mirrors of live paritions. But, like I said, I realize there's no >> elegant solution). > > The correct solution is a lot of code, and all you gain is that > you save a single reboot. > > Ideal Computer Science Method: > > * use mount to tell filesystem to avoid last sector. > * use gctl to tell slicer to reduce parition by last sector > * implement new API so slicer can ask consumer (filesystem) > if reducing size is OK. > * use gctl to tell slicer to avoid last sector. > * use gctl to insert mirror class below slicer > * use gctl to tell mirror class to write metadata > > Practically Sensible Method: > > * boot single user (possibly from CD) > * use fsdb or growfs to reduce filesystem size I didn't realize growfs let you shrink file systems. I didn't see any mention of this in the man page either. If you know otherwise, can you please fill us in, and/or update the man page? Also - you are actually recommending using fsdb to modify a file system as 'practically sensible'? Heheh - that makes me giggle. > * reduce partition size > * use gmirror to write metadata > * reboot > This certainly has been an interesting thread so far... Eric From owner-freebsd-geom@FreeBSD.ORG Fri Feb 9 10:05:13 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C858D16A408 for ; Fri, 9 Feb 2007 10:05:13 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id A6D1413C428 for ; Fri, 9 Feb 2007 10:05:11 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0DB5245685; Fri, 9 Feb 2007 11:05:00 +0100 (CET) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id E3648456B1; Fri, 9 Feb 2007 11:04:48 +0100 (CET) Date: Fri, 9 Feb 2007 11:03:55 +0100 From: Pawel Jakub Dawidek To: Poul-Henning Kamp Message-ID: <20070209100355.GB3742@garage.freebsd.pl> References: <20070208082116.5ac22bee@loki.starkstrom.lan> <4221.1170921240@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="98e8jtXdkpgskNou" Content-Disposition: inline In-Reply-To: <4221.1170921240@critter.freebsd.dk> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: Joerg Pernfuss , freebsd-geom@freebsd.org Subject: Re: New g_part class 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, 09 Feb 2007 10:05:13 -0000 --98e8jtXdkpgskNou Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 08, 2007 at 07:54:00AM +0000, Poul-Henning Kamp wrote: > In message <20070208082116.5ac22bee@loki.starkstrom.lan>, Joerg Pernfuss = writes > : >=20 > >So in theory, the following should work? > > > >- set up a server with 2 160g sata drives (standard example that i > > hope everyone can relate to) > >- gmirror them > >- set up one slice covering the whole gmirror > >- create a disklabel for example with: > > a 2g / > > b 4g swap > > c voodoo > > d 4g /tmp > > e 16g /var > > f 20g /usr > > g 54g /jails > > This leaves the h partition and around 56g free for "later usage" > > in case something comes up/happens or g needs to be grown. > >- add the 'h' partition later on while the system is running >=20 > It works if you leave gmirror out of the picture, so what gmirror > does wrong I don't know. I don't see how gmirror can break anything when it is placed below BSD partitions. Maybe except that I saw some time ago that bsdlabel(8) assume there is no '/' in provider's name. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --98e8jtXdkpgskNou Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFzEcLForvXbEpPzQRApQ5AJ9P327VUhV6GtHmwN9xAccGRy9A6ACfQO7X bVPKU3Ada6U5bKTN+U6X+LM= =mrkQ -----END PGP SIGNATURE----- --98e8jtXdkpgskNou-- From owner-freebsd-geom@FreeBSD.ORG Fri Feb 9 19:29:30 2007 Return-Path: X-Original-To: geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8936016A402 for ; Fri, 9 Feb 2007 19:29:30 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.178]) by mx1.freebsd.org (Postfix) with ESMTP id 74BD413C4A3 for ; Fri, 9 Feb 2007 19:29:30 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/8.12.11/smtpout08/MantshX 4.0) with ESMTP id l19JTUxK021270 for ; Fri, 9 Feb 2007 11:29:30 -0800 (PST) Received: from [172.24.104.125] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id l19JT5PW013954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 9 Feb 2007 11:29:26 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: geom@FreeBSD.org From: Marcel Moolenaar Date: Fri, 9 Feb 2007 11:27:33 -0800 X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: Subject: g_part partition tool -- some logistic questions 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, 09 Feb 2007 19:29:30 -0000 All, I've started writing a partition tool that uses the g_part verbs and I'd like some feedback. I'm going to use the information provided by the kern.geom.confxml sysctl as parsed by the geom_gettree() function that's in libgeom. This way I can avoid having to implement query verbs. The g_part geom just needs to put the information in the XML tree. That said... The first question relates to finding and presenting the right devices/providers to the users. What I don't want is present, for example, ad0 and ad1 if they are part of a mirror. I'd like to present the mirror to the user. The same applies to other GEOM classes. Is there a generic or established way to walk the GEOM tree (obtained by geom_gettree()), and find the real or true virtual storage providers that takes the hierarchy into account? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Fri Feb 9 23:05:04 2007 Return-Path: X-Original-To: geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E958C16A400 for ; Fri, 9 Feb 2007 23:05:04 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A195413C48E for ; Fri, 9 Feb 2007 23:05:04 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 992661747B; Fri, 9 Feb 2007 23:05:02 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l19N51B8006782; Fri, 9 Feb 2007 23:05:01 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 09 Feb 2007 11:27:33 PST." Date: Fri, 09 Feb 2007 23:05:01 +0000 Message-ID: <6781.1171062301@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: geom@FreeBSD.org Subject: Re: g_part partition tool -- some logistic questions 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, 09 Feb 2007 23:05:05 -0000 In message , Marcel Moolenaar wri tes: >The first question relates to finding and presenting the right >devices/providers to the users. What I don't want is present, >for example, ad0 and ad1 if they are part of a mirror. I'd like >to present the mirror to the user. The same applies to other >GEOM classes. > >Is there a generic or established way to walk the GEOM tree >(obtained by geom_gettree()), and find the real or true virtual >storage providers that takes the hierarchy into account? There are no providers that are more "real" or "true" than others, they are all "just" providers. If you want to add a "desirability" property to the providers, then I'm all for it, provided you explain up front how you expect it to actually work. If you have bsd(mirror(ad0,ad1)), then the BSD parts should be more desirable than the mirror or the disks. If on the other hand you have mirror(bsd(ad0),bsd(ad1)), then the mirror should be more desirable than the bsd's and the disks. It follows from this that just assigning a desirability to a class or an instance is not trivial. In general however, I think we can do a pretty good approximation to "DWIM" by using the rank property, because in general people don't stack things up if they don't want to get upwards. So you may want to try something like pruning everything but the highest ranking leaf providers in each subtree and see where that gets you. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Sat Feb 10 18:32:52 2007 Return-Path: X-Original-To: geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1603316A405 for ; Sat, 10 Feb 2007 18:32:52 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.172]) by mx1.freebsd.org (Postfix) with ESMTP id 015D413C46B for ; Sat, 10 Feb 2007 18:32:51 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout02/MantshX 4.0) with ESMTP id l1AIWnXR018854; Sat, 10 Feb 2007 10:32:49 -0800 (PST) Received: from [192.168.1.2] (c-67-164-11-148.hsd1.ca.comcast.net [67.164.11.148]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id l1AIWlx1019539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 10 Feb 2007 10:32:48 -0800 (PST) In-Reply-To: <6781.1171062301@critter.freebsd.dk> References: <6781.1171062301@critter.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5BB89CF0-69CE-4A93-828B-298A13CD0F67@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sat, 10 Feb 2007 10:23:32 -0800 To: Poul-Henning Kamp X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: geom@FreeBSD.org Subject: Re: g_part partition tool -- some logistic questions 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, 10 Feb 2007 18:32:52 -0000 On Feb 9, 2007, at 3:05 PM, Poul-Henning Kamp wrote: > If you have bsd(mirror(ad0,ad1)), then the BSD parts should > be more desirable than the mirror or the disks. > > If on the other hand you have mirror(bsd(ad0),bsd(ad1)), then > the mirror should be more desirable than the bsd's and the disks. Actually, when you have mirror(bsd(ad0),bsd(ad1)) then ad0 and ad1 are the ones I want. But if you have bsd(mirror(ad0,ad1)), then I want the mirror. The reason is that bsd is a partitioning scheme and since I'm writing a partitioning tool, I'm working on the geom that's being partitioned. In an ideal world all partitioning schemes are handled by g_part, which means I can look for the g_part class and have them all, but for now I need to hardcode the numerous classes. I think when there's no partitioning class involved, then the highest ranking geom that has a provider may give me what I want. I think it would exclude "users" like VFS and DEV. Thanks, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Sat Feb 10 21:55:00 2007 Return-Path: X-Original-To: geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03FD216A406 for ; Sat, 10 Feb 2007 21:55:00 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id BDF9D13C4A8 for ; Sat, 10 Feb 2007 21:54:59 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 134611747B; Sat, 10 Feb 2007 21:54:57 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l1ALsvIp017225; Sat, 10 Feb 2007 21:54:57 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 10 Feb 2007 10:23:32 PST." <5BB89CF0-69CE-4A93-828B-298A13CD0F67@mac.com> Date: Sat, 10 Feb 2007 21:54:57 +0000 Message-ID: <17224.1171144497@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: geom@FreeBSD.org Subject: Re: g_part partition tool -- some logistic questions 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, 10 Feb 2007 21:55:00 -0000 In message <5BB89CF0-69CE-4A93-828B-298A13CD0F67@mac.com>, Marcel Moolenaar wri tes: >I'm writing a partitioning tool, I'm working on the >geom that's being partitioned. In an ideal world all >partitioning schemes are handled by g_part, which >means I can look for the g_part class and have them >all, but for now I need to hardcode the numerous >classes. If you're working from the XML, consider having the classes announce themselves to you in XML ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Sat Feb 10 22:04:31 2007 Return-Path: X-Original-To: geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 47B8E16A400 for ; Sat, 10 Feb 2007 22:04:31 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.175]) by mx1.freebsd.org (Postfix) with ESMTP id 3530B13C478 for ; Sat, 10 Feb 2007 22:04:31 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout05/MantshX 4.0) with ESMTP id l1AM4UA6020788; Sat, 10 Feb 2007 14:04:30 -0800 (PST) Received: from [192.168.1.2] (c-67-164-11-148.hsd1.ca.comcast.net [67.164.11.148]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id l1AM4RI5019580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 10 Feb 2007 14:04:29 -0800 (PST) In-Reply-To: <17224.1171144497@critter.freebsd.dk> References: <17224.1171144497@critter.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sat, 10 Feb 2007 14:02:55 -0800 To: Poul-Henning Kamp X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: geom@FreeBSD.org Subject: Re: g_part partition tool -- some logistic questions 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, 10 Feb 2007 22:04:31 -0000 On Feb 10, 2007, at 1:54 PM, Poul-Henning Kamp wrote: > In message <5BB89CF0-69CE-4A93-828B-298A13CD0F67@mac.com>, Marcel > Moolenaar wri > tes: >> I'm writing a partitioning tool, I'm working on the >> geom that's being partitioned. In an ideal world all >> partitioning schemes are handled by g_part, which >> means I can look for the g_part class and have them >> all, but for now I need to hardcode the numerous >> classes. > > If you're working from the XML, consider having the > classes announce themselves to you in XML ? That's a good idea. I think I'll do that. Thanks, -- Marcel Moolenaar xcllnt@mac.com