Re: filesystem full error with inumber
On Wed, 26 Jul 2006 13:07:19 -0400 Sven Willenberger [EMAIL PROTECTED] wrote: Feargal Reilly presumably uttered the following on 07/24/06 11:48: 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. 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: df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/da0s1a496M 63M393M14%/ devfs 1.0K1.0K 0B 100%/dev /dev/da0s1e989M -132M1.0G -14%/tmp /dev/da0s1f 15G478M 14G 3%/usr /dev/da0s1d 15G -1.0G 14G-8%/var /dev/md0 496M228K456M 0%/var/spool/MIMEDefang devfs 1.0K1.0K 0B 100%/var/named/dev Sven For the record, my problems occured with 5.4-PRERELEASE #1 which, for reasons beyond my control, I had not yet been unable to upgrade. What bsize/fsize ratio are you using? Mine was 4/1 instead of the more usual 8/1. BTW, anybody know what the best method be for double-checking df's figures would be? du? -- Feargal Reilly. PGP Key: 0x847DE4C8 (expires: 2006-11-30) Web: http://www.helgrim.com/ | ICQ: 109837009 | YIM: ectoraige Visit http://ie.bsd.net/ - BSDs presence in Ireland signature.asc Description: PGP signature
Re: filesystem full error with inumber
Sven Willenberger wrote: This was an upgrade from a 5.x system (UFS2); a full fsck did in fact fix the problem (for now). Because of past experience I recommend that you disable background fsck (it has a switch in /etc/rc.conf). There are failure scenarios with background fsck that can lead to symptoms similar to what you have experienced. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. C++ is the only current language making COBOL look good. -- Bertrand Meyer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: filesystem full error with inumber
Feargal Reilly [EMAIL PROTECTED] wrote: BTW, anybody know what the best method be for double-checking df's figures would be? du? No, du(1) only sees files that have links (i.e. directory entries). It doesn't see deleted files that occupy space as long as processes still have them open, which can make quite a difference. You can use the command lsof +L1 to check for such files. If there aren't any on the file system in question, then the number from du(1) should be pretty close to the number from df(1). The df(1) tool just displays the summary records from the file system. The only safe way to verify those numbers is to run fsck(8) manually on the file system (possibly twice). It will fix the summary records if necessary. Then run df(1) again. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. To this day, many C programmers believe that 'strong typing' just means pounding extra hard on the keyboard. -- Peter van der Linden ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: filesystem full error with inumber
Feargal Reilly presumably uttered the following on 07/24/06 11:48: On Mon, 24 Jul 2006 17:14:27 +0200 (CEST) Oliver Fromme [EMAIL PROTECTED] 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: 2 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: df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/da0s1a496M 63M393M14%/ devfs 1.0K1.0K 0B 100%/dev /dev/da0s1e989M -132M1.0G -14%/tmp /dev/da0s1f 15G478M 14G 3%/usr /dev/da0s1d 15G -1.0G 14G-8%/var /dev/md0 496M228K456M 0%/var/spool/MIMEDefang devfs 1.0K1.0K 0B 100%/var/named/dev Sven ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: filesystem full error with inumber
On Wed, 2006-Jul-26 13:07:19 -0400, Sven Willenberger wrote: One of my machines that I recently upgraded to 6.1 (6.1-RELEASE-p3) is also exhibiting df reporting wrong data usage numbers. What did you upgrade from? Is this UFS1 or UFS2? Does a full fsck fix the problem? -- Peter Jeremy pgpzljAGgFapT.pgp Description: PGP signature
Re: filesystem full error with inumber
Peter Jeremy presumably uttered the following on 07/26/06 15:00: On Wed, 2006-Jul-26 13:07:19 -0400, Sven Willenberger wrote: One of my machines that I recently upgraded to 6.1 (6.1-RELEASE-p3) is also exhibiting df reporting wrong data usage numbers. What did you upgrade from? Is this UFS1 or UFS2? Does a full fsck fix the problem? This was an upgrade from a 5.x system (UFS2); a full fsck did in fact fix the problem (for now). Thanks, Sven ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: filesystem full error with inumber
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 [EMAIL PROTECTED] 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: 2 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 -h Filesystem SizeUsed Avail Capacity Mounted on /dev/da0s1a496M 63M393M14%/ devfs 1.0K1.0K 0B 100%/dev /dev/da0s1e989M -132M1.0G -14%/tmp /dev/da0s1f 15G478M 14G 3%/usr /dev/da0s1d 15G -1.0G 14G-8%/var /dev/md0 496M228K456M 0%/var/spool/MIMEDefang devfs 1.0K1.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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: filesystem full error with inumber
From Julian H. Stacey [EMAIL PROTECTED], Thu, Jul 27, 2006 at 01:45:16AM +0200: 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 -h Filesystem SizeUsed Avail Capacity Mounted on /dev/da0s1a496M 63M393M14%/ devfs 1.0K1.0K 0B 100%/dev /dev/da0s1e989M -132M1.0G -14%/tmp /dev/da0s1f 15G478M 14G 3%/usr /dev/da0s1d 15G -1.0G 14G-8%/var /dev/md0 496M228K456M 0%/var/spool/MIMEDefang devfs 1.0K1.0K 0B 100%/var/named/dev Sven Julian: if you looked more closely you would see that the negative numbers appear not in the available category but in the 'USED'. This has nothing to do with root reserve. It may have something to do with background fsck though but it is rather inconsistent. 989 - (-132) == 1G 15G - (-1.0G) != 14G ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: filesystem full error with inumber
On Mon, 24 Jul 2006 17:14:27 +0200 (CEST) Oliver Fromme [EMAIL PROTECTED] 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: 2 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. -- Feargal Reilly. PGP Key: 0x847DE4C8 (expires: 2006-11-30) Web: http://www.helgrim.com/ | ICQ: 109837009 | YIM: ectoraige Visit http://ie.bsd.net/ - BSDs presence in Ireland signature.asc Description: PGP signature
