From nobody@FreeBSD.org  Thu Feb  2 08:23:14 2006
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 83D2916A420
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  2 Feb 2006 08:23:14 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 382AD43D53
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  2 Feb 2006 08:23:14 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k128NEpv012822
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 2 Feb 2006 08:23:14 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id k128NDKP012820;
	Thu, 2 Feb 2006 08:23:13 GMT
	(envelope-from nobody)
Message-Id: <200602020823.k128NDKP012820@www.freebsd.org>
Date: Thu, 2 Feb 2006 08:23:13 GMT
From: Jukka Ukkonen <jau@iki.fi>
To: freebsd-gnats-submit@FreeBSD.org
Subject: fdisk should be able to output current slice table in configuration file format
X-Send-Pr-Version: www-2.3

>Number:         92723
>Category:       bin
>Synopsis:       [feature request] fdisk(8) should be able to output current slice table in configuration file format
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Thu Feb 02 08:30:05 GMT 2006
>Closed-Date:    Fri Mar 23 22:36:18 GMT 2007
>Last-Modified:  Fri Mar 23 22:36:18 GMT 2007
>Originator:     Jukka Ukkonen
>Release:        6.0-STABLE
>Organization:
private person
>Environment:
FreeBSD metabo 6.0-STABLE FreeBSD 6.0-STABLE #4: Mon Jan 30 22:45:06 EET 2006     root@metabo:/usr/obj/usr/src/sys/Metabo  i386
>Description:
              Currently fdisk writes only verbose output.

1) Often it would be nice to be able to clone the fdisk slice setup to
another disk of the same model (say you are preparing mirrored volumes).

2) Often it would be nice to be able to store the exact fdisk slice setup
as a backup in case you need to replace and rebuild a disk.
I tend to dump the contents of file systems and the current disklabel
(bsdlabel) when doing backups. Having also the slice table stored safely
in a reusable format would help complete disk rebuilding a lot.

In both of the previous situations it would be preferable to have fdisk to
output the read slice table in the configuration table format to be able
to further feed it to another fdisk instance as input.

At the moment this is not possible or at least not a documented feature.
A good configuration program should always be able to write out the same
format it requires on input.

>How-To-Repeat:
              OK - just try to recreate from scratch some disk you already have
such that there is one slice for actual file system and another for swap.
Obviously you might wish to mirror the file system slice, but since the swap is
ephemeral data and used in interleaved manner in any case, you do not wish to
mirror the swap area. You simply specify two independent swap areas.

So, assume you build a mirror from two disks with suitable slices for the
above schenario, but you use disks which are not equal in size. Now just assume
you will need to rebuild the larger disk, because the old one has a hardware
failure.
Currently you cannot copy the slice tables, and even if you could, you would
prefer to rebuild the slice table on the replaced disk from a backup copy,
because there larger disk might have had extra space sliced for other purposes.

>Fix:
              Extend fdisk with a new command line option and a whole new feature.

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-i386->freebsd-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Tue Feb 21 21:38:42 UTC 2006 
Responsible-Changed-Why:  
This is not i386-specific. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=92723 

From: Alex Kozlov <spam@rm-rf.kiev.ua>
To: bug-followup@FreeBSD.org, jau@iki.fi, spam@rm-rf.kiev.ua
Cc:  
Subject: Re: bin/92723: [feature request] fdisk(8) should be able to output
	current slice table in configuration file format
Date: Thu, 8 Mar 2007 10:52:01 +0200

 Hi
 
 fdisk -s is close enough
 
 
 --
 Adios

