How to safely copy full filesystems with large files (10Gb files)

Hello everyone. Need some help copying a filesystem. The situation is this: I have an oracle DB mounted on /u01 and need to copy it to /u02. /u01 is 500 Gb and /u02 is 300 Gb. The size used on /u01 is 187 Gb. This is running on solaris 9 and both filesystems are UFS.

I have tried to do it using:

# cd /u01
# find . -depth -print | cpio -pdumv /u02

But when the command finishes I end up with 207 Gb copied on /u02!!!!, my question is... why :eek:!!!???, where did the extra 20 Gb come from???

Any ideas on why this happens and how I can safely copy from /u01 to /u02?, I have to be sure since this is a production DB.

PD: The /u01 has files that are 10 Gb large... could this be the problem?, can cpio handle large files? (I thought it could!, I've used it before to copy 2GB files without problems...)

Thanks in advance!

What was the original size of /u02 ?

Are there any symbolic links in /u01 to other file systems?

Any sparse files may also change size when copied(blocks not stored in the input become stored blocks full of zeroes in the output), though the content remains identical.

Hi Neo.

The /u02 is a new volume and filesystem, it had nothing on it... empty.

There are some sym links on /u01... but all the sym links go from / to the same filesystem. Example:

lrwxrwxrwx 1 user dba 41 May 21 2009 /u01/ppp.txt -> /u01/prueba/ppplink.txt

Like Corona says, I there might be sparse files, perhaps temporary table space?. In that case dropping your temporary table space on the target file system and recreating it may turn it back into a sparse file...

It may be Corona688, but... I can not lose 20 Gb just because... I'm sure there has to be other way to do it without that disk space...

When sparse files are copied by programs that do not take sparse files into account they get turned into dense files on the target file system and take up much more disk space...

Copying sparse files is frequently a problem. The ability to replicate sparse files holes-and-all is often not merely system-specific but filesystem-specific too. I wrote a sparsecat utility which turns space full of NULLs into sparse holes but it does it brute force -- it doesn't know where the holes originally were, it just checks for sectors full of zeroes. It's not guaranteed in any sense either.

FWIW, on Linux systems (not sure about Solaris, sorry), you can detect sparse files by comparing the output of these two commands:

du -s -B1 --apparent-size sparse-file

and:

du -s -B1 sparse-file
1 Like

For twenty gigs worth of space, the difference should be apparent enough between du -h and ls -lh.

Instead of using cpio which isn't sparse file aware, use ufsdump/ufsrestore to backup your directories. Make also sure you backup stable data by either locking the filesystem (lockfs) or creating a snapshot of it (fssnap).

1 Like

But... is the "df" command able to detect sparse files???, it should detect them, should it?. I am kind of confused here... if I create a 5Gb sparse file on a filesystem, lets say /u01, then

du -sh sparse-file

should say that the file is 5Gb... then if I copy the same file to another filesystem, /u02, and do the

du -sh sparse-file

, the result should be the same. Now, lets say in both filesystems: /u01 and /u02 I have only this file, the df -h command will report the same as du...

What I mean is, it doesn't matter that a sparse file is 10 Gb big and only 1 Gb of it is filled with usefull data, the df or ls -lh or du -sh commands have to return that the file is 10 Gb big.... right?!?!

A 5GB sparse file may take up only 500MB for instance. If you copy the file with a program that does not take sparse files into account, its copy will take up 5GB on the target file system.

1 Like

I found the infamous 20 Gb sparse file!!! :-), you were right guys!, now I'll follow jlliagre's advice on using ufsdump/ufsrestore to do this job... I'll try:

ufsdump 0f - /dev/rdsk/c0t0d0s0 | (cd /u02; ufsrestore xf -)

and see how it goes...

Thank you to everyone for your time and help!!!

PS: I used

ls -lh filename

to see the file size (it showed 20 Gb) and

du -h filename

to see the real/actual size it is consuming (it showed 96 Kb).

du reports disk used, not file size. Never quite the same thing at the best of times(i.e. 1K file in a filesystem with 4K clusters takes a minimum of 4K space), and the difference could be enormous for a sparse file, since arbitrary parts of the file aren't on disk at all.

Glad you got it solved. :slight_smile:

1 Like