Dear All, Thanks to Denis Perchine <dyp@perchine.com> and joe.fletcher@btconnect.com 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: http://docs.sun.com/db/doc/817-0496/ (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 ... Cheers, GB 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 kern.info] NOTICE: sf: 64-bit driver module not found scsi: [ID 243001 kern.info] /pci@8,600000/SUNW,qlc@2/fp@0,0 (fcp0): ndi_devi_online: failed for ses: target=dc lun=0 ffffffff scsi: [ID 243001 kern.info] /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 FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? y 9 files, 15102187 used, 17472835 free (1 frags, 8736417 blocks, 0.0% fragmentation) ***** FILE SYSTEM WAS MODIFIED ***** # 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 sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived 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