From owner-freebsd-bugs@FreeBSD.ORG Fri Mar 9 07:30:11 2007 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0EB6C16A401 for ; Fri, 9 Mar 2007 07:30:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id D530113C442 for ; Fri, 9 Mar 2007 07:30:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l297UAKm081611 for ; Fri, 9 Mar 2007 07:30:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l297UA2n081610; Fri, 9 Mar 2007 07:30:10 GMT (envelope-from gnats) Date: Fri, 9 Mar 2007 07:30:10 GMT Message-Id: <200703090730.l297UA2n081610@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: jau@iki.fi (Jukka A. Ukkonen) Cc: Subject: Re: bin/92723: [feature request] fdisk(8) should be able to output X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Jukka A. Ukkonen" List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2007 07:30:11 -0000 The following reply was made to PR bin/92723; it has been noted by GNATS. 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. + + + +