bug-coreutils
[Top][All Lists]
Advanced

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

Re: Bug#294206: stat(1) unclear about block size


From: Jeroen van Wolffelaar
Subject: Re: Bug#294206: stat(1) unclear about block size
Date: Tue, 8 Feb 2005 16:54:09 +0100
User-agent: Mutt/1.3.28i

On Tue, Feb 08, 2005 at 03:39:05PM +0000, James Youngman wrote:
> On Tue, Feb 08, 2005 at 02:42:09PM +0100, Jeroen van Wolffelaar wrote:
> > Package: coreutils
> > Version: 5.2.1-2
> > 
> >   %s   Optimal transfer block size
> > $
> > 
> > 'Optimal transfer block size', I have the suspection that %s IS the
> > blocksize of the filesystem, which should be used in a number of other
> > parameters in order to translate number of blocks into number of bytes.
> > 
> > Is that correct?
> 
> No.    The POSIX standard (in a non-normative section) says :-
> 
> | The unit for the st_blocks member of the stat structure is not defined
> | within IEEE Std 1003.1-2001. In some implementations it is 512
> | bytes. It may differ on a file system basis. There is no correlation
> | between values of the st_blocks and st_blksize, and the f_bsize (from
> | <sys/statvfs.h>) structure members.
> | 
> | Traditionally, some implementations defined the multiplier for
> | st_blocks in <sys/param.h> as the symbol DEV_BSIZE.
> 
> I think almost all systems use 512 byte units.

Ah. On all (GNU/Debian) systems I tried so far though, %s gave 4096, and
I needed to multiply free and available block counts (%a and %f) with
4096 to get the actual amount of free diskspace. The two UNIX systems I
tried so far neither had GNU stat installed, unfortunately.

What I'm interested in to know, is what stat member gives the correct
amount of bytes for a block with which I can multiply %f/%a to obtain
the amount of free diskspace in bytes, or if that's impossible, some
mention of that in a manpage, so that people after me who are going to
look for it, will find out easier than I'm doing now. Since the 'df'
utility does seem to be able to determine the amount of free diskspace,
somehow this would seem to be possible.

Thank you for your response,
--Jeroen

-- 
Jeroen van Wolffelaar
address@hidden (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl




reply via email to

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