CDR Troubles #1 - Disk Error

Frekuensi kejadian : 5, Tingkat kesulitan : 4

Sebenarnya masalah ini sama sekali tidak berhubungan dengan komponen radar sendiri, tetapi lebih pada workstation pengontrolnya. Workstation yang digunakan CDR merupakan media pertama yang berhubungan langsung dengan komponen-komponen radar (seperti transmitter, receiver, signal processor dan lain-lain) sebelum terhubung dengan server IRIS yang mengolah data radar selanjutnya. Workstation ini pada dasarnya adalah PC branded produksi Toshiba, dengan sistem operasi SunSolaris 5.7. Aku sendiri lebih sering menyebutnya dengan Server Toshiba.

Aplikasi pengontrol CDR (DPMain) juga terinstalasi pada server Toshiba, sehingga untuk mengontrol kerja dari CDR itu sendiri, operator harus menggunakan server ini sebagai medianya. Dan tentu saja, bila terjadi masalah dengan server ini, otomatis si 'harimau' Serpong akan ikutan nggak beres tingkahnya.

Server Toshiba awalnya juga berfungsi sebagai pemroses data selain untuk kontrol radar. Setelah CDR dimodifikasi akhir tahun 2008 lalu, seluruh urusan pengolahan data dipindahkan ke server IRIS. Namun, ada beberapa pengaturan yang tidak bisa diubah seluruhnya. Salah satunya adalah dalam hal pemrosesan data. Seharusnya cukup server IRIS yang mengolah data si CDR, namun dalam hal ini, server Toshiba ternyata tidak bisa di-set untuk 'meletakkan jabatannya' kepada si server IRIS. Oleh karena itu, walaupun pada akhirnya seluruh data diolah oleh server IRIS, si server Toshiba juga tetap menyimpan sebagian data RAW (dalam format Toshiba). Karena data RAW ini ukurannya sangat besar, sementara kapasitas harddisk server Toshiba sangat terbatas (jauh lebih kecil dibandingkan server IRIS), maka data RAW (di server Toshiba) harus dihapus secara berkala. Bila tidak, harddisk akan penuh, aplikasi kontrol radar bakalan ngadat, dan kalo sudah ngadat, otomatis CDR tidak akan bisa memproses data observasi, walaupun perangkat keras seperti transmitter dll tetap bekerja sebagaimana mestinya. Biasanya program kontrol akan memberi tanda 'Disk Error' apabila ruang yang digunakan pada harddisk sudah melebihi 90% dari total space yang ada.

 

Normalnya, file-file RAW ini akan dihapus secara otomatis dengan memanfaatkan shell script dan crontab yang dijalankan pada SunOS, namun karena crontabnya hanya berjalan sekali sehari, terkadang aku juga harus menghapusnya secara manual.

Untuk memeriksa sisa space pada tiap partisi sistem, aku biasa menggunakan perintah 'df -k' yang umum digunakan pada sistem berbasis UNIX.

 

Untuk mengetahui sisa space secara real pada sistem file root directory (UFS) bisa menggunakan perintah berikut :

df -F ufs -o i

Bila output dari kedua perintah tersebut root directory (/) dan /usr1 sudah menunjukkan angka yang melebihi 90%, maka harus dilakukan penghapusan pada beberapa file berikut :

1. RAW Files. Berada pada direktori /usr1/spf/DB/ONLINE. Setelah masuk, hapus seluruh data RAW pada sub direktori 01000000, 01000001, 01080000, 02000000, 02000001, 02060000, 03000000, 03000001 dan 03060000.
2. Mail file di /var/mail. Aku sempat nemu file mail yang besarnya lebih dari 5 MB, padahal fitur mailnya sendiri ga dipake.
   
3. Coredump files di /var/crash. Ini jg salah satu jenis file yang bikin penuh harddisk. Biasanya file ini dihasilkan kalo sistem lagi error atau crash.
   
4. Temporary file di /var/tmp. Biasanya aku pake perintah ini : 'find /var/tmp -mtime +3 -a -user xxx -a -type f -exec rm {} ;'. Tadinya maunya cuma file-file yang lebih dr 7 hari yg dihapus, tp supaya lebih aman mending yang di atas 3 hari sudah dihapus juga
5. Website files. Berada pada direktori /usr1/spf/WEB. Hapus semua data dalam sub direktori tr01, tr05, tr10, tv01, tv05 dan tv10.
   

Poin 1 aku pelajari dari orang JAMSTEC (thanks to Mori-san). Poin 2-3 cari sendiri di internet. Poin 4 aku pelajari sendiri setelah baca email dari engineer K-Weather (thanks to Iwao-san). Poin 5 murni hasil ngoprek-ngoprek server Toshiba beberapa hari yang lalu (thanks to myself LOL).

Kesimpulan : Masalah ini awalnya sempat bikin pusing karena aku belum tau penyelesaiannya (poin 2-4) dan respon dari pihak JAMSTEC juga rada lambat. Tapi setelah tau triknya, no problemo ... hehhe ...