[HPADM] SUMMARY - Copied data larger than source?

From: Kevin Davisson (kdavis@woodward.com)
Date: Tue Sep 24 2002 - 09:47:44 EDT


Thanks for all the helpful suggestions. Unfortunately, I have no "smoking
gun" yet.
Most folks wanted to blame cpio and/or links for including extra files, but
extensive
and exhaustive comparison of the file listings in the two directories show
that not only
do the two filesystems have the same files - comparisons of the long
listings shows up
only insignificant size differences caused by the source filesystem being up
"live".

I have also looked at the output of vgdisplay, lvdisplay, fstyp, vxtunefs,
fcmsutil,
df -g, sam, glance, etc. till I'm blue in the face - no significant
differences
between the filesystems (especially no blocksize difference)

It is possible that BOTH cpio and the restore from backup performed the same
type of
sparse file expansion. I will attempt to circumvent this by following Scott
Riley's
suggestion to use a dd to recopy the filesystem, then extendfs:

dd if=/dev/vg??/rlvol?? of=/dev/vg??/rlvol?? bs=256k
mount target filesystem
bdf
df -g on both filesystems
fstyp on both filesystems
umount target filesystem
extendfs /dev/vg??/lvol??

If I come up with a more definitive answer, I'll update the SUMMARY.
============================================================================
=====
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