On Mon, Mar 04, 2002 at 08:47:06AM +0100, Alexander Skwar wrote:
> > I don't know exactly if this is really OK, but it is probably OK,
> > because you can have "holes" in a file (open/create file, seek to X MB
> > and write something, close it), so file size can be large but actual
> > disk usage is small. Coredump is likely to have an hole in it.
>
> Hm, I don't understand. I first thought you were saying that in the
> above file there were only 380 KiB of data and because of a seek or
> something, it would take up 6 MiB.
The logical file size can be X but actual physical disk usage (space
it's actually occuppies on a disc) could be Y (where Y <= X), because
the file can have "holes" in it.
ls shows "file sizes", du shows "disc usage".
If you create new file, seek to 6MB and write 1kB of data, you will
get file which contains 6MB+1kB of data which actually occupies
something more than 1kB but much smaller space than 6MB ...
Try this:
df .
dd if=/dev/zero of=test seek=100000000 count=1
ls -l test
du -hs test
df .
> What I'd like to know now: If my partition is 500 MiB, how many of
> those "6" MiB files with 380 KiB data can I have on the partition?
> 500/6 or is it 500/(380/1024)?
The second - not exactly, because it occupies a little more space, but
you propable get the idea.
P.S. It's an OFFTOPIC here, try searching google with something like
"file size disc usage space holes" if you want more. This is not about
cooker.
--
Martin Mačok http://underground.cz/
[EMAIL PROTECTED] http://Xtrmntr.org/ORBman/
