8/23/13 Why "file-size" of "sar -v" is different with "lsof | wc -l" (AIX World)

https://www.ibm.com/developerworks/community/blogs/aixworld/entry/why_file_size_of_sar_v_is_different_with_lsof_wc_l3?lang=en 1/5
0
Like 0

Tweet 0
IBM
Why "file-size" of "sar -v" is different with "lsof |
wc -l"
One month ago a colleague asked me a
question:
why the "file-size" in output of "sar -v" is
different with "lsof | wc -l"?
For example:
# sar -v
09:23:31 proc-sz inod-sz file-sz thrd-
sz
09:23:32 82/262144 0/201 933/11215 321/524288
# lsof | wc -l
767
From above output we can find that lsof reports a smaller number
than file-sz (767 vs 933).
He thought the file-size means the number of open files in the
system,
and the lsof also reports files opened by processes in the system.
So it is strange why they are different.
To answer this question,
we need to know clearly what "sar -v" and lsof actually report:
1. sar -v
# man sar
-v
Reports status of the process, kernel-thread, i-node, and file
tables. The following values are displayed:
file-sz, inod-sz, proc-sz , thrd-sz
Reports the number of entries in use for each table.
So file-size 933/11215 means there is currently 933 entries in use
(among 11215 entries) for file table.
In fact we can get it from kdb:
(0)> file | wc -l
937

AIX World Log in
to participate
About this blog
Discuss various AIX issue
Related posts
IBM extension (2) ...
UpdatedYesterday 2:28 PM
0 0
Taking advantage of ...
UpdatedYesterday 1:43 AM 0
0
How to filter the ou...
UpdatedAug 20 0 5
Debugging batch COBO...
UpdatedAug 14 0 0
SAMP Introduction & ...
UpdatedAug 7 2 0
Tags
Find a Tag
aix dump f ile f s gcc jfs2 kdb
kernel lib libintl lsof lvm restore
rm sar sync syncd umount
Cloud List
Share
8/23/13 Why "file-size" of "sar -v" is different with "lsof | wc -l" (AIX World)
https://www.ibm.com/developerworks/community/blogs/aixworld/entry/why_file_size_of_sar_v_is_different_with_lsof_wc_l3?lang=en 2/5
0)> var | grep v_file
v_file....... 0000000000002BCF
0x2BCF==11215
We can also get Max entries in file tbl (only for aix 6.1/7.1):
(0)> var | grep v_file_max
v_file_max... 00000000002E88B8
In addition to sar/kdb,
we may also write our own program to get these info.
For example:
vi test.c:
#include <sys/stat.h>
#include <stdlib.h>
#include <stdio.h>
int main()
{
long long nofile;
ptx_get_file_count(&nofile);
printf("%lld\n", nofile);
}
vi test.exp:
#!/unix
ptx_get_file_count syscall3264
xlc -o test -bI:./test.exp test.c
# ./test
933
Sometimes we will find above tool is useful when we get into trouble
to run "sar -v" like:
# sar -v
Can't open /var/adm/sa/sa06
Try running /usr/lib/sa/sa1 <inc> <num>
2. lsof | wc -l
Now let us take a look at lsof.
In fact lsof 00FAQ already explains this issue:
3.19 Why is `lsof | wc` bigger than my system's open file limit?
There is a strong temptation to count open files by piping
lsof output to wc. If your purpose is to compare the number
you get to some Unix system parameter that defines the
number of open files your system can have, resist the
temptation.
One reason is that lsof reports a number of "files" that
don't occupy Unix file table space -- current working
directories, root directories, jail directories, text files,
8/23/13 Why "file-size" of "sar -v" is different with "lsof | wc -l" (AIX World)
https://www.ibm.com/developerworks/community/blogs/aixworld/entry/why_file_size_of_sar_v_is_different_with_lsof_wc_l3?lang=en 3/5
library files, memory mapped files are some. Another reason
is that lsof can report a file shared by more than one
process that itself occupies only one file table slot.
If you want to know the number of open files that occupy
file table slots, use the +ff option and process the lsof
output's FILE_ADDR column information with standard Unix
tools like cut, grep, sed, and sort.
You might also consider using use lsof's field output with
+ff, selecting the file struct address with -FF, and
processing the output with an AWK or Perl script. See the
list_fields.awk, list_fields.perl, and shared.perl5 scripts
in the scripts/ subdirectory of the lsof distribution for
hints on file struct post-processing filters.

