bin/92723: [feature request] fdisk(8) should be able to output

Jukka A. Ukkonen jau at iki.fi
Fri Mar 9 07:30:11 UTC 2007


The following reply was made to PR bin/92723; it has been noted by GNATS.

From: jau at iki.fi (Jukka A. Ukkonen)
To: bug-followup at 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. + + + +


More information about the freebsd-bugs mailing list