System Administration

Re: SAM Needs Disk and File System Input!

Go to solution
Jon Mattatall
Esteemed Contributor

Re: SAM Needs Disk and File System Input!

1. Full filesystems and vanishing nfs mounts.
Check with du -kx and find, manually manipulate any files or resize mountpoints/filesystems.

2a. mount/bdf are fine.
2b. a. mount point
b. source (device file)
f. free space
g. used space
d. file system type
e. total size
j. mounted/unmounted status
2c. Current commands are fine for me.
2d. Yes.

3a. e. size
f. usage (i.e. vxfs, swap, LVM, etc.)
a. device file or name
h. volume group name or mount point
3b. No.
3c. Yes, and probably yes. Any check would be nice, and I'd also find it annoying. Doesn't mean it wouldn't be a good idea, though.

4. Mapping could be clearer. I stick with Grid Manager. (Model 10/20/30)

A little knowledge is dangerous - none is absolutely terrifying!!!
H.Merijn Brand (procura
Honored Contributor

Re: SAM Needs Disk and File System Input!

And of course we *all* want *F*R*E*E* OnLine JFS :):)

Where can we sign the petition?

Enjoy, Have FUN! H.Merijn
Bill Hassell
Honored Contributor

Re: SAM Needs Disk and File System Input!

1. There are several dozen postings in the ITRC Forums about full filesystems and most of them start out with "How do I find big files to remove?" which is the wrong question. The question should be: what are the biggest directories? The reason is that while an occasional big file may show up, a large directory may be the problem but contains thousands of small files. A very useful SAM enhancement:

du -kx /some_mountpoint | sort -rn

and display the first 10-20 lines. And for 'standard' HP-UX mountpoints, SAM's help on context could provide some guidelines on 'normal' sizes for common directories like / /dev /sbin /etc / and then some guidelines on /var /uss /tmp and /var.

2. bdfmegs
bdf is leftover from the days of megabyte disks so the Kbyte values are very hard to use. (bdfmegs has been attached to this posting) Being able to display the largefile flag and the JFS version is quite useful, along with the variable length format that ensures no split lines. A new command is probably needed since bdf has a Berkeley heritage, perhaps like nslookup and nsquery.

It would be useful in a new command to see umnounted disks that have VG identifers much in the way that SAM shows importable VGs. And unmounted filesystems would be quite useful as long as long disk hangs due to hardware problems can be avoided. Additionally, there should be a special entry in fstab called nomount (like the undocumented noauto) that can document raw filesystems. The new command would then report on these raw disks as 'used' rather than assume 'unused'.

3. All the details would be useful, some as part of 1-liner summaries, but by picking one lvol, all info can be shown. See Xvg as an example of detailed info. As far as using SAM's mark facility, I don't know anyone who uses it, perhaps due to lack of publicity. Is the mark visible/useful outside of SAM? Certainly having swapon, newfs, mkfs, even dd refuse to write over marked devices would be VERY useful as many Sybase and Informix users will attest. An override (like pvcreate -f) is of course required, with a second choice to unmark the disk/lvol then the command would work. In all cases, marking controls should be available on the command line as well as SAM.

4. LUN management is quite cumbersome, requiring the sysadmin to merge knowledge about HP-UX device files and ioscan info with the vendor's cryptic (and often PC-oriented) LUN definitions.

Bill Hassell, sysadmin

Re: SAM Needs Disk and File System Input!

Thought I would clarify a bit on a couple things.

When looking into new features, we are not only concerned with SAM but are also really looking to improve the command line experience. So, if you do not use SAM, you can still help with the end goal. First and foremost, we would like to see a complete command line.

A bit more info concerning question 3. When entering SAM's Disk Devices or Logical Volumes sub areas, all disks/LVs are retrieved and then SAM collects various system information about LVM/VxVM, file systems, swap, basically any way a disk can be "used" and then indicates this in the "Usage" column. In some cases (i.e. databases) a usage cannot be easily determined so SAM allows a user to "mark" a disk as used to essentially indicate the device is in use and do not use it. This way, when a user goes to something like the file systems area and tries to add a new one, the user is not presented with the marked device in the list of disks to choose from (list of unused disks).

Thanks, SAM Team
Do You Like Green Eggs and Ham? (Sam I Am)
Honored Contributor

Re: SAM Needs Disk and File System Input!

since you can extend a logical volume online (if you have optionnal JFS-online) it would be nice to have the reduce also...
Just thoughts...

For the rest, I agree with the previous answers...(Yes bdf should display MBs)
In sam/VG it would be nice to see the pvs with I/O timeout values set (with max in ref.) and queue depth values...

All the best

Geoff Wild
Honored Contributor

Re: SAM Needs Disk and File System Input!

I mainly use the command line for disk activities.

1. Concerning file system diagnosis:

I check log files, sar, monitoring disk space via OVO.

2. We are looking into better ways to list file system information.

A. How would you like to see file systems listed?

I would like to see a nicely formatted bdf.
Currently, we do this with scripts.

B. What data do you like to see listed? Indicate all that apply but try to stick to those most important (top ~7):

a. mount point
b. source (device file)
e. total size
f. free space
g. used space
h. percent used
i. percent free
l. date last written

C. Should this data be part of a new command, an enhancement to an existing command (which one), or is there no need for anything new or different than what is available today?

Doesn't matter

D. Should a listing include file systems that are not currently mounted?

Yes, but should be optional.

