2006-12-08
What I want out of a Linux partitioning program
Programs like fdisk
, sfdisk
, and even parted
are really irritating
to deal with most of the time because they ask you too many nitpicking
questions. What I want is a partitioning program with a command oriented
'shell' interface, with the core command being:
make N SIZE [TYPE]
This makes partition N be SIZE big (with the default units being
megabytes), optionally making its type be TYPE (which can be in hex or
in English). If N is 1 to 4, it is a primary partition; otherwise it
is a logical partition and the program automatically creates an
extended partition as necessary. Partitions are allocated in order,
from the start of the disk on up. You can use 'sdaN' and the like as a
synonym for 'N'; if you do so, by default it is an error if you are
not operating on /dev/sda
or the like.
The next most important command is:
grow N TO [MAX]
This allows partition N to grow to be TO big (up to MAX size). 'TO' can be 'rest', for the rest of the disk, a percentage of the total disk size, or a size (in which case MAX is redundant). Growth requests are satisfied in order.
Then our default partitioning scheme could be expressed simply and directly:
make 1 512M # /boot make 2 2G swap # swap make 5 5G raid # / make 6 20G raid # /usr make 7 5G raid # /var make 8 2G raid # /tmp make 9 1M raid # rest grow 8 10% 4G grow 9 rest
An if
command that let me conditionalize things on at least the
total disk size would also be handy (and avoid the temptation to have
make
and grow
grow too many options).
This omits a great many advanced features that are part of fdisk
et al that we never use in practice, in favour of doing the right
thing by default. (If I need the advanced features, I can always
drag out fdisk
(or ideally cfdisk
, which I like much better;
unfortunately, Fedora Core has not packaged it for some time).)
Some existing programs come close:
- GNU parted has the command shell approach, but makes me specify the starting point of partitions. I don't want to have to do that, because the answer is always 'after the previous one'.
sfdisk
can do this, but has an interface in the finest Unix traditions of, say,ed
. (I really likesfdisk
for what it does well, but manual partitioning is not really one of those things.)fdisk
has no command line mode. While I can feed it standard input, I'd have to tediously navigate through text menus.
(The 'grow the last partition to the rest of the disk' is the piece
of grow
that I really care about; other things are gravy.)
(These are all the Linux partition editors that I know of, apart from
qtparted and gparted, which are parted frontends, and cfdisk
, which
is entirely curses-based. If there's others, let me know.)
Since I've now discovered that sfdisk
comes closest to what I want,
and I can actually write a command file for it, I expect that it's
what I'll use in the future for this kind of thing. It may be arcane,
but it's less tedious than fdisk
.
Why I don't expect result-oriented work hours to work out
A recent Slashdot story pointed to this article on one company's more flexible approach to work hours. It has the line:
The goal at Best Buy is to judge performance on output instead of hours.
My immediate cynical reaction is that this is a marvelous theory but doomed in most practices. The root problem is the same seductive thought in management that leads to excessive overtime: 'if my employee is getting all this done in N hours now, think how much more work she could do in N+Y hours!'
Or in other words, if employees have idle time you're clearly not working them hard enough. ('Giving them enough work' is the more polite but less brutally honest version.)
(I suppose that ultimately this is a variant of Brooks' Law, in that it is management treating all hours of work as equivalent when they aren't. In Brooks' Law the additional hours come from new people instead of existing people, but the core mistake is the same.)
One ultimate end point of this whole idea is a pattern we've already seen: piece-work, where people are paid by the result. Interestingly, I understand that auto mechanics often work this way; there is a fixed charge for many repairs, based on the nominal time it should take, and a skilled mechanic who can do them faster than average can benefit significantly. (Applications to system administration are left as an exercise.)