On Fri, Eric Schrock wrote:
> 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.
I must have been half asleep when looking at this; thanks for the clue bat.
Spencer
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