3. SAM lists disk devices and logical volumes with their "usage" (i.e. LVM, file system, swap, business copy) and allows you to manually "mark" them as used

a. device file or name
c. number of paths
e. size
f. usage (i.e. vxfs, swap, LVM, etc.)
h. volume group name or mount point (with respect to what it is used for)
i. device type (i.e. cdrom, disk, optical, etc.)

B: I do not use marking facility

C: Don't care

4. What could SAM or the HP-UX commands do to make disk array LUN management, and their configuration tools easier to use?

We use EMC so I don't think this would work for us - unless you could tie into them?
What would be nice is better reporting/capacity planning.


Proverbs 3:5,6 Trust in the Lord with all your heart and lean not on your own understanding; in all your ways acknowledge him, and he will make all your paths straight.
Michael Tully
Honored Contributor

Re: SAM Needs Disk and File System Input!

1. Size checking. As rightly suggested by Bill, we should be looking at directory sizes as well.

2 (a) Well my first thought would be reporting order ... I'd like to see options to report in volume group order, alphabetical without wrapping a script around it.
2 (b) all of them, but perhaps using options on h, j & k
2 (c) options for existing command
2 (d) option
3 (a) I don't use SAM for any type of disk/vg/lv management
3 (b) no
3 (c) yes
4 We use EMC
## One further thought. When software such as MirrorDisk/UX is not installed on a system and you try to mirror a volume, perhaps an error message like "MirrorDisk/UX is not installed" as opposed to a usage message of the lvextend command. I too think that MirrorDisk/UX and OnLineJFS should be free.
Anyone for a Mutiny ?
David Ritchie
Frequent Advisor

Re: SAM Needs Disk and File System Input!

1) have ioscan ignore phantom LUN's from XP512 (and sam, and all the other utilities). By phanton LUN's, I referring to those marked as "HP DISK SUBSYSTEM" when in fact there is no disk there.

2) A quick way to map vg's into CU:ldev's on the XP512. (Similar things for Symmetrix would be useful also).

Here is a script that I wrote to do this in a basic sort of way...
------------------cut here ----------------

xpinfo -il | tail +6 >/tmp/xpinfo$$.out

for i in `echo /dev/*/group`
echo ::::::::::::::::
echo $i
echo ::::::::::::::::
for j in `vgdisplay -v \`dirname $i\` 2>/dev/null | grep "PV Name" | awk ' { print $3 } '`
grep `basename $j` /tmp/xpinfo$$.out | awk ' { print $1," ",$5," ",$6 } '
rm /tmp/xpinfo$$.out
---------------cut here----------------

3) A way other than 'strings /etc/lvmtab' to
display (and perhaps even interpret)
/etc/lvmtab's data structures. Conversely,
at least document the format via an .h file so that we can read and interpret it.

4) A way to both stripe and mirror simultaneously under LVM (without having to pay $30K for the priviledge). This is not possible currently under LVM, and would make my life much simpler. It would also allow for conversions between the two without bringing filesystems off line.

5) A way to pvmove a unstriped lvol out of a volume group that contains a striped lvol (this is not possbile currently.)

6) Fix sam so that when building striped lvols, you can pick the drive order to pull the stripes from. This may be possible by using pvg's, but it should not be necessary
to create a striped lvol.

7)document physical volume groups and how they are useful for striping...

8) document extent bases striping and why you would use this vs. lvm striping. When would you use this?

9) What are the optimal stripe sizes for various LVM volumes?

10) Write routines to manipulate the allocation and performance reporting on the
XP512... this is extremely disjoint currently.

11) Have enough knowledge of XP512 to recommend against striping within an array group (this is very bad from a performance standpoint).

Best regards,
Dave Ritchie
Adisuria Wangsadinata_1
Honored Contributor

Re: SAM Needs Disk and File System Input!

A1. In the file system size checking, especially when the usage of the file system reach the limit. I used find command to resolve this problem. It will be nice if this can be happen also on the sam plus indication if the file system reach the limit.

A2A. bdf and if possible with MBytes or there's a converter for that.

A2B. here is the list :
a. mount point
b. source (device file)
d. file system type
e. total size
f. free space
g. used space
i. percent free

A2C. if the data just an additional option, you can use the old command & only put the new option in there. But if totally new, better put as the new command 8-).

A2D. Yes, it would be nice

A3A. here is the list :
a. device file or name
b. h/w path
e. size
f. usage (i.e. vxfs, swap, LVM, etc.)
g. driver

A3B. No

A3C. extra checking is nice as long as based on request, means the extra checking will be run if we need it. Cause if all checking plus extra checking comes in 1 display, it will makes headache 8-).

A4. Very difficult and complicated I guess, but any positive changes will help us to make it easier 8-).

now working, next not working ... that's unix
David Ritchie
Frequent Advisor

Re: SAM Needs Disk and File System Input!

a terse version of the verbose output for lvdisplay - so if you perform a lvdisplay -t /dev/vg01, it would look something like:

--- Logical Extents ---
LE's PV1 PV's
00000 - 00004 /dev/dsk/c4t0d0 00000 - 00004 current

instead of
--- Logical extents ---
LE PV1 PE1 Status 1
00000 /dev/dsk/c4t0d0 00000 current
00001 /dev/dsk/c4t0d0 00001 current
00002 /dev/dsk/c4t0d0 00002 current
00003 /dev/dsk/c4t0d0 00003 current

This would make it more readable by humans.