On Thu, Jun 08, 2006 at 10:53:06PM -0500, Spencer Shepler wrote:
>
> On Thu, Eric Schrock wrote:
> > The problem is that statvfs() only returns two values (total blocks and
> > free blocks) from which we have to calculate three values: size, free,
>
> ?
>
> >From statvfs(2) the following are returned in struct statvfs:
>
> fsblkcnt_t f_blocks; /* total # of blocks on file system
> in units of f_frsize */
> fsblkcnt_t f_bfree; /* total # of free blocks */
> fsblkcnt_t f_bavail; /* # of free blocks avail to
>
> So, the data is being passed back. Is there something I am missing?
Yes, because these values aren't as straightforward as they seem. For
example, consider the return values from UFS:
$ truss -t statvfs -v statvfs df -h /
statvfs64("/", 0x080479BC) = 0
bsize=8192 frsize=1024 blocks=8068757 bfree=2258725
bavail=2178038 files=972608 ffree=809612 favail=809612
fsid=0x1980000 basetype=ufs namemax=255
flag=ST_NOTRUNC
fstr=""
Filesystem size used avail capacity Mounted on
/dev/dsk/c1d0s0 7.7G 5.5G 2.1G 73% /
$
Notice that the values don't correspond to your assumption. In
particular, 'bfree + bavail != blocks'. The two values for 'bfree' and
'bavail' are used for filesystems that have a notion of 'reserved'
blocks, i.e. metadata blocks which are used by the filesystem but not
available to the user in the form of free space. That's why you have
two values, and if you look at the source code for df(1), you'll see
that it never uses 'bfree' (except in rare internal calculations)
because it's basically useless.
> So, from the comments, that bit of df code seems to be adjusting
> for quotas if they exist? I am not sure I understand why
> zfs' VFS_STATVFS() function can't do what the df command is doing
> and then return the appropriate value to both df and the NFS server?
>
> So, in Robert's case, is that 17GB really available and if so that
> would seem to be an important thing to report to the NFS clients.
Because as mentioned above, 'free' and 'avail' are really variations on
the same theme. And ZFS _must_ report them as the same value (because
metadata is accounted in the same way as data), so we're constrained by
the POSIX interface.
- Eric
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
