[sf-lug] sfdisk (& caution!, & usefulness!) [Re: How linuxmafia.com got back to being operational again :-)]

[Michael Paoli]

> Date: Sun, 25 Jan 2015 23:09:17 -0800
> From: Rick Moen <rick at linuxmafia.com>
> Subject: [sf-lug] Red: How linuxmafia.com got back to being
> 	operational	again :-)
> Message-ID: <20150126070917.GL7354 at linuxmafia.com>

> I have to say:  sfdisk and mdadm
> really rock!

Well, the one caveat I try to *always* give with sfdisk (and I did so
on-site, verbally - or at least touched upon), is that one needs be
quite cautious with sfdisk.  Most notably, by default, if one doesn't
give sfdisk options, sfdisk will be writing and altering partition
table, with standard input specifying the new partition table.  That's
usually not what one wants if one does something like interactively
type:
# sfdisk /dev/sda
And if one finds oneself in that situation accidentally, SIGINT
(typically control-C from the keyboard) is generally what one wants to
do ... and absolutely anything but EOF (control-D).

That being said, with that caveat, and cautious use, I find sfdisk to be
an invaluable tool for *many* partitioning operations.  It's certainly
"lower level" and not nearly so (or hardly at all) "user friendly" or
"interactive", but if one knows exactly what one wants to do with
partition table, it's great.  It's also very handy for backing up and
recreating partition tables, copying partition tables to matching or
similar device.  It also has lovely options to backup and restore
changes to partition editing - this is especially noteworthy for
logical partitions, as there are little partition header bits on those
chained across disk - so one can't always undo a partition change by
merely writing the partition data as it was before - as change may
involve writing to sectors beyond the primary partition table - and
reversing that to get to where things were before (e.g. did that
accidentally happen in the middle of data that one wants to preserve),
one has to have the sector(s) backed up before they're overwritten - well,
sfdisk has options to be able to do that.   I also use sfdisk regularly
in my backup scripts, as part of the meta-data gathering, both in
sfdisk -uS -d (the more machine/sfdisk friendly format), and also
sfdisk -uS -l (the more human readable format).  sfdisk also,
(sometimes with a bit of use of force option), will also let you write
*any* legal partitioning whatsoever, and let you control down to the
512 byte sector exactly how one wants to lay things out (and one can
also screw up performance or flash wear by getting this "wrong").  Oh,
and if one wants to really understand exactly how things are laid out
with extended and logical partitions, it has a lovely -x option, e.g.:
# sfdisk -uS -l -x /dev/sda
And, as a somewhat relevant aside, the *best* documentation I've ever
run across for highly well understanding the (PC) partitioning scheme
and how that works, I found (of all places) in the LILO documentation -
I've yet to see it better documented anywhere else.

Also, I don't think sfdisk supports GUID Partition Tables (GPT) yet (or
at least not on the stable/production version on my Linux
distribution), but I certainly hope such support gets added to sfdisk
... or at least if not sfdisk, hopefully something will pick up such
capabilities as sfdisk has and make them likewise available for GUID
Partition Tables (GPT).