- 论坛徽章:
- 0
|
没人回答只好求助于usenet,老外给出的答复是这样的,我觉得可供参考
Ryan <ericchd@gmail.com> writes:
Mark Wooding:
> > 1.The book said:A particular feature of Unix-based operating
> > system,including the Linux ext3 file system,is the way space on a disk
> > is reserved for a file.
> > Under Linux,space is never released for a file.For example,if you
> > overwrite a 1MB file with a single byte,Linux still reserves one
> > megabyte of disk space for the file.
As you've written it, this is just wrong. I don't have the book in
question, so I can't say for certain whether it's wrong or whether
you've misinterpreted it.
It's true that you must explicitly truncate or delete a file if you want
to recover the space it occupies. You can delete a file by removing all
links to it and closing all file descriptors and memory mappings which
refer to it. You can truncate it using the truncate(2) or ftruncate(2)
functions, or by opening it with O_TRUNC. Shell output redirection `>
foo' does the latter. GNU Coreutils has a truncate(1) program which
lets you adjust file lengths.
> > Then i did a experiment:
> > dd bs=1024 count=1 of=a.txt if=/dev/zero
> > cat < /dev/null > a.txt
> > Now the size of a.txt became 0,NOT still 1024,am i misunderstond that?
> > if i were,what did the words above really mean?
Be careful here: the amount of space that a file occupies on disk is
only loosly related to its length, for two reasons.
* The file system needs to keep track of which blocks on the disk are
allocated to the file. The bigger the file is, the more space is
required to keep track of it. Traditional Unix file systems use
`indirect blocks' to do this: blocks which contain only the numbers
of other blocks. A 1-indirect block names direct blocks, which
actually hold the file's content; an n-indirect block names (n -
1)-indirect blocks. A file's inode typically stores the names of a
small number of direct blocks, 1-, 2-, 3-indirect blocks. The
indirect blocks are accounted as being occupied by the file, which
means that it may use more space than suggested by its length.
* Unix files can have `holes' in them: portions of the file to which
no block is actually allocated. When read, the holes appear to
contain zero bytes. Writing to a hole causes space to be allocated
to store what's written (even if it's zero). There is usually no
way to introduce a hole into a part of the file which has been
written. Holes are left if you use truncate(2) or ftruncate(2) to
increase a file's length, or if you write beyond its current length
(using lseek(2) or pwrite(2)). Since no disk space is used by
holes, a file which contains holes may use (much!) less space than
is suggested by its length.
So `ls -l' won't really tell you how much space a file is using. Use
`ls -s' instead.
Greg Andrews:
It isn't a megabyte. More like 4096 bytes. For efficiency reasons,
space on the disk drive is allocated in blocks rather than individual
bytes. The blocks are usually 4096 bytes in size, and to hold any
data at all, a file must have at least one block. You can reduce the
file to just one byte, but it still consumes enough space to hold
4096 bytes (one block).
But it's wrong to say that space is *never* released. If you delete
the file, it is. |
|