Date: Fri, 9 Mar 2007 07:30:10 GMT From: jau@iki.fi (Jukka A. Ukkonen) To: freebsd-bugs@FreeBSD.org Subject: Re: bin/92723: [feature request] fdisk(8) should be able to output Message-ID: <200703090730.l297UA2n081610@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
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. + + + +
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200703090730.l297UA2n081610>