We may find 00FAQ under lsof source code directory.
To verify it let us do a simple test.
vi test.c:
#include <stdio.h>
int main(int argc, char** argv)
{
FILE * fp;
fp = fopen("foo", "w");
pause();
return 0;
}
xlc -o test test.c
./test
# lsof +ff | grep test
test 5243028 root cwd VDIR 10,8 4096 4128
/home (/dev/hd1)
test 5243028 root 0u VCHR 0xf1000f1e500e1658 31,2
0t2494 4496 /dev/pts/2
test 5243028 root 1u VCHR 0xf1000f1e500e1658 31,2
0t2494 4496 /dev/pts/2
test 5243028 root 2u VCHR 0xf1000f1e500e1658 31,2
0t2494 4496 /dev/pts/2
test 5243028 root 3w VREG 0xf1000f1e500a6f58 10,8 0
4481 /home (/dev/hd1)
There is no file pointer in the "cwd" line.
So it is resonable that `lsof | wc -l` is bigger than "file-sz".
Then why `lsof | wc -l` is reversely smaller than "file-sz" in our initial
example (767 vs 933)?
Here lsof "X" option come into play.
8/23/13 Why "file-size" of "sar -v" is different with "lsof | wc -l" (AIX World)
https://www.ibm.com/developerworks/community/blogs/aixworld/entry/why_file_size_of_sar_v_is_different_with_lsof_wc_l3?lang=en 4/5
Add a Comment More Actions
Comments (0)
Only when we use "X" option, lsof will report text files, library files and
memory mapped files:
# lsof -X | wc -l
1182
Now it is much bigger than 933 (file-sz).
#lsof +ff -X | grep test
test 5243028 root cwd VDIR 10,8 4096 4128
/home (/dev/hd1)
test 5243028 root txt VREG 0xf1000f1e50066870 10,8 4734
4500 /home (/dev/hd1)
test 5243028 root L00r VREG 0xf1000f1e50012808 10,5
11525 12736 /usr (/dev/hd2)
test 5243028 root L01r VREG 0xf1000f1e50010188 10,5
11807579 57351 /usr (/dev/hd2)
test 5243028 root 0u VCHR 0xf1000f1e500e1658 31,2
0t2494 4496 /dev/pts/2
test 5243028 root 1u VCHR 0xf1000f1e500e1658 31,2
0t2494 4496 /dev/pts/2
test 5243028 root 2u VCHR 0xf1000f1e500e1658 31,2
0t2494 4496 /dev/pts/2
test 5243028 root 3w VREG 0xf1000f1e500a6f58 10,8 0
4481 /home (/dev/hd1)
# ncheck -i 4500 /home
/home:
4500 /wjj/test
# ncheck -i 12736 /usr
/usr:
12736 /lib/libcrypt.a

(0)> file 0xf1000f1e50066870
ADDR COUNT OFFSET DATA TYPE FLAGS
F1000F1E50066870 1 0000000000000400 F1000A0048A82020
VNODE EXEC

Above output demonstrates that text and ibrary files also occupy AIX
file table space,
this is different with what lsof 00FAQ described.
Conclusion:
It is resonable that `lsof | wc -l` has different value with "file-sz" since
they report different things.
And `lsof -X| wc -l` should bigger than "file-sz".
Tags: sar lsof kdb aix
Add a Comment More Actions
8/23/13 Why "file-size" of "sar -v" is different with "lsof | wc -l" (AIX World)
https://www.ibm.com/developerworks/community/blogs/aixworld/entry/why_file_size_of_sar_v_is_different_with_lsof_wc_l3?lang=en 5/5
Previous Entry Main Next Entry
Technical topics Evaluation software Community Events IBM