Could you please let me know what each of the output fields in ls -ltr for a directory imply.
Example :
drwxrwsr-x 4294967295 infamgr infagrp 2147549184 Sep 2 17:01 job
basically would want to know 4294967295 and 2147549184
Given the positions of the numbers in your ls output, the first number would be the link count number, and the second one the directory size (in blocks). What type of filesystem is mounted on that directory? A network one, a USB one, or some other that your OS doesn't fully understand, but it happy to read?
Thank You, it is on network.
By Size in Blocks - would this give an idea of how much size it occupies in GB ?
But i see the parent directory of this dir has a lower block size.. So i am a little confused.
cd /prod/
@:/prod #ls -ld logs
drwxrwsr-x 28 xyz abc 134217728 Sep 12 17:49 logs
@:/prod #cd logs
@:/prod/logs #ls -ld job
drwxrwsr-x 4294967295 xyz abc 2147614720 Sep 12 17:49 job
I've never really paid much attention, if I'm honest, to what NetApp, or whatever network storage, tells me in terms of the sizes of directories (files (and especially ownership) would be different - for example, the number 4294967295 might indicate that the disk is not correctly assigned). I know if I were to look on the filer that everything is probably OK. What it chooses to report to your (client) OS as being the correct information is being misinterpreted by the OS. It's possible there may be some options when mounting the filesystem, or some software that's tightly couple with the storage technology that can be installed, to get you the right numbers.. but, generally, it's really not something to worry about.
In principle: yes. Blocksize depends on the filesystem type, though. Originally in UNIX this was 512 bytes and this is still true for many FSes. XENIX filesystem had a blocksize of 2048 bytes and that too has been adopted by some others (although considerably less). Sometimes block sizes of 4096 bytes are used too and probably there are some others i just don't remember off the top of my head. Issue the mount command, most systems will show which type of FS they (think to) have mounted. Take it from there.
There are several possible explanations for this: the parent directory could be on another FS or your system doesn't fully understand the networked FS it mounted (enough to handle the file access but can't grok the FS statistics).
I hope this helps.
bakunin
The size of the directory is not the size of the blocks, but rather the product of blocksize and number of blocks used. Consider this on my system:
$ echo > file
$ mkdir dir
$ ls -ld file dir
drwxr-xr-x 2 apm sog 4096 13-Sep 09:15 dir
-rw-r--r-- 1 apm sog 1 13-Sep 09:14 file
$ du file dir
4 file
4 dir
$ du -b file dir
1 file
4096 dir
Both file and dir occupy a single 4096 byte-sized block. ls shows the size of the file regardless of the amount of disk space it occupies. The directory, on the other hand, appears to fit the block it occupies. As you add more to the file it grows until it occupies two, three, or even twenty blocks. Think of the directory as look-up table, containing two fields per record: the name of the file it "contains", and the files inode number. As you add files to the directory it fills up the table until there is no more room, at which point it will grow into a second block. Now look at the number of links if your two directories. Evidently job contains more files than logs, requiring it to use more disk space Hence the discrepancy.
I should point out that I don't know the full workings of file systems; I don't really need to. The above assumptions just give me that warm, fuzzy feeling that I need to use them.
Andrew
Something you can try to do is determine the sizeof a dir entry on your system...it's a simple C program to write and it'd give you how much storage each dir entry takes up...although the "no. of entries X sizeof each dir entry" may still not equal the 2147549184 figure...at least that'd be the rationale behind it yet the kernel has complete control over the inner workings of a dir so one cannot be sure of what it's actually doing.