bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19530: Solaris 10 df and zfs


From: Pádraig Brady
Subject: bug#19530: Solaris 10 df and zfs
Date: Thu, 08 Jan 2015 01:18:38 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

On 07/01/15 22:13, Ted Carr wrote:
> Pádraig,
> 
> Here is what I get:
> 
> # ./stat -f /      
>   File: "/"
>     ID: 4010002  Namelen: 255     Type: zfs
> Block size: 131072     Fundamental block size: 512
> Blocks: Total: 106248371  Free: 83645114   Available: 83645114
> Inodes: Total: 83922472   Free: 83645114

Cool, we're getting 51G from the system.

> 
> That said ... Check this out:
> 
> Before the patch it was reporting this for root:
> 
> Filesystem                                                     Size  Used 
> Avail Use% Mounted on
> /platform/sun4u-us3/lib/sparcv9/libc_psr/libc_psr_hwcap1.so.1   51G   11G   
> 40G  22% /platform/sun4u-us3/lib/sparcv9/libc_psr.so.1
> 
> Which is what I see in the output from SUN df in these two lines (size 
> matches):
> 
> /platform/sun4u-us3/lib/libc_psr/libc_psr_hwcap1.so.1
>                         51G    11G    40G    22%    
> /platform/sun4u-us3/lib/libc_psr.so.1
> /platform/sun4u-us3/lib/sparcv9/libc_psr/libc_psr_hwcap1.so.1
>                         51G    11G    40G    22%    
> /platform/sun4u-us3/lib/sparcv9/libc_psr.so.1

40 + 11 = 51

> Running a SUN df on one of the above "FS" gives this:
> 
> # df -h /platform/sun4u-us3/lib/libc_psr.so.1
> Filesystem             size   used  avail capacity  Mounted on
> rpool/ROOT/q414         67G    11G    40G    22%    /
> 
> # zpool list rpool
> NAME   SIZE  ALLOC   FREE  CAP  HEALTH  ALTROOT
> rpool   68G  26.8G  41.2G  39%  ONLINE  -
> 
> Not sure if that helps or not...
> 
> I did find this: 
> http://www.c0t0d0s0.org/archives/6168-df-considered-problematic.html.  About 
> half way down the page you will see "Digging in the source" which may help, 
> or not. ;-)

So Solaris df seems to do further munging of the sizes to
handle deduplication and what not, resulting in a virtual total.
I.E. total != used + avail.
I'm not sure why such details need to be exposed to the user TBH.

We'll keep special handling of file systems like these
under consideration for future releases.

thanks,
Pádraig






reply via email to

[Prev in Thread] Current Thread [Next in Thread]