charlie derr <[EMAIL PROTECTED]> writes:
>
> Thanks Kent, Liam and Martin for the quick responses. I wasn't
> entirely clear on the situation -- the machine didn't always show this
> discrepency, so I don't think it's due to the "system overhead" sort
> of thing.
Charlie,
Martin's got it right. By default, 5% of the disk is reserved for use
by processes running as "root", probably including your "rsync"
scripts. The fourth column of the "df" output, on the other hand,
reports the free space available to regular users.
This reserved space business is documented in the "mke2fs" manpage
(see the "-m" option), and the size of the reserved portion can be
changed on an existing filesystem with "tune2fs" and specified either
as a percentage ("-m") or a raw number of blocks ("-r").
In particular, you can use "tune2fs" to set it to zero, and the
columns of "df" output will be consistent, but you probably shouldn't.
In addition to providing a little bit of slack space for processes
running as root to continue functioning when the disk fills up,
keeping some small percentage of the disk free helps reduce the
severity of fragmentation that would otherwise occur if the disk was
to fill up completely (and that could then remain even when space was
subsequently freed).
Reducing it to 1% should be fine, though.
> I am absolutely certain that in the past I've seen output similar to
> the following:
>
> /dev/sda1 440G 431G 9G 98%
I don't think you would have seen this on an ext2 or ext3 filesystem,
unless you explicitly created one with no reserved space. The default
has been 5% as long as I can remember.
> and over time, this "degrades" to the present situation -- it does
> appear to me that the 2nd and 3rd columns are definitive (and that the
> 4th column is in error) because the rsync scripts that ran last night
> all seemed to succeed in writing to this partition despite the fact
> that column 4 was reporting 0 as the available disk space.
Again, writes as a normal user probably would have failed, but an
"rsync" running as "root" would have continued writing to the reserved
space.
--
Kevin Buhr <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
