Very Computer

My personal favorite is the Advanced File System.

It is crash proof.  Never fear someone accidentally pulling the plug on a
workstation.  I am responsible for about 75 systems and I haven't lost a filesystem
in over 5 years.  You'll never fsck again !

Also, the ability to create/re-size "partition" (they are actually call filesets) **
ON THE FLY ** is INVALUABLE !!  How else can you reasonably deal with a RAID set over
100 Gb ?

Add your personal favorite OSF1/DUNIX/Tru64 "feature" to this list.

Carly, are you listening ?  (Curly sure wasn't !)

--

Jack Patteeuw

: My personal favorite is the Advanced File System.

: It is crash proof.  Never fear someone accidentally pulling the plug on a
: workstation.  I am responsible for about 75 systems and I haven't lost a filesystem
: in over 5 years.  You'll never fsck again !

: Also, the ability to create/re-size "partition" (they are actually call filesets) **
: ON THE FLY ** is INVALUABLE !!  How else can you reasonably deal with a RAID set over
: 100 Gb ?

: Add your personal favorite OSF1/DUNIX/Tru64 "feature" to this list.

: Carly, are you listening ?  (Curly sure wasn't !)

: --

How is that different from the AFS that HP-UX has had since 10.20?

--
Jim Hollenback

my opinion.

Quote:> Okay, HP, you won !  You've got the $$$'s, so you get to call the shots.
> "Unix is is
> Unix" (yeah, right, and I have a bridge to sell ...), but there are a
> few things you
> should really look at before "throwing the baby out with the bath water"

> My personal favorite is the Advanced File System.

I've seen you post quite a bit in the last few months on comp.unix.tru64, and
most of the time I agree with you.  Here, I think you're wrong.  I've
been using Tru64 since the days when it was known as OSF 3.2, and I got
my UNIX start on HP-UX 8.07 in '91, so I've been familiar with both platforms
for a long time.

While AdvFS has become much better in the last few years, and LSM (aka
Veritas VxVM) is the most widely used (contrast that with *best*) lvm
implementation for commercial UNIX, HP's filesystem offerings are *much*
better than Tru64's.

Rather than buying/porting the most widely used products and writing their
own journaling filesystem, HP adopted the *best* LVM out there (IBMs) and the
best commercial filesystem (VxFS) of the day (still a great fs, only some of
the newer filesystems of today would have a chance of claiming "best" over
it).

I've used Veritas' vxvm on Sun and as LSM on DU/Tru64.  While doing everything
you need from an LVM, it stinks in comparison to IBM's volume manager (which
is what HP-UX 10.x + later have).  With vxvm, you always know there are
partitions underneath.  It's complex, and if you look at it long enough, you
see how ugly it is.

Contrast that with IBM's LVM, which doesn't have the "lvm on top of partitions"
problem.  It's much cleaner looking, and it's easy to use.  Also, the HP-UX
command set for LVM (most of the command names were changed when HP ported
IBM's LVM, even though underneath they're they have the same ancestor) is
the one that Linux adopted for LVM.

AdvFS is pretty stable these days and the "shared space from one domain for
many filesets" concept is pretty cool, but Veritas' filesystem is an excellent
filesystem.  HP calls it `jfs', but it's just VxFS.  It's solid, and has
been solid for a few years.

Quote:> It is crash proof.

Quote:>  Never fear someone accidentally pulling the plug on a
> workstation.  I am responsible for about 75 systems and I haven't lost a
> filesystem
> in over 5 years.  You'll never fsck again !

As I said, I've used both DEC/Compaq and HP UNIX for a long time.  They
actually share a lot in common, and I like them both a lot.  Tru64 edged
out HP-UX as my favorite UNIX a few years ago, but I like to think I am
good at seeing the strong points of all the UNIX flavors I work with (even
IRIX!), and also noticing the weak points.  HP's filesystem & LVM offerings
aren't weak, and I think they're quite a bit better than Tru64's.

Tim
--

Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

Quote:> AdvFS is pretty stable these days and the "shared space from one domain for
> many filesets" concept is pretty cool

I'll admit I don't know anything about the other filesystems you mentioned as well as
LSM.  AdvFS is "standard equipment", and being able to create filesets on the fly is
worth it's weight in gold to me.  We have > 80 Gb RAID sets on our HSZ80 that I would
hate to ever have to "hard" partition.

So what options do I have for on the fly partitioning ?

Jack Patteeuw

"Probing" SCSI devices and getting useful information from the running OS (i.e. file
/dev/rrz*c).  I think this came from Ultrix, but it is another thing about Tru64 I
love.

Jack Patteeuw

This may be an OS feature and/or a feature of Digital SCSI disks.  When a block get
"re-vectored" (I hope that is the right terminology) the OS keep track of the count,
at least until the next reboot.  The error logger records this and it can be read by
one of the tools provides (Bring back uerf !  It's simple, fast and get the job done
Period)

I don't know how Solaris or HP UX admins have a clue that a disk is "going bad" until
it is too late.

--

Jack Patteeuw

Ken

--

Tru64.org, http://www.tru64.org
Tru64.org Newsletter:
http://www2.tru64.org/pages.php?page=Newsletter-Registration

--
Purring: an automatic safety-valve device for dealing with happiness overflow.

ICQ UIN: 2295979
WWW: http://www.saturnus.com/~krynos/

I'm not a big fan of predictive due to the two way communication that it
requires, even with email... however, it has helped in many circumstances.
Sounds like the tool you describe may be a good idea though to add for HP.
Of course, the best way to handle disk failures is to mirror or use RAID.

Seldan

Quote:> One more and I'm done (for a while).

> This may be an OS feature and/or a feature of Digital SCSI disks.  When a
> block get
> "re-vectored" (I hope that is the right terminology) the OS keep track of the
> count,
> at least until the next reboot.  The error logger records this and it can be
> read by
> one of the tools provides (Bring back uerf !  It's simple, fast and get the
> job done
> Period)

> I don't know how Solaris or HP UX admins have a clue that a disk is "going
> bad" until
> it is too late.

Quote:> HP-UX disks are composed of extents that are 4mb in size.  Typically when
a
> disk goes bad, the extents will become stale as those portions of the disk
> cannot be written too.  Of course, this will shouw that a disk is bad, not
> going bad.  For a more proactive approach, read/write errors can also be
> logged via predictive services so that a disk can be replaced before it is
> too late.  HP-UX will also typically record SCSI lbolt resets and
powerfails
> to the syslog which are indications that a particular device may be going
> bad.

> I'm not a big fan of predictive due to the two way communication that it
> requires, even with email... however, it has helped in many circumstances.
> Sounds like the tool you describe may be a good idea though to add for HP.
> Of course, the best way to handle disk failures is to mirror or use RAID.

- bill

This is even more annoying than Terry's posting style. Why not trim excess
text out of the message you're responding to, so people don't have to hunt
for the relevant part?

--
 `-_-'   In hoc signo hack, Peter da Silva.
  'U`    "A well-rounded geek should be able to geek about anything."

         Disclaimer: WWFD?

Quote:>> I'm not a big fan of predictive due to the two way communication that it
>> requires, even with email... however, it has helped in many circumstances.
>> Sounds like the tool you describe may be a good idea though to add for HP.
>> Of course, the best way to handle disk failures is to mirror or use RAID.
>No, that's just one element of protection.  If you mirror (or use parity
>RAID) and *don't* also check for accumulating errors, there's a far higher
>probability that if one of your disks fails you'll find something you can't
>read on its partner.

