Sun Microsystems, Inc.  Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-71-2385311.1
Update Date:2018-04-13
Keywords:

Solution Type  Technical Instruction Sure

Solution  2385311.1 :   Oracle ZFS Storage Appliance: Windows Client Reports Larger Usage Size Than Actual Size of SMB Share  


Related Items
  • Sun ZFS Storage 7420
  •  
  • Oracle ZFS Storage ZS5-2
  •  
  • Oracle ZFS Storage ZS3-2
  •  
  • Oracle ZFS Storage Appliance Racked System ZS5-4
  •  
  • Oracle ZFS Storage ZS4-4
  •  
  • Oracle ZFS Storage ZS5-4
  •  
  • Sun ZFS Storage 7120
  •  
  • Oracle ZFS Storage ZS3-4
  •  
  • Oracle ZFS Storage Appliance Racked System ZS5-2
  •  
  • Sun ZFS Storage 7320
  •  
  • Oracle ZFS Storage Appliance Racked System ZS4-4
  •  
  • Oracle ZFS Storage ZS3-BA
  •  
Related Categories
  • PLA-Support>Sun Systems>DISK>ZFS Storage>SN-DK: ZS
  •  




In this Document
Goal
Solution


Created from <SR 3-17236487851>

Applies to:

Oracle ZFS Storage ZS5-4 - Version All Versions and later
Oracle ZFS Storage ZS5-2 - Version All Versions and later
Oracle ZFS Storage Appliance Racked System ZS5-4 - Version All Versions and later
Oracle ZFS Storage Appliance Racked System ZS5-2 - Version All Versions and later
Oracle ZFS Storage ZS4-4 - Version All Versions and later
7000 Appliance OS (Fishworks)

Goal

The purpose of this document is to explain the discrepancy of usage size from a Windows client and the ZFSSA SMB Share, when compression is on.

 

Solution

\\hostname\share, mounted as D: contains three directories:

dir1 which Windows properties for the directory report as 4.96T.
dir2 which Windows properties for the directory report as 8.99T.
dir3 which Windows properties for the directory report as 8.57T.
Which add to 22.52T.

 

Output taken from Support Bundle.

$ egrep 'share|Filesystem' status/df.out
Filesystem Size Used Available Capacity Mounted on
pool/local/project/share 8.5T 6.6T 905G 89% /export/project/share

$ grep share shares/definedshares.out
pool_local_project_share /export/project/share nfs sec=sys,rw
share /export/project/share smb abe=false,dfsroot=false

$ egrep -i 'share|mount' zfs/list.out
NAME USED AVAIL REFER MOUNTPOINT
pool/local/project/share 7.62T 905G 6.57T /export/project/share

$ ggrep -e "share .* avail" -e "share .* used" -e "share .*quota" -e "share .*referenced" -e "share .*compression" -e "share .*compressratio" pool.datasets.prop | tr -s " " | egrep -v "none| 0 "
pool/local/project/share available 905G -
pool/local/project/share compression lzjb local
pool/local/project/share compressratio 3.23x -
pool/local/project/share quota 8.50T local
pool/local/project/share referenced 6.57T -
pool/local/project/share used 7.62T -
pool/local/project/share usedbydataset 6.57T -
pool/local/project/share usedbysnapshots 1.04T -

As we can see, the share is only 8.5T due to the quota.

The reason 22.52T is seen on the Windows client is because it does not know about the compression that takes place on the ZFSSA.

 

If we do the math, we can see that the numbers are relatively the same as what is seen on the Windows client.

quota 8.5 TB x 3.23 (compressratio) = 27.45 TB
used 7.62 TB x 3.23 = 24.61 TB (used includes snapshot data)
usedbydataset 6.57 TB x 3.23 = 21.23 TB (without snapshot data)

If we were to break this down to bytes, instead of terrabytes, and then times by the compressratio (3.23), we would end up with numbers that closer match what the Windows client sees.

 


Attachments
This solution has no attachment
  Copyright © 2018 Oracle, Inc.  All rights reserved.
 Feedback