From: jau@iki.fi (Jukka A. Ukkonen)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/92723: [feature request] fdisk(8) should be able to output
Date: Fri, 9 Mar 2007 08:49:27 +0200 (EET)

 Quoting Alex Kozlov:
 > 
 > fdisk -s is close enough
 
 	If you are willing to do somewhat slow and also error prone
 	manual labor to recreate the exact same slices you have had
 	on another disk, then it is close enough.
 
 	If you want a production level approach to be always able
 	to automatically rebuild the same slices from another disk,
 	it is not close enough.
 	You now have to either manually convert the incompatible
 	current output to a compatible input file or manually feed
 	whatever slice specifications to rebuild.
 	Neither of which is really "production quality automation".
 
 	We already have bsdlabel/disklabel reading and writing the
 	same format which allows copying and rebuilding the exact
 	same partitions.
 	We already have "mount -p" to print out all currently mounted
 	volumes or individual new mount points as fstab entries to
 	automate mounting selected volumes to the same locations they
 	are currently mounted to. (I.e. "mount -p" writes properly
 	formatted configurations for "mount -a" to read.)
 	I personally donated the -p functionality, because Sun had it
 	while we did not. So, in that sense I think I know what I am
 	talking about.
 
 	Fdisk is an exception in this series, and clearly not really
 	production quality as it cannot read its own output.
 
 	Your "close enough" assumes willingness for laborous and error
 	prone human action.
 	I am no way claiming using "fdisk -s" output is not doable.
 	It certainly is doable given some time and risking human error.
 	I am claiming it is not worthy of a production quality system.
 
 	Assuming you are intending to use the rebuilt slices e.g. as
 	parts of geom mirrors they have to match exactly. Any rounding
 	error or mistyping etc. will cause a failure to insert the
 	slice to the mirror while the clock is ticking all the time.
 	This happened to me once and it is definitely not production
 	quality, if quick recovery suddenly becomes wrestling with
 	fdisk.
 
 	So, close enough is not actually close enough. It is artistic
 	approach fitting maybe Linux, but we are not just Linux, right?
 
 
 	Cheers,
 		// jau
 .---  ..-  -.-  -.-  .-    .-  .-.-.-    ..-  -.-  -.-  ---  -.  .  -.
   /    Jukka A. Ukkonen,                             Oxit Ltd, Finland
  /__   M.Sc. (sw-eng & cs)                    (Phone) +358-500-606-671
    /   Internet: Jukka.Ukkonen(a)Oxit.Fi        (Home) +358-9-6215-280
   /    Internet: jau(a)iki.fi
  v
         .---  .-  ..-  ...-.-  ..  -.-  ..  .-.-.-  ..-.  ..
 + + + + My opinions are mine and mine alone, not my employers. + + + +

From: Alex Kozlov <spam@rm-rf.kiev.ua>
To: bug-followup@FreeBSD.org, jau@iki.fi, spam@rm-rf.kiev.ua
Cc:  
Subject: Re: bin/92723: [feature request] fdisk(8) should be able to output
	current slice table in configuration file format
Date: Fri, 9 Mar 2007 10:52:01 +0200

 On Fri, Mar 09, 2007 at 07:30:10AM +0000, Jukka A. Ukkonen wrote:
 >  Quoting Alex Kozlov:
 >  > 
 >  > fdisk -s is close enough
 >  
 >   If you are willing to do somewhat slow and also error prone
 >   manual labor to recreate the exact same slices you have had
 >   on another disk, then it is close enough.
 >  
 >   If you want a production level approach to be always able
 >   to automatically rebuild the same slices from another disk,
 >   it is not close enough.
 >   You now have to either manually convert the incompatible
 >   current output to a compatible input file or manually feed
 >   whatever slice specifications to rebuild.
 >   Neither of which is really "production quality automation".
 fdisk -s $dev|perl -ne 'if(/^(.*?):\s+(\d+)\s+cyl\s+(\d+)\s+hd\s+(\d+)\s+sec/)\
 {print "g c387621 h16 s63\n"}elsif(/^\s+(\d+):\s+(\d+)\s+(\d+)\s+([\da-z]+)\
 \s+([\da-z]+)\s*$/){print "p $1 $4 $2 $3\n";if ($5 eq "0x80"){print"a $1\n"}}'
 
 Too lazy to write in awk or shell. Sorry.
 
 >   We already have bsdlabel/disklabel reading and writing the                                  
 >   same format which allows copying and rebuilding the exact                                   
 >   same partitions.                                                                            
 >   We already have "mount -p" to print out all currently mounted                               
 >   volumes or individual new mount points as fstab entries to                                  
 >   automate mounting selected volumes to the same locations they                               
 >   are currently mounted to.
 Generally, I do not object against this functionality. But more useful
 enhancement to fdisk like pr 68312 or 40597 were not commited, so this
 has a slim chances.
 
 
 --
 Adios
 
State-Changed-From-To: open->closed 
State-Changed-By: maxim 
State-Changed-When: Fri Mar 23 22:33:53 UTC 2007 
State-Changed-Why:  
Superseded by bin/110182. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=92723 
>Unformatted:
