Wandering Thoughts archives

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 like sfdisk 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.

linux/PartitioningDesire written at 16:36:52;

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.)

tech/ROWEThought written at 00:30:39;


Page tools: See As Normal.
Search:
Login: Password:

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.