Date: Sat, 15 Nov 1997 11:05:55 -0600 (CST) From: Dave Bodenstab <imdave@mcs.net> To: dwhite@resnet.uoregon.edu Cc: caj@praline.no.neosoft.com, freebsd-questions@FreeBSD.ORG Subject: Re: full file system: df and du disagree - why? Message-ID: <199711151705.LAA02456@imdave.pr.mcs.net>
next in thread | raw e-mail | index | archive | help
> From: Doug White <dwhite@gdi.uoregon.edu> > On Fri, 14 Nov 1997, Charles Owens wrote: > > > > > A 'du -ks /var' showed that only 11 out of 60 megs were in use, so I > > > > _knew_ that there was plenty of free space. But, df didn't think so, and > > > > the kernel apparantly didn't think so either, as writes to /var still > > > > produced a filesystem full error. > > > > > > Some process has a file that has been rm'ed open, likely. The file is not > > > actually deleted until the last process that has it open closes it. Du will > > > report the space as unused, df will report correctly. > > > > Thanks! Could you define "rm'd open" ? > > Under UNIX, files have a `link count' associated with them. WHen you > create a file on a filesystem, it gets one link to the FS. When a program > opens a file, the link count is incremented. When a program closes a file > or you use the rm(1) command, the link count is reduced by one. When the > link count reaches 0, the index node (inode) is cleared, the disk's block > free list is updated and the file is forgotten. > > The problem you may be seeing is that although you deleted a file, some > program still has the file open. Even though the filesystem's link is > gone, the link count is still >0, so the inode continues to exist, and so > df(1) will count it (since it exists in the used block list) even though > du(1) can't see it since it can't see it's directory entry. > A small correction to the terminology that could be confusing... I'll try to be brief. The term ``link count'' is generally used to refer to the count maintained in the inode of the file system -- it is used to count the number of hard links to a file. A ``ls -l'' shows this count. The file system code in the kernel maintains an in-core copy of the inode for each file that is open. The kernel maintains a ``reference'' count in the ``struct file'' (sys/file.h, f_count) for each successful open(2) system call. The two counts are not related. In order for a file to be deleted, both counts must be zero. When a file is closed, the reference count drops by one. When an unlink(2) -- rm uses unlink -- is done, the link count drops by one. Only when both counts are zero will the file system code actually delete the file by adding the blocks formerly used by the file's data back to the free space blocks on the file system. Doug's statement that ``as long as a file is still open, it will not be deleted'' is correct. But this is because the reference count is not yet zero -- the link count is indeed zero in this case (but you can't see this since there is no way to do a ``ls -l'' on what used to be the file because the directory entry is now gone.) Dave Bodenstab imdave@mcs.net PS. Some of *my* terminology is no doubt dated -- ``vnodes'' now seem to be used throughout the kernel, and I haven't studied kernel sources for so long that I can't say anything about them. I think that the on-disk structure that maintains the link count -- the old system 5 file system inode -- is used to construct the some of the contents of the in-memory vnode -- but the basic idea that there are two counts is correct.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711151705.LAA02456>