lkml.org 
[lkml]   [1996]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 5% reserved discrepancy (minor nitpick)
Hi,

On Tue, 6 Aug 1996 15:39:02 -0700 (PDT), Robert Woodcock
<rcw@netcom.com> said:

> I made my fs with the mke2fs from Slackware 3 (0.5a), and I'm currently
> running on kernel 2.0.0. I have not used tune2fs since then, so I still have
> the default 5% set for root. A friend on #linux noticed that df wasn't quite
> adding up (he's running on Redhat 3.0.3, exact same problem, then again,
> same mke2fs version :)

> mercury:~$ df /
> Filesystem 1024-blocks Used Available Capacity Mounted on
> /dev/hda5 659003 527991 95835 85% /
> mercury:~$ /sbin/fdisk -l
> [snip]
> Device Boot Begin Start End Blocks Id System
> [snip]
> /dev/hda5 261 261 609 703552+ 83 Linux native
> [...]

> 527991+95835=623826
> 659003-623826=35177 /* tune2fs also gives this number */
> 35177*20=703540 /* 1/20 = 5% */
> ^^^^^^
> Shouldn't that turn out to 659000? Or is this the desired behavior?

It's all working fine. The reserved space --- 35177 blocks, in this
case --- is exactly 1/20 of the entire filesystem, 703552 blocks.
There are 659003 available blocks on the filesystem, of which 35177
are reserved only for root leaving 623826 available for normal users.

The "problem" is that tune2fs and mke2fs are calculating the reserved
space as a fraction of the partition size, not as a fraction of the
data blocks on the filesystem. Inode tables, bitmaps and filesystem
descriptors all incur some overhead on the filesystem so the number of
data blocks available will always be a bit less than the number of
blocks on the partition, and you could argue that the reserved space
should be calculated against the number of data blocks, not the size
of the partition.

Cheers,
Stephen.
--
Stephen Tweedie <sct@dcs.ed.ac.uk>
Department of Computer Science, Edinburgh University, Scotland.


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.023 / U:3.576 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site