perfSONAR User Q&A and Other Discussion

[Aaron Brown <>]

Hey Winnie,

If there’s not a lot in the failed, my guess then is that it got into a bad 
state, and the perl module never cleaned up the old directories. You can 
safely remove them, though you’ll need to do a “service regular_testing 
restart” after doing so.

Cheers,
Aaron


> On Jan 29, 2015, at 9:18 AM, Winnie Lacesso 
> <>
>  wrote:
> 
> Good afternoon!
> 
> On Thu, 29 Jan 2015, Aaron Brown wrote:
>> Hey Winnie,
>> 
>> Are the lots of files under a 'failed' directory? If so, could you send 
> No. Or they've already been removed.
> 

>> us the /var/log/perfsonar/regular_testing.log?    
> 
> The box has been broken since late Nov so the regular_testing.log is 
> probably full of "broken, broken, broken"
> 
> The poor box has been chugging away about 3hours now on find + remove of
> Nov+Dec timestamped files in esmond_latency_localhost/active/queue & data
> 
> df -i / is showing # free inodes increasing, it's just taking a long time.
> 
>> As to the files themselves, you can safely axe them. Anything that's in 
>> the 'failed' section can probably be removed, no matter the age.  
> 
> Is it safe to remove the entire file directory structure though? for 
> instance 
> in esmond_latency_localhost/active/data
> drwxrwxrwx  5 perfsonar perfsonar 4096 Oct 29 02:03 0/
> drwxrwxrwx  5 perfsonar perfsonar 4096 Nov 28 14:22 1/
> drwxrwxrwx  4 perfsonar perfsonar 4096 Dec  4 02:02 5/
> drwxrwxrwx  5 perfsonar perfsonar 4096 Dec  1 12:00 M/
> drwxrwxrwx  5 perfsonar perfsonar 4096 Oct 29 02:03 N/
> drwxrwxrwx  3 perfsonar perfsonar 4096 Dec 18 16:09 O/
> drwxrwxrwx  4 perfsonar perfsonar 4096 Dec  4 02:02 w/
> drwxrwxrwx  3 perfsonar perfsonar 4096 Dec  1 12:00 z/
> 
> and each of those has several single-digit-or-letter directories inside it a
> few levels deep with thousands of files in them.
> 
> It'd be much easier to /bin/rm -rf esmond_latency_localhost/* (if that's 
> safe)
> than find & remove the _files_ (only) several directory layers deep inside
> (via find -type f -mtime +30 etc etc etc)
> 
> But would perfsonar services, once restarted, correctly & safely be able to 
> recreate the directory hierarchy inside esmond_latency_localhost ???
> 
> Same question for esmond_throughput_localhost & esmond_traceroute_localhost
> altho they are much much smaller than esmond_latency_localhost.
> 
> Another question: this perfsonar latency box is currently like this:
> root@lcgnetmon>
>  df -i /
> Filesystem            Inodes   IUsed   IFree IUse% Mounted on
> /dev/mapper/vg_lcgnetmon-lv_root
>                     9478144 8108152 1369992   86% /
> 
> The perfsonar bandwidth box is:
> root@lcgnetmon02>
>  df -i /
> Filesystem             Inodes  IUsed    IFree IUse% Mounted on
> /dev/mapper/vg_bfc-lv_root
>                     14548992 193506 14355486    2% /
> 
> Does that kind of match other sites' latency (LOTS of inodes used) &
> bandwidth (FEW inodes used) perfsonar boxen?
> 
> Our latency box is pretty broken which may account for its pathology.
> Poor little blighter.