- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: strange - FS usage differs
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-09-2005 06:35 AM
05-09-2005 06:35 AM
strange - FS usage differs
I am working on copying contents of a dir under a file system to a different file system. I am using rsync here, just to make to same. Below is what I am doing.
rsync -av /ora_dump/CTSPRD2 /ora_dump/NewCTSPRD2
I dont use compression because it's a local copy.
Problem I am finding is strange till now:
ohms# cd /ora_dump/CTSPRD2
ohms# du -sk *
1296 audit
1327 audit.old
712 babu
1629195 bdump
19711 cdump
1 connect_report
0 exports
1 ksmsp_report
166080 monitor
1253699 perf
161078 udump
==========================
ohms# cd ../NewCTSPRD2
ohms# du -sk *
ohms# du -sk *
2420 audit
2506 audit.old
712 babu
4908252 bdump
19710 cdump
0 connect_report
0 exports
0 ksmsp_report
0 lost+found
160624 monitor
1256534 perf
161148 udump
=============================
lvcreate -i 2 -I 64 -L 8192 -n vora_dump_ctsprd2 /dev/vgfs
==
newfs -F vxfs -o largefiles -b 2048 /dev/vgfs/rvora_dump_ctsprd2
====================================
I have tried chaning block factor to 8192/2048 etc. I can see the same usage difference,
ohms# bdf /ora_dump
Filesystem kbytes used avail %used Mounted on
/dev/vgfs/vora_dump
8192000 5445573 2574832 68% /ora_dump
ohms# bdf /ora_dump/NewCTSPRD2
Filesystem kbytes used avail %used Mounted on
/dev/vgfs/vora_dump_ctsprd2
8388608 6533104 1797578 78% /ora_dump/NewCTSPRD2
==============================================
I want to make it happen as ora_dump is common and I have seperate dir/s underneath it.
Anyone faced this or any suggestions..
Thanks and regards
Prashant
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-09-2005 06:42 AM
05-09-2005 06:42 AM
Re: strange - FS usage differs
Are there any files that are in use??
lsof +D /dir1 - source dir.
fuser -cu /FS - source FS
Anil
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-09-2005 07:14 AM
05-09-2005 07:14 AM
Re: strange - FS usage differs
Files are getting copied, but are getting double in size at destination.
if you see bdump size, it's quite big at destination.
I have copied when file system was down also..offcourse tried oevrwriting..didnt make a difference..
Files will be use as CTSPRD2 is live.
Thanks
Prashant
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-09-2005 07:25 AM
05-09-2005 07:25 AM
Re: strange - FS usage differs
Try to eliminate to copy command.
Something like
# find /ora_dump/CTSPRD2 | cpio -pcmudv /ora_dump/NewCTSPRD2
Robert-Jan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-09-2005 07:38 AM
05-09-2005 07:38 AM
Re: strange - FS usage differs
You can see this for yourself by doing this:
mkdir /var/tmp/mydir /var/tmp/mydir2
cd /var/tmp/mydir
dd if=/dev/zero bs=1k oseek=1000000 count=1 of=x
cp x ../mydir2/
du -k /var/tmp/mydir
du -k /var/tmp/mydir2
Surprisingly, an ls -l of both files will show a 1MB (+1k) file size but the du will report very different results because the two commands are looking at very different things.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-09-2005 08:43 AM
05-09-2005 08:43 AM
Re: strange - FS usage differs
It is also possible for the copied files and direrctories to be smaller. In this case, it is due to 'sparse directories'. When you create a directory (mkdir), it will be 2 blocks in size. Create thousdands of new files in the directory and the size of the directory (ll -d /some_directory) might be 512 blocks. Now purge all the files. The directory is still 512 blocks but contains nothing but 'empty' or reusable records. Directories are not truncated when files are removed, but if you copy the directory, it is created as 2 blocks and then enlarged when necessary.
The only thing you can rely on is the quantity of directories and files. Use find and wc to count for you.
Bill Hassell, sysadmin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-09-2005 08:53 AM
05-09-2005 08:53 AM
Re: strange - FS usage differs
Thanks
Prashant
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-09-2005 01:22 PM
05-09-2005 01:22 PM
Re: strange - FS usage differs
If size still does not match, there may be some sparse files, so you may want to run rsync with -S option.
-S, --sparse handle sparse files efficiently