Solaris

Dears,

I have one strange problem. When I copy file from source to destination using scp, file size decreased in destination side. I can see that copy progress is successful in source side. But when I check file size using

Code:

du -sh

command file size is 10 time smaller.
First I looked into network. But there wasn't any network interrupt. So I changed destination directory to /tmp in scp copy command. After that I checked file size on destination side and it was correct size. Then I copied file from /tmp to /backup on destination side and checked file size. File size was 0k very strange.

I think there's some disk issues in the server. Also checked zfs filesystem using

Code:

zfs list
zpool list
zpool status -x  commands.

They are all fine. Have you seen this issue ever?

How did you determine that the size of the copy was zero?

On a ZFS filesystem, copying file1 to file2 might share disk block allocations between the two files until some bytes in one of the files is overwritten. In that case a du -s file1 file2 might show 0 blocks allocated to file2 while du -s file2 file1 might show 0 blocks allocated to file1, and du -s file1 followed by du -s file2 (in separate invocations of du) would show the same (non-0) size for both files.

I used du -sh command to determine the size of the copy. I just found that file size in destination directory is increasing. It was 0K about 30 min ago and now it's 7.2M. So that means I need to check disk read write performance, right?

---------- Post updated at 02:41 PM ---------- Previous update was at 11:45 AM ----------

I found that this issue appeared on only disk from SunStorage M2500M2 array.

Did you read what I said in post #2 in this thread?

You haven't told us anything that would allow us to guess what, if anything, is wrong:

Hi Don Cragun,

Yeah, read your post, sorry for not enough details. Here are some details.
1. Source file size is 10mb. Actually there are many files with the size greater than 10GB. But I chose 10mb sized one file as test.
2. I'm using cp and scp both.
scp -C source_file oracle@remote_host:/path/to/dir
cp source_file /path/to/destination
3. I used du -sh command to see file size. ls -l command shows the size same as source file. But du -sh command shows different size. I think that ls -l command is showing only file size info in the header and du -sh command is showing size on the disk.
4. Yes, source and destination filesystem are same. I'm using Solaris ZFS filesystem
5. Yes, command completed without error.
6. du -sh and ls -ltr results are different. Please see 3th answer.
7. Already checked if there's any log. But I didn't see any log.
8. Solaris 10 runs on both source and dest server.
9. If I copy files from source server to local disk of the remote server it copies file without issue. All file sizes are correct.
If I copy file from source server to sunstorage disk of the remote server, copied file size is decreased. That means this issue is related to SunStorage.

---------- Post updated at 01:51 PM ---------- Previous update was at 11:27 AM ----------

I'm checking storage and will share the result here.

Check if your zfs filesystem in question is using compression and/or deduplication.
That can cause confusion with du, if you are not aware that it is turned on.

GNU du has --apparent-size which can be usefull on zfs filesystems and is present as gdu on Solaris 11 and later.

Also you might want to run md5sum or cksum to check if the files are the same on source and destination.

Hope that helps
Regards
Peasant.

Deduplication is what I was talking about in post #2 in this thread. But comparing the source and destination is going to fail if du is showing that the destination is growing over time after the copy completes.

I asked for the EXACT du command that was being used to look at the size of the destination file and was told that the command used was:

Code:

du -sh

which will not tell you the number of blocks allocated to any particular file; it gives you the number of disk blocks allocated to all files in the file hierarchy rooted in the current working directory that are in the same filesystem as the current working directory.

The fact that ls -l shows the correct file size is a clear indicatory that the copy completed successfully and if:

Code:

du -sh source_file destination_file

is showing destination_file with in initial allocation of 0 blocks after the copy completes and an increasing allocation as time passes, it means that new blocks are being allocated to destination_file as blocks in source_file and/or destination_file are being changed after the copy completed.