Large discrepancy in reported disk usage on USR partition

Brendan Hart brendanh at strategicecommerce.com.au
Wed Oct 29 20:36:15 PDT 2008


On Thu 30/10/2008 12:25 PM, Jeremy Chadwick wrote:
>> Could the "missing" space be an indication of hardware disk issues i.e.
>> physical blocks marked as bad? 

>The simple answer is no, bad blocks would not cause what you're seeing.
>smartctl -a /dev/disk will help you determine if there's evidence the disk
is in bad shape.  I can help you with reading SMART stats if need be.

I took a look at using the smart tools as you suggested, but have now found
that the disk in question is a RAID1 set on a DELL PERC 3/Di controller and
smartctl does not appear to be the correct tool to access the SMART data for
the individual disks. After a little research, I have found the aaccli tool
and used it to get the following information:

AAC0> disk show smart
Executing: disk show smart
        Smart    Method of         Enable
        Capable  Informational     Exception  Performance  Error
B:ID:L  Device   Exceptions(MRIE)  Control    Enabled      Count
------  -------  ----------------  ---------  -----------  ------
0:00:0     Y            6             Y           N             0
0:01:0     Y            6             Y           N             0

AAC0> disk show defects 00
Executing: disk show defects (ID=0)
Number of PRIMARY defects on drive: 285
Number of GROWN defects on drive: 0

AAC0> disk show defects 01
Executing: disk show defects (ID=1)
Number of PRIMARY defects on drive: 193
Number of GROWN defects on drive: 0


This output doesn't seem to indicate existing physical issues on the disks. 

> Since you booted single-user and presumably ran fsck -f /usr, and nothing
came back, I'm left to believe this isn't filesystem corruption.

Yes, this is the command I tried when I went into the data centre yesterday,
and yes, nothing came back. 

I have done some additional digging and noticed that there is a /usr/.snap
folder present. "ls -al" shows no content however. Some quick searching
shows this could possibly be part of a UFS snapshot... I wonder if partition
snapshots might be the cause of my major disk space "loss". Some old message
group posts suggest that UFS snapshots were dangerously flakey on Release
6.1, so I would hope that my predecessors were not using them however...  Do
you know anything about snapshots, and how I could see what/if any/ space is
used by snapshots?

I also took a look to see if the issue could be something like running out
of inodes, But this does't seem to be the case:

#: df -ih /usr
Filesystem       Size    Used   Avail Capacity iused   ifree %iused  Mounted
on
/dev/aacd0s1f     28G     25G    1.1G    96%  708181 3107241   19%   /usr


BTW Jeremy, thanks for your help thus far.

I will wait and see if any other list member has any suggestions for me to
try, but I am now leaning toward scrubbing the system. Oh well.

Best Regards,
Brendan Hart

---------------------------------
Brendan Hart, Development Manager
Strategic Ecommerce Division
Securepay Pty Ltd
Phone: 08-8274-4000
Fax: 08-8274-1400 
 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3568 (20081030) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 



More information about the freebsd-questions mailing list