8.2 - High Srorage Partition Usage

Can you pinpoint which directory the "new" space usage is in?

Now -100%
Hi Skott.
How you can see that?
BTW - the CPU also got higher/

Hi ,
Can u please check at ssh 
1) cd /var/storage/cores/
2) ls -ltr and post last 10 lines

do u have local database enable ?  if enable please check with 

 cd /var/chroot-http/var/pattern/sfcontrol/
 
thx

Normally this kind of issue is caused by reporting database corruption.  In this case though it could also have something to do with the big schema changes in 8.200, especially if you had a ton of historical reporting data.

Once you get the information, per utm_kids detailed instructions and post them here, do a reboot and see if that fixes it.

If not, I can give you instructions on how to rebuilt the database if necessary.

Hi guys.
Thanks for the speedy response.
After Clearing the Http cache, the storage dropped dramatically.
Very strange, because the HTTP proxy cache was and is not NOT even active [:S]

rw-r--r-- 1 root root   2084864 2011-06-22 12:53 httpd.12865
-rw-r--r-- 1 root root   2224128 2011-06-22 12:54 httpd.12915
-rw-r--r-- 1 root root   2891776 2011-06-23 10:47 httpd.5655
-rw-r--r-- 1 root root 216846336 2011-07-05 21:42 snort_inline.22666
-rw-r--r-- 1 root root   1912832 2011-07-22 07:08 httpd.11298
-rw-r--r-- 1 root root   1912832 2011-07-22 07:32 httpd.10781
-rw-r--r-- 1 root root  82063360 2011-07-22 07:36 afcd.7433
-rw-r--r-- 1 root root  81731584 2011-07-22 08:07 afcd.17130
-rw-r--r-- 1 root root  81637376 2011-07-22 08:09 afcd.17242
-rw-r--r-- 1 root root  81641472 2011-07-22 08:13 afcd.17373
-rw-r--r-- 1 root root  81637376 2011-07-22 11:01 afcd.30864

*shrugs*  Chalk it up to some post install goofiness.

Guess you're good to go now.  [:)]

We were too Happy, too soon :}
Start rising again...


-rw-r--r-- 1 root root   2224128 2011-06-22 12:54 httpd.12915
-rw-r--r-- 1 root root   2891776 2011-06-23 10:47 httpd.5655
-rw-r--r-- 1 root root 216846336 2011-07-05 21:42 snort_inline.22666
-rw-r--r-- 1 root root   1912832 2011-07-22 07:08 httpd.11298
-rw-r--r-- 1 root root   1912832 2011-07-22 07:32 httpd.10781
-rw-r--r-- 1 root root  81731584 2011-07-22 08:07 afcd.17130
-rw-r--r-- 1 root root  81637376 2011-07-22 08:09 afcd.17242
-rw-r--r-- 1 root root  81641472 2011-07-22 08:13 afcd.17373
-rw-r--r-- 1 root root  81637376 2011-07-22 11:01 afcd.30864
-rw-r--r-- 1 root root  81952768 2011-07-22 14:43 afcd.15472

It is probably the reporting database corruption thing then.

Follow the steps in posts from buddy007 in the thread at https://community.sophos.com/products/unified-threat-management/astaroorg/f/53/t/33301.  This will allow you to confirm that this is the problem and remediate.

Be aware that if you do need to rebuild the db, you'll lose any current reporting data.

Let me know if this helps.  [:)]

Sorry ,i am not expert in debug the  asg or linux but my guess is (as per my basic and small brain) afcd -astaro flow con*** deamon is crashing and which suppose to be replace by new application control 

do u see any segfault in kernel log ? 

again sorry this is very basic idea /thought if this system is critical u should open tickets 

if i had to handle this case i would have /var/storage/core file to local sytem (desktop ) becase they are in aound 500 md if u r disk size is small  

btw what is u r disk size 
df  -h ? 
edit " is u r internet usege is high now ? 
can u please try to disable log mgmt and see the differance ? 

thx

550 users, ASG 7.5x Dell PowerEdge 1900, 4GB ram, 120 GB x2 (Raid 0) hdd, 11 intel Nics

Thanks...