httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: [PATCH] Proxy Garbage Collection fixes
Date Thu, 28 May 1998 16:58:46 GMT
Oh duh, I should have just read your patch first, you did all this
research already :)

Dean

On Thu, 28 May 1998, Dean Gaudet wrote:

> 
> 
> On Thu, 28 May 1998, Martin Kraemer wrote:
> 
> > Furthermore, it contains the following fixes:
> > *   "real world" operating systems usually allocate files on block
> >     granularity of 512 bytes or bigger. The old algorithm did not
> >     account for that, and would think 1023 files with 1 byte each would
> >     take up less than 1 kB ;-)
> >     The block size is currently initialized to 512 bytes, but should
> >     probably be configurable. But with this fix, mod_proxy's idea of
> >     disk usage is only "10% off" the OS's idea (it used to be >25% off).
> 
> On solaris, struct stat contains:
> 
>           long     st_blksize;  /* Preferred I/O block size */
>           blkcnt_t st_blocks;   /* Number of 512 byte blocks allocated*/
> 
>      st_blksize
>                A  hint  as  to  the  "best"  unit  size  for  I/O
>                operations.   This  field is not defined for block
>                special or character special files.
> 
>      st_blocks The total number of physical blocks  of  size  512
>                bytes  actually  allocated on disk.  This field is
>                not defined for block special or character special
>                files.
> 
> i.e. you could use st_blocks.
> 
> On linux, struct stat contains:
> 
>                   unsigned long st_blksize;  /* blocksize for filesystem I/O */
>                   unsigned long st_blocks;   /* number of blocks allocated */
> 
> And there's this humourous note:
> 
>        Note that st_blocks may not always be in terms of blocks of size
>        st_blksize, and that st_blksize may instead provide a notion  of
>        the  "pre- ferred" blocksize for efficient file system I/O.
> 
> i.e. they're useless as documented... looking in the kernel they actually
> have the same meaning as on solaris.
> 
> But if you read the code in gnu fileutils/src/system.h, search for
> st_blocks, you'll see it is a hopeless mess of incompatibility.
> 
> Note: st_blocks, when it's useful, appears to also contain the number
> of indirect blocks in the inode.  I forget when a file needs them,
> is it 48k and above?
> 
> Dean
> 

Mime
View raw message