| Title: | DIGITAL UNIX (FORMERLY KNOWN AS DEC OSF/1) |
| Notice: | Welcome to the Digital UNIX Conference |
| Moderator: | SMURF::DENHAM |
| Created: | Thu Mar 16 1995 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 10068 |
| Total number of notes: | 35879 |
My customer is nfs mounting a filesystem from an SGI running IRIX 5.3.
The client is running Digital UNIX V4.0b. When showing the disk used
by a file with the "-s" switch on ls, the size doesn't seem right from
the DU system. For example -
From the DU system (I edited out group names to make it easier to read)
# ls -las
total 322451016
64 drwxr-xr-x 2 root 512 Jan 19 22:10 .
8 drwxr-xr-x 25 root 8192 Feb 3 03:37 ..
60063680 -rw-r--r-- 1 root 480509018 Jan 23 15:21 cd1.tar.gz
62737984 -rw-r--r-- 1 root 501903422 Jan 17 03:22 cd2.tar.gz
140006400 -rw-r--r-- 1 root 1120051200 Jan 19 22:09 du.vdump
7080960 -rw-r--r-- 1 root 56647680 Jan 19 22:10 root.vdump
52561920 -rw-r--r-- 1 root 420495360 Jan 19 22:20 usr.vdump
From the SGI system (minus group names)
root 2: ls -las
total 5038298
1 drwxr-xr-x 2 root 512 Jan 19 22:10 .
1 drwxr-xr-x 12 root 512 Feb 3 23:38 ..
938495 -rw-r--r-- 1 root 480509018 Jan 23 15:21 cd1.tar.gz
980281 -rw-r--r-- 1 root 501903422 Jan 17 03:22 cd2.tar.gz
2187600 -rw-r--r-- 1 root 1120051200 Jan 19 22:09 du.vdump
110640 -rw-r--r-- 1 root 56647680 Jan 19 22:10 root.vdump
821280 -rw-r--r-- 1 root 420495360 Jan 19 22:20 usr.vdump
So the file size in bytes matches exactly. But the disk space used is
very different. I know "-s" counts the sparse parts of a file. I
since the files are over 16M, it is using the second level of indirect
blocks. I understand that the indirect blocks get counted in this
amount. But the strange thing is that the disk used is ALWAYS 1/8 of
the file size, instead of 1/512, as I would expect. I noted also that
some of these are vdumps...
Could the second level of indirection account for these high disk usage
numbers? Does anyone out there have access to an SGI to see if they
see the same behavior?
Thanks for any input,
janet
csc/cs
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 8740.1 | NABETH::alan | Dr. File System's Home for Wayward Inodes. | Thu Feb 06 1997 16:24 | 6 | |
Could they be using different values for the size of a "block"? It just so happens that the ratio of blocks between the two is consistent 64 to 1. We could be using 1 KB blocks and SGI using 64 KB blocks. Close reading of the each system's ls(1) manual page may clear this up. | |||||
| 8740.2 | still strange... | RHETT::AMAN | Thu Feb 06 1997 21:39 | 23 | |
I'll have him check his man page. I just noticed that the 'ls' man
page changes between V3.2x and V4.0. Standards...
From V3.2G -
-s Gives space used in n 512-byte units (including indirect blocks)
for each entry.
From V4.0 -
-s [XPG4-UNIX] Gives space used in n 1024-byte units (including
indirect blocks) for each entry.
So, it would seem the disk space would be
(file size in bytes)/1024 + sparseness + indirect blocks
instead of
(file size in bytes)/8
Could the indirect blocks really account for that much difference?
Maybe a peek at 'ls' sources will help me.
Thanks!
janet
Thanks,
janet
| |||||
| 8740.3 | has this problem been solved? | MUNICH::DANNER | Thu Apr 10 1997 06:22 | 14 | |
One of our customers experiences the same problem as described in .0.
SGI IRIX 5.3 patch 1477 is installed, which is said to fix all known
IRIX NFS problems (includes patch 547,481 &others)
du -k on Solaris 2.5 does not show a mismatch with SGI like
Digital Unix V4.0b (shows physical file allocation 64 times bigger
than IRIX/Solaris)
What solved this problem or is it still an open issue?
thanks in advance
Reinhold
CSC Muc
| |||||