[rescue] 72gb+ Disks in A1000

Mike Meredith mike at redhairy1.demon.co.uk
Tue Apr 12 14:31:46 CDT 2005

On Mon, 11 Apr 2005 23:22:06 -0500 (CDT), Jonathan C. Patschke wrote:
> Nice, if you have need for them.  However, I have a lot more use for
> Solaris 9 Just Working than I do for them.  

So far I don't see any signs of Solaris 10 not Just Working.

> Zones are a good start,
> but I use AIX at work.  I'm too spoiled by LPARs to have much interest
> in prissied-up jails.

LPARs are nice, but should be compared with domains (which they beat
into a bloody pulp) rather than zones. LPARs aren't available on
everything, although it is pretty much everything new now. Zones have
some advantages over LPARs (more lightweight), and LPARs have some
advantages over zones (more seperation to the extent you can have
different operating systems running).

For the record I have both LPARs and zones running production services.

> > iSCSI, and iSCSI target mode (maybe in update 1, not sure)
> iSCSI is another solution looking for a problem.  SCSI over network

I suppose it could be used to slap a big disk temporarily onto a server
that doesn't need a real SAN connection. iSCSI always looks to me like
something that was done just because it's kind of neat .... like
implementing tape drives as swap space.

> > SMF can be a plus or minus, depending on how you look at it.
> Well, I look at it as SysV init scripts Just Work and are well-
> understood (whether you love or hate them).  They can be deployed
> solve the precedence problem that SMF claims to solve, even if they do
> require it being solved by hand.  That's not a bad thing.  Knowing
> your system's startup procedure is a Good Thing.

SMF is ok, and at long last means that patching a system doesn't result
in disabled services suddenly springing back into life. At least SMF
does start things on startup unlike AIX's SRC which requires you to
manually start services in /etc/rc.tcpip (or wherever) ... unless I've
missed something.

And you can still use the old SysV mechanism.

> > XML in config files?  Blecch.
> XML is a cancer of the mind.  It's astonishingly good for a small
> class of applications, but those who deploy it feel compelled to use

I'm not a great fan of XML, but it beats Yet Another Configuration File
Format, and beats having a proprietry binary database lurking underneath
everything. Some of the XML tools out there are completely bletcherous
... for example the svccfg tools to import a new SMF 'manifest' has just
about the worst error reporting I've seen recently.

More information about the rescue mailing list