At the request of a number of list members, I'm forwarding the message Dr.
Blinn originally sent to me regarding the way the "df" command works, and
how it is of questionable value when dealing with advfs systems. Enjoy!
Pearce Statts
GE Fanuc Automation IT
-----Original Message-----
From: Dr. Thomas.Blinn_at_Compaq.com [mailto:tpb_at_doctor.zk3.dec.com]
Sent: Thursday, March 28, 2002 11:45 AM
To: Statts, Pearce (IndSys, GEFanuc, NA)
Subject: Re: Missing filespace on advfs domain?
"df" gets the information it reports out of a table maintained by the
kernel.
Within an AdvFS domain, in the absence of fileset quota enforcement,
the "available" space for any fileset in the domain should be the
same -- that is, the size of the fileset is the size of the domain,
the "used" for the fileset should approximate the output of "du -s"
for the mount point of the fileset (when the fileset is mounted),
and the "available" should be approximated by the size of the whole
domain less the "used" space for all of its filesets (bear in mind
that unmounted fileset still occupy space).
Most of the logic for maintaining the tables from which "df" gets
the data pre-dates the existence of AdvFS as a file system type in
what is now Tru64 UNIX. Traditional UNIX file systems do NOT have
this "domains and filesets" implementation. So there is nothing
in the underlying kernel code that makes sure that all of the data
for the filesets within a domain remains consistent. Everything is
focused on "per mount point" (that is, per UNIX file system) logic
and making sure that it's consistent. And AdvFS complicates the
picture because it puts small files into a "fragment pool" that is
managed (as I recall) at the domain level, not the fileset level;
so things are murky at best. (A directory is always allocated as
a "big" file outside the "fragment pool", but user files usually
start by being allocated in the "fragment pool" and then migrate
out of it when they grow -- imagine keeping track of the space used
in the face of this, when it was never part of the original design
of a UNIX operating system file systems model.)
Whenever there is a transaction in any fileset that either allocates
more space or frees space, the table is updated, but if there is a
bug in the kernel logic, the table may not be right. And all that
"df" shows you is what's in the table. (There is a special system
call for retrieving the data, or anyway a library routine, statfs(),
read the reference page.) That's all "df" shows you, you can write
your own program to look at the data, but it's just something that
is pulled out of the kernel, and the kernel may have it wrong.
Tom
Dr. Thomas P. Blinn + UNIX Software Group + Compaq Computer Corporation
110 Spit Brook Road, MS ZKO3-2/W17 Nashua, New Hampshire 03062-2698
Technology Partnership Engineering Phone: (603) 884-0646
Internet: tpb_at_zk3.dec.com - or - thomas.blinn_at_compaq.com
ACM Member: tpblinn_at_acm.org PC_at_Home: tom_at_felines.mv.net
Worry kills more people than work because more people worry than work.
Keep your stick on the ice. -- Steve Smith ("Red Green")
My favorite palindrome is: Satan, oscillate my metallic sonatas.
-- Phil Agre, pagre_at_alpha.oac.ucla.edu
Yesterday it worked / Today it is not working / UNIX is like that
-- apologies to Margaret Segall
Opinions expressed herein are my own, and do not necessarily represent
those of my employer or anyone else, living or dead, real or imagined.
Received on Fri Mar 29 2002 - 14:28:43 NZST