And this still doesn't cover all failure modes. I have seen a failed
mirrored disk cause a kernel panic - the SCSI bus was just filled with
garbage, probably enough to cause the controller card to malfunction
too... and yes, everything was mirrored to the other SCSI bus, but that
just wasn't good enough when you still had only one backplane.

My point: don't think you can eliminate all possible failure points.

--

My ideas, not my employer's. No warranty. YMMV.
#include <disclaimer.h>

However, high-availability wasn't the subject under discussion:  it was
avoiding data loss.  In that context, one doesn't care about the kinds of
failures you mention, since the data will still be there after you fix them.

- bill

Quote:> Carly, are you listening ?  (Curly sure wasn't !)

From reading the posts so far, I would add LVM and vxfs to Tru 64.  On
the Tru 64 side, the features to look at are "probing scsi devices"
and better predictive support for disk drives.

I'm sure experienced HP-UX admins can come up with plenty of shortcomings
in Tru64 that you, as apparently an experienced Tru64 admin, could say
"no, that's easy to do in Tru64, you just have to do xxx"  All this
thread shows is that admins who are strong on one OS and weak on another
will find lots of shortcomings in the weak one, but few that are from
anything other than lack of expertise with that OS.

This is also why less clueful people often end up thinking that Windows
systems offer better diagnostics than Unix, because you can randomly poke
around in various GUIs and click on random admin programs in Win2K and
discover useful stuff, but most people won't go looking in /usr/sbin and
trying programs with odd names like 'ioscan' with random flags until they
get some useful things to happen (the really clueful ones might think to
read the man page, but unforunately only some of them are capable of
understanding it)

This is of course why you have books on the market like "Solaris for
HP-UX admins", and vice versa.

--

I have discovered a remarkable proof which this .sig is too small to contain!