Dear managers,
i had problems to understand the output of "ls -l"
and your answers have been very helpful!
My special thanks to:
"Brian 'Doc' O'Neill" <oneill_at_cs.uml.edu>
Igor Natanzon <igor_at_cs.cs.miami.edu>
Robert Munn <munn_at_tristan.umd.edu>
"Dr. Tom Blinn, 603-881-0646" <tpb_at_zk3.dec.com>
Hans Ranke <Hans.Ranke_at_Regent.E-Technik.TU-Muenchen.DE>
Birgit Fruehwirth <birgit_at_osf4us.enet.dec.com>
Erick Bizouarn <eb_at_two-oo-one.fr>
Ray Bellis <Ray.Bellis_at_psy.ox.ac.uk>
alan_at_nabeth.cxo.dec.com (Alan Rollow>
I include here the answers of Dr. Tom Blinn, Alan Rollow and Brian O'Neill,
which gives a picture full of details.
<tpb_at_zk3.dec.com> says:
> All that ls -l does is do a stat() on the file and report the byte
> count from the data structure returned by stat(). This may or may
> not really have anything to do with the real size of the file, since
> the file may have "holes" in it (pages that contain no data and
> aren't mapped in the file).
> What other utilities are reporting is the count of pages (e.g., 512
> byte or 1K chunks actually used on disk to hold the file's data).
> This count may be much smaller than you would think it should be (or
> larger, as the case may be) depending on whether the files in
> question have lots of holes, and if they happen to nicely fill what
> you think is the on-disk cluster size (for the UFS file system, disk
> space is allocated in 1Kbyte chunks, but for the AdvFS file system it
> is allocated in 8KB chunks, and a small file will take up at least
> one chunk in either file system).
alan_at_nabeth.cxo.dec.com said:
> Files have two sizes associated with them; the number of blocks
> allocated to the file and the byte size. It is possible for a file
> not to have blocks allocated to some of the space. Such files are
> called "sparse". When the file system code reads one of this holes
> it uses NULs for the data. See the lseek(2) manual page for more
> information about creating a sparse file.
> Kernel core dumps, quota files, dbm(3) and ndbm(3) databases are
> common users of sparse files. In case the case of a kernel core dump
> only the pages essential to crash dump analysis are saved; unused
> page, program data, etc aren't. The result is the ability to save a
> large file without using all the required space.
oneill_at_cs.uml.edu said:
> UNIX has what is known as "sparse files". A file which has disk
> blocks which simply contain nulls just isn't allocated. Since a crash
> dump is a dump of memory, and memory pages might not be used or
> relevant, it doesn't allocate disk blocks for them, instead I believe
> the inode pointers point to NULL.
> To get a better sense, "ls -ls" will prepend each line with the
> number of 1k blocks allocated to that file.
> One note of warning...not all file backup/archiving utilities handle
> spare files well...they would be restored at full size...
Thank you again!
Bernt Christandl
-------------------------------------------------------------------------
- Bernt Christandl / Max Planck Institut fuer Extraterrestrische Physik -
- D-85740 Garching / Phone: +49/89/3299-3346 / Fax: +49/89/3299-3569 -
- Internet: beb_at_mpe-garching.mpg.de -
-------------------------------------------------------------------------
Received on Mon Feb 05 1996 - 17:41:16 NZDT