How to map a file's space usage to the PVs it resides on?

[Somckit]

Dear HP-UX experts,

I'm on HP-UX 11.23 with Online JFS version 4.1.008 using LVM.

My question is about how to map a file's space usage to the PVs (there are multiple PVs) in a VG.

I know I can see what PVs make up the LV (i.e with lvdisplay) but this is not granular enough...I'm trying to map file space (i.e. Oracle datafiles) to the PV(s) the file resides on.

I looked at vxtrace but thought that it would not work since I'm not actually using the Vx filesystem (rather Online JFS)...please feel free to clear this up if I am confused.

Thank you much!

[Alzhy]

"I looked at vxtrace but thought that it would not work since I'm not actually using the Vx filesystem (rather Online JFS)...please feel free to clear this up if I am confused."

OnLine JFS == Veritas Filesystem (VxFS)

All techniques for VxFS apply to OJFS or JFS...

[Somckit]

Hi,

Thanks much...maybe you could elaborate more?

I tried to run vxtrace but got this error:

VxVM vxtrace ERROR V-5-1-1392 Volume configuration daemon is not accessible

Does this mean that I have to enable the vxconfigd daemon?

After enabling the daemon, would I have to import my existing JFS (vxfs) files into the daemon's config...

Sorry if they are basic questions...your help is appreciated!

[Alzhy]

To locate where in the FILESYSTEM and where on the LVOL and where in the disk a particular contigous or non-contigous file resides, you will I think NEED to write C code...

See man fs_vxfs(4).


I do not think there is a single tool to allow you to pinpoint where on the FIlesystem a file resides which is the first step. Once that is done and you have an idea what offset the LVOL which the FIlesystem resides on -- you will be able to pinpoint on which PV and offsets thereat your File uses.

[Somckit]

OK, thanks...so I'm heading down the wrong path with vxtrace?

Has else anyone tried to find this out before?

I'm trying to understand if my I/O is evenly distributed among my available LUNs...

I've pulled data from the Oracle level (v$filestat) and from the LVM to PV level but confirming that a file resides on a or on any LUN seems to be next to impossible..thus I was looking at vxtrace.

Thanks for your help...please let me know if you've solved a similar dilemma...

[James R. Ferguson · Accepted solution]

Hi:

To map a file systems utilization to physical extents, you can use 'nckeck'.

Do something like:

# ncheck -osector- /dev/vgNN/lvolXX

Regards!

...JRF...

[Somckit]

Thanks much James, you're AWESOME...

Can I get your help to read this correctly?

sectors(9999999) blocks(9999999)
----------------- -----------------
0/1-0/9999999 0/1-0/9999999

fileset fset match match devid/
name indx inode indx inode sectors name
---------- ---- ------ ---- ------ ------------- ------------------

...snip...


UNNAMED 999 5 - - 0/7744168 /acm/.
UNNAMED 999 4 - - 0/3637248-0/3648135 /undo_2/undo.data2
UNNAMED 999 4 - - 0/3604480-0/3637247 /undo_2/undo.data2
UNNAMED 999 4 - - 0/3571712-0/3604479 /undo_2/undo.data2
UNNAMED 999 4 - - 0/3538944-0/3571711 /undo_2/undo.data2
UNNAMED 999 4 - - 0/3506176-0/3538943 /undo_2/undo.data2
UNNAMED 999 4 - - 0/3473408-0/3506175 /undo_2/undo.data2
UNNAMED 999 4 - - 0/3440640-0/3473407 /undo_2/undo.data2
UNNAMED 999 4 - - 0/3407872-0/3440639 /undo_2/undo.data2
UNNAMED 999 4 - - 0/3375104-0/3407871 /undo_2/undo.data2
UNNAMED 999 4 - - 0/3342336-0/3375103 /undo_2/undo.data2
UNNAMED 999 4 - - 0/3309568-0/3342335 /undo_2/undo.data2
UNNAMED 999 4 - - 0/3276800-0/3309567 /undo_2/undo.data2
UNNAMED 999 4 - - 0/3244032-0/3276799 /undo_2/undo.data2


...snip....


Is devid the PV?

Or maybe I should ask how would I map the above output to an lvdisplay?

[James R. Ferguson]

Hi (again):

> Or maybe I should ask how would I map the above output to an lvdisplay?

A file may (generally) occupy some range of sectors which may or may not be one group. For each range (in sectors or in blocks) compute which logical extent that would be.

For example:

# ncheck -oblock=- /dev/vgNN/lvolXX

...blocks(65537)...

# lvdisplay /dev/vgNN/lvolXX

...Current LE 64

...and thus 65536/64 = 1024

...so blocks 0-1023 occupy LE #1, etc.

Regards!

...JRF...

[Emil Velez]

Why not let the performance agent collect LV and physical volume data while your run the oracle database and that should tell you whether the I/Os are balanced across multiple disks.

YOu can get I/O by disk
I/O by filesystem
I/O by logical volume

when you create the LV you can stripe it across multiple disks which should spread data out.

[Somckit]

Hi Emil,

You have good points and I would say 1 should strive for that state, but for whatever reason(s) some folks are not quite there yet...

Also, when you are "digging" into issues you'll need more low level data and confirmation that what you really think is happening really is...