Re: /var/log/lastlog -- why is it 19 megabytes?

• Previous message: Didier Casse: "Re: Print Configuration Problem"
• In reply to: Rodolfo J. Paiz: "Re: /var/log/lastlog -- why is it 19 megabytes?"
• Next in thread: Michael Schwendt: "Re: /var/log/lastlog -- why is it 19 megabytes?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

To: redhat-list@redhat.com
Date: Mon, 25 Aug 2003 03:42:45 -0400

Rodolfo,

On Sunday August 24, 2003 11:28, Rodolfo J. Paiz wrote:
> Is there someone out there with some coding expertise, who can maybe
> explain why "ls -l" and "ls -sh" give different results? Like this:

Not that I read the code but it isn't too hard to derive the answer from the
info page of ls.

`-s'
`--size'
     Print the disk allocation of each file to the left of the file
     name. This is the amount of disk space used by the file, which is
     usually a bit more than the file's size, but it can be less if the
     file has holes.

     Normally the disk allocation is printed in units of 1024 bytes,
     but this can be overridden (*note Block size::).

`-l'
`--format=long'
`--format=verbose'
     In addition to the name of each file, print the file type,
     permissions, number of hard links, owner name, group name, size in
     bytes, and timestamp (*note Formatting file timestamps::), normally
     the modification time.

So in this case it appears you have some VERY "holey" files. Since the -s is
telling you the space used and the -l is calculating the bytes used by
(number of blocks allocated - 1) * 512 + remainder.

Perhaps try running "stat" on a file and see if this is accurate.

I'll give some examples to try and illustrate this.

Here is an example file of ~40MB. You will see the blocks in the first version
and the "human interpretation of those blocks. By default, ls uses 1K blocks
for it's output of the -s flag.

[brian@hell test]$ ls -ls testfile
39376 -rw-r--r-- 1 brian brian 40274705 Jan 20 2003 testfile
[brian@hell test]$ ls -lsh testfile
 39M -rw-r--r-- 1 brian brian 38M Jan 20 2003 testfile

Note how what the man page told us holds true here as the two numbers don't
match. This is because of using (blocks * blocksize) and each having
different numbers to use. Now let's see what the system _really_ thinks about
this file.

[brian@hell test]$ stat testfile
  File: `testfile'
  Size: 40274705 Blocks: 78752 IO Block: 4096 Regular File
Device: 305h/773d Inode: 109 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 500/ brian) Gid: ( 500/ brian)
Access: 2003-08-25 02:24:01.000000000 -0400
Modify: 2003-01-20 10:34:12.000000000 -0500
Change: 2003-01-20 10:34:12.000000000 -0500

Now we see we actually have a 4K blocksize. But the number of blocks is still
in the default 512b size.

So let's tell ls what the blocksize actually is and see what it tells us.

[brian@hell test]$ ls --block-size=4K -ls testfile
9844 -rw-r--r-- 1 brian brian 40274705 Jan 20 2003 testfile

Notice the number of blocks changes but the file size doesn't. So now we can
see that the blocksize is playing a large part in how even the same command
can interpret what it is seeing.

However this doesn't explain what's going on, just what you see.

Everything from here on is either pure speculation or WAG. ;)

> ls -l:
> -rwxr--r-- 1 rpaiz rpaiz 1177207676 Aug 3 18:09 Kansas ~ Best of
> Kansas ~ 04 ~ Dust in the Wind ~ 890B500A.wav
> ls -sh:
> 35M Kansas ~ Best of Kansas ~ 04 ~ Dust in the Wind ~ 890B500A.wav
>

The difference here looks like a 32 times in difference (35 * 1024 * 1024 * 32
= 1174405120 (which is pretty close to the 1177207676 you see above
considering rounding)). Which the only thing I can guess at is perhaps one of
the two drives has a 32K blocksize and the other has a 1K blocksize. Further
it would seem that somehow the rsync command you used (or something else)
transfered blocks instead of bytes and really screwed up the layout of the
filesystem. I believe you mentioned that you had seen a 98% fragmented system
and this would seem congruent with some very holey files. Hence the vast
difference in reported sizes.

You really need to take a look inside these files to see what's going on. That
way you can see if there are real file issues or some sort of filesystem
confusion. You had mentioned earlier that you can't read a file in a hex
editor due to memory constraints. You should try something like
head -c 64k <filename> | od -c
to get a feel for what's in the file (look for zeroes).

The only thing I can think to recommend that would make sense is to grab a
defrag tool and see if it can fix it. Or if you can copy a file back to the
old drive using the same method and then use a different one to get it back
on the desired drive if that seems to restore sanity to the files.

Anyway, it's late here and there could be some inaccuracies, but perhaps you
can either get it fixed or provide some new info. I left out using debugfs
for now, since it can get very confusing if you're not used to it.

-- 
Brian Ashe                                                     CTO
Dee-Web Software Services, LLC.                  rhlist@dee-web.com
http://www.dee-web.com/
-- 
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list

• Previous message: Didier Casse: "Re: Print Configuration Problem"
• In reply to: Rodolfo J. Paiz: "Re: /var/log/lastlog -- why is it 19 megabytes?"
• Next in thread: Michael Schwendt: "Re: /var/log/lastlog -- why is it 19 megabytes?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]