ProLiant DL380 G5, freshly installed FreeBSD 7.0-RELEASE amd64. I have done similar installations on 2 other servers, and suddenly: ~/#df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s1a 1012974 385846 546092 41% / devfs 1 1 0 100% /dev /dev/da0s1e 507630 12 467008 0% /tmp /dev/da0s1f 58730650 1302436 52729762 2% /usr /dev/da0s1d 5077038 -33660 4704536 -1% /var ~/#du -sk /var 3188 /var I have not done anything with neither newfs nor tunefs. ~/#tunefs -p tunefs: ACLs: (-a) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: gjournal: (-J) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L)Fra /var/run/dmesg.boot:>From /var/run/dmesg.boot:da0 at ciss0 bus 0 target 0 lun 0 da0: <COMPAQ RAID 1 VOLUME OK> Fixed Direct Access SCSI-0 device da0: 135.168MB/s transfers da0: 69973MB (143305920 512 byte sectors: 255H 32S/T 17562C) There were no complaints during slicing og installing. Any ideas? --Ingeborg -- Ingeborg ?strem Hellemo -- ingeborg@cc.uit.no (Univ. of Troms?, Norway)
On Tue, Apr 01, 2008 at 02:57:17PM +0200, Ingeborg Hellemo wrote:> ProLiant DL380 G5, freshly installed FreeBSD 7.0-RELEASE amd64. I have done > similar installations on 2 other servers, and suddenly: > > ~/#df > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/da0s1a 1012974 385846 546092 41% / > devfs 1 1 0 100% /dev > /dev/da0s1e 507630 12 467008 0% /tmp > /dev/da0s1f 58730650 1302436 52729762 2% /usr > /dev/da0s1d 5077038 -33660 4704536 -1% /var > > > ~/#du -sk /var > 3188 /var > > I have not done anything with neither newfs nor tunefs. > > ~/#tunefs -p > tunefs: ACLs: (-a) disabled > tunefs: MAC multilabel: (-l) disabled > tunefs: soft updates: (-n) enabled > tunefs: gjournal: (-J) disabled > tunefs: maximum blocks per file in a cylinder group: (-e) 2048 > tunefs: average file size: (-f) 16384 > tunefs: average number of files in a directory: (-s) 64 > tunefs: minimum percentage of free space: (-m) 8% > tunefs: optimization preference: (-o) time > tunefs: volume label: (-L)Fra /var/run/dmesg.boot: > > >From /var/run/dmesg.boot: > > da0 at ciss0 bus 0 target 0 lun 0 > da0: <COMPAQ RAID 1 VOLUME OK> Fixed Direct Access SCSI-0 device > da0: 135.168MB/s transfers > da0: 69973MB (143305920 512 byte sectors: 255H 32S/T 17562C) > > > There were no complaints during slicing og installing. > > > Any ideas?1) Softupdates can cause this. Run "sync" a few times, then wait 30 seconds or so; does it go away? 2) Files which are open (have active file descriptors associated with them) on /var before it filled may be causing this. fstat may help you here. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
koitsu@freebsd.org said:> 1) Softupdates can cause this. Run "sync" a few times, then wait 30 seconds > or so; does it go away?Tried. And booted several times. No luck koitsu@freebsd.org said:> 2) Files which are open (have active file descriptors associated with them) > on /var before it filled may be causing this. fstat may help you here.But /var is not full. It is _more_ than empty. After the system has been running a couple of days (more files in /var/log, /var/db/locate.database, etc.) I now have an almost empty /var: ~#du -sk /var 15378 /var ~#df /var Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s1d 5077038 -21470 4692346 -0% /var I guess I could be happy for this extra diskspace, but I am afraid that something is not quite right... --Ingeborg -- Ingeborg ?strem Hellemo -- ingeborg@cc.uit.no (Univ. of Troms?, Norway)
On Wed, Apr 02, 2008 at 08:03:09AM +0200, Ingeborg Hellemo wrote:> > koitsu@freebsd.org said: > > 1) Softupdates can cause this. Run "sync" a few times, then wait 30 seconds > > or so; does it go away? > > Tried. And booted several times. No luck > > > koitsu@freebsd.org said: > > 2) Files which are open (have active file descriptors associated with them) > > on /var before it filled may be causing this. fstat may help you here. > > But /var is not full. It is _more_ than empty.It is possible to have files that are open and held by processes on the filesystem that are no longer listed. If you kill the offending process the space will be freed up. -- Jonathan Chen <jonc@chen.org.nz> ---------------------------------------------------------------------- "You can get farther with a kind word and a gun than you can with a kind word alone" - Al Capone
eugen@kuzbass.ru said:> > It is possible to have files that are open and held by processes on > > the filesystem that are no longer listed. If you kill the offendingL > process the space will be freed up.> > "lsof +aL1 <file_system>" shows unlinked open files on the specified file > system (quoting its man page).If you read my first mail you will see that this is not a case of overfull /var (101% used) and a need to free space. Something is wrong with either the filesystem or df(1) since it claims that I am using a negative amount of disk-blocks. There are no unlinked open files on /var, and I fail to understand how they could have explained the output of df(1) --Ingeborg -- Ingeborg ?strem Hellemo -- ingeborg@cc.uit.no (Univ. of Troms?, Norway)
On Wed, Apr 02, 2008 at 07:41:16PM +1300, Jonathan Chen wrote:> > > 2) Files which are open (have active file descriptors associated with them) > > > on /var before it filled may be causing this. fstat may help you here. > > But /var is not full. It is _more_ than empty. > > It is possible to have files that are open and held by processes on > the filesystem that are no longer listed. If you kill the offending > process the space will be freed up."lsof +aL1 <file_system>" shows unlinked open files on the specified file system (quoting its man page). Eugene Grosbein