Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!pacbell.com!att!cbnews!ask From: ask@cbnews.att.com (Arthur S. Kamlet) Newsgroups: comp.unix.questions Subject: Re: du vs. df Message-ID: <1990Nov28.194540.10128@cbnews.att.com> Date: 28 Nov 90 19:45:40 GMT References: <1990Nov18.154826.28813@mccc.uucp> <143@raysnec.UUCP> Reply-To: ask@cblph.att.com Distribution: na Organization: AT&T Bell Laboratories, Columbus, Ohio Lines: 29 In article <143@raysnec.UUCP>, shwake@raysnec.UUCP (Ray Shwake) writes: > pjh@mccc.uucp (Pete Holsberg) writes: > > >From TFM, it appears to me that "df " and "du -s > >" should give complementary reports, the first giving the > >number of 512 byte blocks remaining in and the latter, the > >number used. On a 3B2/400 running SVR3.1.2, they don't. "du -s /usr2" > >reports 1049 blocks used. "df -t /usr2" reports 108424 free, 117404 > >total, or 8980 blocks used. The only files that exist in /usr2 are > >directory files. > > While complementary in some respects, du and df will not provide > complementary results since they source their information in > different fashion. (Note: what follows is based on the System III > and System V boxes with which I'm familiar.) > > 'df' pulls its information from the superblocks. "df -t" shows > the total block size of the file system, *including* space allocated > to the boot block, superblock, etc. which, by definition are not > available (not free) for user use. > > 'du', on the other hand, looks at the space consumed by the files > and directories themselves. Some implementations will double-count > the space consumed by linked files, others will not. Also, du silently fails to report about unreadable directories. -- Art Kamlet a_s_kamlet@att.com AT&T Bell Laboratories, Columbus