On Fri, Jan 21, 2005 at 03:11:06PM +0100, Wichert Akkerman wrote:
> After cleaning up a bit df suddenly showed interesting results:
>
> Filesystem Size Used Avail Use% Mounted on
> /dev/md4 1019M -64Z 1.1G 101% /tmp
>
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/md4 1043168 -73786976294838127736 1068904 101% /tmp
>
> This is on a ext3 filesystem on a 2.6.10-ac10 kernel.
Funny.
The Used column is total-free, so free was 2^66 + 964440.
That 2^66 no doubt was 2^64 in a computation counting 4K-blocks,
and arose at some point where a negative number was considered unsigned.
But having available=1068904 larger than free=964440 is strange.
I assume this was produced by statfs or statfs64 or so.
You can check using "strace -e statfs64 df /dev/md4" that
these really are the values returned by the kernel,
so that we can partition the blame between df and the kernel.
The values are computed by
buf->f_blocks = es->s_blocks_count - overhead;
buf->f_bfree = ext3_count_free_blocks (sb);
buf->f_bavail = buf->f_bfree - es->s_r_blocks_count;
that is: blocks = total - overhead, and available = free - reserved.
strace shows three values, and I expect tune2fs or so will show 2 more.
More available than free sounds like a negative count of reserved blocks.
Are you still able to examine the situation?
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
