[5829] in Release_7.7_team
Re: Linux Athena and SATA operation modes
daemon@ATHENA.MIT.EDU (andrew m. boardman)
Tue Sep 4 11:29:47 2007
Message-Id: <200709041529.l84FT49v025292@pothole.mit.edu>
To: amu@alum.MIT.EDU, jdreed@MIT.EDU
cc: release-team@MIT.EDU
In-Reply-To: Your message of "Thu, 30 Aug 2007 20:07:08 EDT."
<udl8x7so9cj.fsf@vinegar-pot.mit.edu>
Date: Tue, 04 Sep 2007 11:29:04 -0400
From: "andrew m. boardman" <amb@MIT.EDU>
X-Spam-Flag: NO
X-Spam-Score: 0.00
Aaron:
> How about converting to a largely device-name-independent setup based
> on UUIDs or labels?
This is actually a good idea, and I'd like to go with a label approach.
Historically, hotline has had to do a lot of fscking to recover machines
without a reinstall (and having consistent partition names is helpful
there; I know exactly what Lou means when he talks about "that hda6
problem"), but given that we're now running ext3 everywhere that it
matters we've got more of a reason to overcome inertia and we'd get a
lot of fringe benefits for maintainability.
Jon:
>If someone does manage to shoot themselves in the foot, what is the
>recovery process?
Assuming supported hardware, you can always change the BIOS setting to
match whatever the software configuration is and the system will boot.
The worst-case (but, given human nature, not-unlikely) scenario here is
having the script forced on hardware that isn't really SATA-based. If
we're using filesystem labels in grub.conf and fstab any other problems
go away (they get a bogus scsi_hostadapter driver entry and an extra
initrd driver, but it doesn't really hurt anything), but otherwise, while
the grub invocation can be changed on the fly (I can envision talking
someone through this on the phone without too too much pain), fixing
/etc/fstab becomes at least mildly horrendous. (Boot install media,
mount root filesystem, edit file...)
>Looking at it, I assume the shell script is run first, and then the user
>makes the BIOS change upon reboot? I'd kind of like the script to trap
>SIGINT et al and after the conversion, inform the user that they must now
>reboot and frob the BIOS settings, and prompt them to press a key to
>reboot, or something, so it's all a one step process, rather than having
>them run the script and then reboot 2 hours later and forget what they
>were supposed to do.
That's all quite reasonable and I'll implement it thus. I also added a
sanity-check to punt in case of a scsi_hostadapter setting already being
present, and I want to figure out why I removed the compatability
sanity-check (it's actually a fairly old script) and re-enable it.
Thanks for the support perspective; thinking about it has convinced me to
develop the script a bit more for use in special cases but to not
advertise it unless/until we switch to filesystem labels. I've tested
things both ways a bit more, and (at least on my Dell boxes here) native
SATA support starts becoming noticably nicer when I'm badly blocking on
disk io, but that's the case for neither my use nor, I believe, typical
use. (Bursty transfers (like swapping) are either faster or just not
slow enough to be noticable.)
