ls ig giving the wrong sizing?

[F Verschuren]

Hi,
I have a 90 gig filesystem and if I look whit ls there is 100 gig is used
I found that i have some files:

du -ks tempimp_2.dbf
1518616 tempimp_2.dbf

ls -al tempimp_2.dbf
-rw-r----- 1 oraccr dba 5368717312 Jan 26 23:25 tempimp_2.dbf

Does is this a bug in ls ore is ther a explanation?

[Arunvijai_4]

Hello,

It is not a bug, you can check this thread for more information

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=968235

-Arun

[Muthukumar_5]

Nope.

You have to check as,

du -s filename
ls -s filename

it will be same. It is meaning to show size in 512 blocks.

du -ks filename
ls -s filename (size field * 2 ) will be same to denote 1024k blocks.

Read du and ls man page.

--
Muthu

[Eric Antunes]

Hi,

"ls -al" gives you the size in bytes and "ls -as" will give you the size in blocks (512 bytes = 1 block)...

Best Regards,

Eric Antunes

[F Verschuren]

whit the -s option it is the same,
after reading the man page prealloc
I think that that was used when creating the file

[A. Clay Stephenson · Accepted solution]

This is an artifact of sparse files; it is not at all uncommon for database files to be sparse. Essentially, all that happens is that an lseek() is done to very large offset and then data are written there and the file is closed. The "missing" data are filled in with NUL's when the data are actually read. Just as airlines can overbook a flight, sparse files can overcommit a filesystem.

[F Verschuren]

Tanks, I have mailed the Oracle DBA the reason.

[F Verschuren]

closed