du and ls

du and ls

[Fabio Miranda Hamburger]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed, Size: 405 bytes --]

Hello,

I am curious about the mismatch between du and ls. Apparently, du reports 
amount of 512 or 1024-K blocks, and ls lists the absolute value.

But, why in some cases, a 1100 bytes file is reported by du as 4 x 512 
bytes instead of 3 x 512bytes

I note both use fstat().

Thanks for advice,

---
Fabio Andrés Miranda
Ingeniería en sistemas informáticos
Universidad Latina - Costa Rica

Re: du and ls

[Glynn Clements]

Fabio Miranda Hamburger wrote:

> I am curious about the mismatch between du and ls. Apparently, du reports 
> amount of 512 or 1024-K blocks, and ls lists the absolute value.

du reports the amount of disk space which the file uses, while ls
reports the amount of data which it contains.

> But, why in some cases, a 1100 bytes file is reported by du as 4 x 512 
> bytes instead of 3 x 512bytes

Because the file occupies 2 x 1024-byte blocks.

> I note both use fstat().

stat(), fstat() etc, and thus du, report disk usage in multiples of
512-byte blocks, as that was the block size on the earliest Unix
systems. The actual block size depends upon the filesystem.

The st_size field indicates the actual size of the file (i.e. the
number of bytes which it contains); this is the value reported by ls. 

The st_blocks field returns the disk usage in multiples of 512 bytes;
this is the value reported by du.

Note that the actual size of the file can be more than 512 * st_blocks
bytes if the file contains "holes". These are blocks which are
implicitly filled with zeros when the file is enlarged by lseek(),
ftruncate() etc, and aren't actually stored on disk.

-- 
Glynn Clements <glynn@gclements.plus.com>

Re: du and ls

[Fabio Miranda Hamburger]

> Fabio Miranda Hamburger wrote:
>
>> I am curious about the mismatch between du and ls. Apparently, du reports
>> amount of 512 or 1024-K blocks, and ls lists the absolute value.
>
> du reports the amount of disk space which the file uses, while ls
> reports the amount of data which it contains.
>
>> But, why in some cases, a 1100 bytes file is reported by du as 4 x 512
>> bytes instead of 3 x 512bytes
>
> Because the file occupies 2 x 1024-byte blocks.
>
>> I note both use fstat().
>
> stat(), fstat() etc, and thus du, report disk usage in multiples of
> 512-byte blocks, as that was the block size on the earliest Unix
> systems. The actual block size depends upon the filesystem.
>
> The st_size field indicates the actual size of the file (i.e. the
> number of bytes which it contains); this is the value reported by ls.
>
> The st_blocks field returns the disk usage in multiples of 512 bytes;
> this is the value reported by du.
>
> Note that the actual size of the file can be more than 512 * st_blocks
> bytes if the file contains "holes". These are blocks which are
> implicitly filled with zeros when the file is enlarged by lseek(),
> ftruncate() etc, and aren't actually stored on disk.


Glynn, why lseek() will fill space with zeros if it's placed in a position 
beyond file limit itself? To provide to the application a fixed size of 
data for one purpose and so on.

Example, an application will use first 1025k of a file for something, then 
the next 2048 fo another, is this the intention of lseek() ?

Please, adivse,

Thanks,

fabio

Re: du and ls

[Glynn Clements]

Fabio Miranda Hamburger wrote:

> >> I am curious about the mismatch between du and ls. Apparently, du reports
> >> amount of 512 or 1024-K blocks, and ls lists the absolute value.
> >
> > du reports the amount of disk space which the file uses, while ls
> > reports the amount of data which it contains.
> >
> >> But, why in some cases, a 1100 bytes file is reported by du as 4 x 512
> >> bytes instead of 3 x 512bytes
> >
> > Because the file occupies 2 x 1024-byte blocks.
> >
> >> I note both use fstat().
> >
> > stat(), fstat() etc, and thus du, report disk usage in multiples of
> > 512-byte blocks, as that was the block size on the earliest Unix
> > systems. The actual block size depends upon the filesystem.
> >
> > The st_size field indicates the actual size of the file (i.e. the
> > number of bytes which it contains); this is the value reported by ls.
> >
> > The st_blocks field returns the disk usage in multiples of 512 bytes;
> > this is the value reported by du.
> >
> > Note that the actual size of the file can be more than 512 * st_blocks
> > bytes if the file contains "holes". These are blocks which are
> > implicitly filled with zeros when the file is enlarged by lseek(),
> > ftruncate() etc, and aren't actually stored on disk.
> 
> Glynn, why lseek() will fill space with zeros if it's placed in a position 
> beyond file limit itself? To provide to the application a fixed size of 
> data for one purpose and so on.
> 
> Example, an application will use first 1025k of a file for something, then 
> the next 2048 fo another, is this the intention of lseek() ?

An application may want to write fixed-sized records, so that they can
be accessed in an arbitrary order, using lseek() to locate a specific
record.

-- 
Glynn Clements <glynn@gclements.plus.com>