More Quality Funcktionality From Sun

Last updated: Tue, 09 Jan 2007 11:01:00 GMT

Sigh.

Lofiadm, the commandline tool used to add, remove and query the status of loopback filesystem in Solaris. Loopback filesystems are files mounted as devices, not to be confused with loopback mounts, where one part of a local filesystem is mounted simultaneously at another point on the local filesystem.

Newsflash already, Sun-boys: lofi should have been implemented such that I could put entry in fstab -- sorry, vfstab, what kind of retard calls their fs tab "fstab"? -- and call mount. A solid half of the horrible breakage I've had to deal with with zone hosting and zone patching is because I'm using lofi to mount files as devices to home zone root filesystems. I've had to hack up an awful lot of crap to make that work the way it would have if lofi filesystems were accomodated as they should be.

Thought it purports to present a real device, sustaining of a real filesystem, lofi doesn't play well with smpatch, it doesn't play at all with Live Update. Sweet.

Anyway, I've been hacking further at the scripts I've had to put in place to get those lofi devices mapped in and the filesystems contained therein verified by fsck. I've been doing it serially, forcing a full fsck, but my boot time has swollen to disfiguring proportions. So, I'm breaking it down into more, shorter phases, parallelising, switching to preening with fsck. Good results. But I've found a few gotchas with lofiadm.

Firstly, it seems that there's an arbitrary limit on the number of lofi devices one can have mounted at any time. That arbitrary limit is 128. I wish I'd found that out earlier, but I don't know what I'd have done instead. I'll just have to live with it or start hacking my own kernel together from OpenSolaris source. It's put paid to my proposal to ditch the RAM-backed tmpfs that my zones enjoy and replace it with a separate lofi /tmp device for each zone -- let's not get into that right now.

Secondly, and most annoyingly, there's a control device (called /dev/ lofictl, in what amounts to an earth-shattering policy shift for Sun: let's call it something obvious) that lofiadm opens in order to effect changes. Sadly, it opens it for a fair old while, for write, non-blocking. This means that if you're backgrounding multiple calls to lofiadm, you're going to get a lot of them failing.

They fail with the message:

lofiadm: /dev/lofictl: Device busy

Fair enough. I can see what's going on. So, what I need to do is just write me a loop that tests the exit code and retry the lofiadm command indefinitely. Well, that'd be peachy-keen, except that:

EXIT STATUS

    The following exit values are returned:

        0    Successful completion.
        >0   An error occurred.

Lazy bastards. Testing indicates that they never went as far as a distinction between recoverable and unrecoverable errors, at least not so far as to be any use to me -- everything comes back "1". So, my choice is to loop forever on a potentially fatal error or time out.

I'm timing out, and I'm praying that I don't get bitten.

There are a couple of other solutions -- I could break the phases down further and keep the lofi mounts serial, or I could actually parse the output, but I'm hoping that they'll improve it some time. Maybe they're waiting for their community to come along and finish all those things they started, even if they started it, like this, eight years ago. Maybe that's what I should do instead of bitching.