SUMMARY: strange df result

From: Grzegorz Bakalarski <>
Date: Mon Sep 15 2003 - 10:22:26 EDT
Dear All,

Thanks to Denis Perchine <> and
for discussion. At present I think I found the origin
of this behaviour. It seems to me this is a bug in Solaris 9 8/03
(or possibly any Solaris 9 patched to recent recommended pachtes).
I found the following info:

(look for ufs bugs or issues)

Here is an excerpt:

-----------------------SUN's doc info -----------------------------------
Using the UFS noatime and logging Mount Options Can Result in File System Corruption (4884138)
If the UFS noatime and logging mount options are used together, the file system can become corrupted because an inode is not being written. This failure can result in the display of the following messages:

/mnt: unexpected allocated inode 1783, run fsck(1M)...
/zoot: unexpected free inode 5674, run fsck(1M)...

Workaround: Perform the following steps:

Determine which file systems are using the noatime and logging mount options.

% mount | grep noatime | grep logging

Edit /etc/vfstab to remove the noatime option from all file systems that use the logging option.

Unmount and run the fsck command against all the file systems that were mounted by using the logging and noatime mount options.

Run the fsck command against any currently unmounted file systems that were previously mounted with the logging and noatime mount options.

------------------ END of Excerpt -----------------------------

This is my case. I used logging,noatime in vfstab for almost all  my
disks ... 



P.S. What I learned from above doc page, is there are still problems
with UFS and multiterabyte filesystems. So If one does not have
unpredicted problems with ufs, he/she should keep filesystem below
1TB ...

---------------ORIGINAL QUERY ------------------------
Machine, V880, Solaris, all recommended patches up Sep/11/2003

I have a disk 73GB (FC - plain disk - ufs with no mirroring,
one big partitition). Mounted with logging.
There is a big file on it (a tar archive from my DB system).
The size of the file is 60404773888 bytes ...
du -h shows 56GB ... But df shows the following

df -k
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/dsk/c1t3d0s2    70564432  573364 69991068     1%    /disk/c1t3

No links, no funny setting. Just ufs filesystem with 5 files. Here is full
output from du -ha starting from mount point of the disk:

  56G   ./sci_xml.tar
 640K   ./iplog/log
 296K   ./iplog/log.1
 940K   ./iplog
 496M   ./tcpdump/log
 764M   ./tcpdump/log200309131504
 1.2G   ./tcpdump
  58G   .

So I have 56GB file, 764MB file, 496MB file, 640KB file and 296KB file
- about 57GBytes.
But df shows 573364 Kbytes used and 69 991 068 KBytes free ...
So even if the huge file makes problems, the size of 4 other normal
files gives about 1.2GBytes ...
Any idea? Where should I look for ???

The only unusual messages during last reboot were:

 krtld: [ID 469452] NOTICE: sf: 64-bit driver module not found
 scsi: [ID 243001] /pci@8,600000/SUNW,qlc@2/fp@0,0 (fcp0):
       ndi_devi_online: failed for ses: target=dc lun=0 ffffffff
 scsi: [ID 243001] /pci@8,600000/SUNW,qlc@2/fp@0,0 (fcp0):
       ndi_devi_online: failed for ses: target=dc lun=0 ffffffff

System looks like working fine!

OBP recent (from June/2003).

--------------------- UPDATE (fsck results) --------------------
Some more info. Digging out little bit more, I unmounted the
filesystem (fortunately I could do this!) and run fsck.
Here is result:

# umount /disk/c1t3
# fsck /dev/rdsk/c1t3d0s2
** /dev/rdsk/c1t3d0s2
** Last Mounted on /disk/c1t3
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups

9 files, 15102187 used, 17472835 free (1 frags, 8736417 blocks, 0.0% fragmentation)

# mount /disk/c1t3

After this operation df shows correct numbers:

# df -k .
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/dsk/c1t3d0s2    70564432 60474292 10090140    86%    /disk/c1t3
What is funny, machine was rebooted on Saturday (the big file was created
month ago). There was no crash on this system. It was always properly
shutdowned and restarted. Do you think that logging makes some trick.
Other path: I recently loaded recent pachtes which deal with ufs ...
May it be a result of ufs upgrade (or incompatibility of new ufs with
old ufs )?

-------------------------- EoT---------------------------------
sunmanagers mailing list
Received on Mon Sep 15 10:27:27 2003

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:19 EST