From: Kevin Davisson (kdavis@woodward.com)
Date: Mon Sep 23 2002 - 12:32:32 EDT
Several people have been offering tips and suggestions and asking for more
info, so here's more details:
At the hardware level, both LUN's were created with RAID5 and an 8k stripe
depth
fcmsutil shows no appreciable differences in the configuration of the new
card -vs- the replaced card
Both VG's created by SAM with identical PE size (4mb)
Both lvols created by SAM - only difference is allocation; source is
strict/contiguous - target is just strict
Both filesystems are JFS (vxfs) filesystems created with SAM.
The vxtunefs command shows identical parameters for both.
the command to copy the data was a simple : cd /olddir;find . -depth -print
| cpio -pdmx /newdir
When that gave me the size inconsistency, I deleted it, recreated a clean,
empty filesystem, and
restored the data from the full OmniBackII backup, with identical results.
I realize that certain sparse files "could" get expanded - but there is no
database involved, just a half a million files comprising home directories
for a couple hundred users, some directories shared by samba, and a couple
GB of apache web. Is 50% expansion really "normal"?
There were no hard links to data that got restored into the filesystem by
accident.
Thanks for the help everyone - anything else you can suggest to try and
resolve this issue is greatly appreciated.
Kevin
ORIGINAL QUESTION
HP Admins,
Spent a looooong Sunday working on an L2000 (latest patches, replace Fibre
Channel card, new F/C driver, etc). It was a combination effort to resolve
I/O problems to the external array along with adding an additional 80GB LUN
to the array. Hardware and software all went pretty well. To test the I/O,
we copied around 40GB of data onto the new LUN. I/O problem seems to be
solved, but a quick "bdf" has me mystified:
SOURCE
Filesystem kbytes used avail %used Mounted on
/dev/vgfc4/lvol2 50700288 41774288 8856616 83% /fcc2
TARGET
Filesystem kbytes used avail %used Mounted on
/dev/vgfc6/lvol1 89579520 60481168 28871072 68% /fcc3
Why does "bdf" show that the copied data occupies nearly 60GB of disk, when
the source was only using 40GB??? I thought something might be wrong with
the cpio command I used to copy the data, so I blew it away and restored
from tape backup - SAME RESULT.
OK, maybe I'm brain-dead after my 20 hour day - can someone please point me
to the cause/solution....?
Respectfully,
Kevin M Davisson
Information Technology Dept.
Woodward Aircraft Engine Systems
PH# 815-639-6272
> :-)
>
>
***
The information in this e-mail is confidential and intended solely for the
individual or entity to whom it is addressed. If you have received this
e-mail in error please notify the sender by return e-mail, delete this
e-mail, and refrain from any disclosure or action based on the information.
****
--
---> Please post QUESTIONS and SUMMARIES only!! <---
To subscribe/unsubscribe to this list, contact majordomo@dutchworks.nl
Name: hpux-admin@dutchworks.nl Owner: owner-hpux-admin@dutchworks.nl
Archives: ftp.dutchworks.nl:/pub/digests/hpux-admin (FTP, browse only)
http://www.dutchworks.nl/htbin/hpsysadmin (Web, browse & search)
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 11:02:20 EDT