Re: filesystem full error with inumber
- From: "Julian H. Stacey" <jhs@xxxxxxxxxxxxxxxx>
- Date: Thu, 27 Jul 2006 01:45:16 +0200
Sven Willenberger wrote:
Feargal Reilly presumably uttered the following on 07/24/06 11:48:
On Mon, 24 Jul 2006 17:14:27 +0200 (CEST)
Oliver Fromme <olli@xxxxxxxxxxxxxxxxx> wrote:
Nobody else has answered so far, so I try to give it a shot ...
The "filesystem full" error can happen in three cases:
1. The file system is running out of data space.
2. The file system is running out of inodes.
3. The file system is running out of non-fragmented blocks.
The third case can only happen on extremely fragmented
file systems which happens very rarely, but maybe it's
a possible cause of your problem.
I rebooted that server, and df then reported that disk at 108%,
so it appears that df was reporting incorrect figures prior to
the reboot. Having cleaned up, it appears by my best
calculations to be showing correct figures now.
> kern.maxfiles: 20000
> kern.openfiles: 3582
Those have nothing to do with "filesystem full".
Yeah, that's what I figured.
> Looking again at dumpfs, it appears to say that this is
> formatted with a block size of 8K, and a fragment size of
> 2K, but tuning(7) says: [...]
> Reading this makes me think that when this server was
> installed, the block size was dropped from the 16K default
> to 8K for performance reasons, but the fragment size was
> not modified accordingly.
>
> Would this be the root of my problem?
I think a bsize/fsize ratio of 4/1 _should_ work, but it's
not widely used, so there might be bugs hidden somewhere.
Such as df not reporting the actual data usage, which is now my
best working theory. I don't know what df bases it's figures on,
perhaps it either slowly got out of sync, or more likely, got
things wrong once the disk filled up.
I'll monitor it to see if this happens again, but hopefully
won't keep that configuration around for too much longer anyway.
Thanks,
-fr.
One of my machines that I recently upgraded to 6.1 (6.1-RELEASE-p3) is also
exhibiting df reporting wrong data usage numbers. Notice the negative "Used" numbers
below:
Negative isnt an example of programming error, just that the system
is now using the last bit only root can use.
for insight try for example
man tunefs
reboot
boot -s
tunefs -m 2 /dev/da0s1e
then decide what level of m you want default is 8 to 10 I recall.
df -hFilesystem Size Used Avail Capacity Mounted on
/dev/da0s1a 496M 63M 393M 14% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/da0s1e 989M -132M 1.0G -14% /tmp
/dev/da0s1f 15G 478M 14G 3% /usr
/dev/da0s1d 15G -1.0G 14G -8% /var
/dev/md0 496M 228K 456M 0% /var/spool/MIMEDefang
devfs 1.0K 1.0K 0B 100% /var/named/dev
Sven
--
Julian Stacey. Consultant Unix Net & Sys. Eng., Munich. http://berklix.com
Mail in Ascii, HTML=spam. Ihr Rauch = mein allergischer Kopfschmerz.
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: filesystem full error with inumber
- From: Paul Allen
- Re: filesystem full error with inumber
- References:
- Re: filesystem full error with inumber
- From: Sven Willenberger
- Re: filesystem full error with inumber
- Prev by Date: Re: Monitoring temperature with acpi (sysctls)
- Next by Date: Re: filesystem full error with inumber
- Previous by thread: Re: filesystem full error with inumber
- Next by thread: Re: filesystem full error with inumber
- Index(es):
Relevant Pages
|
|