Situasi:
Masalah aneh berikut telah terjadi pada server file tunggal yang menjalankan OmniOS r151018 (95eaa7e) yang melayani file melalui SMB ke Windows dan tamu OS X.
Menyimpan file tertentu (.docx, .xlsx, beberapa gambar) melalui jendela dialog "Simpan sebagai ..." pada pembagian SMB menghasilkan jeda sekitar 3 hingga 5 detik, di mana aplikasi tidak merespons sama sekali, setelah itu aplikasi file disimpan secara normal.
Masalahnya memang terjadi "semalam", tanpa melakukan apa pun ke server, tetapi sulit untuk menentukan tanggal yang tepat, karena keluhan pengguna hanya muncul beberapa saat setelah kejadian pertama. Setelah reboot server, satu vdev dari pool root mirrored tidak tersedia, tetapi pemeriksaan lebih dekat tidak menemukan kesalahan pada perangkat dan disambungkan kembali ke pool. Masalahnya masih berlanjut.
Beberapa pengamatan:
- Ini terjadi pada semua klien Windows 7
- Itu terjadi untuk semua ukuran file
- Itu terjadi pada semua bagian mesin ini, terlepas dari izin
- Ini terjadi untuk penyimpanan yang lebih cepat yang diimpor pada host melalui iSCSI dari server lain
- Kecepatan penyalinan normal adalah 110 MB / detik di atas GBit Ethernet
- Data dan root pool tampaknya baik-baik saja
- Itu tidak terjadi pada server file lain
- Itu tidak terjadi ketika file disimpan secara lokal, kemudian disalin melalui explorer
- Itu tidak terjadi pada OS X (hanya bisa mengujinya dengan OpenOffice)
dmesg
menunjukkan beberapa halNOTICE: bge0: interrupt: flags 0x0 - not updated?
dengan berbagai nilai, tetapi ini juga terjadi sebelumnya dan tidak membahayakan
Ide / rencana selanjutnya:
Karena tidak ada pesan kesalahan yang jelas ditemukan, saya mungkin perlu melakukan beberapa percobaan mencari kesalahan. Beberapa hal yang akan saya pertimbangkan ( hasilnya dicetak miring ):
- Ganti kartu jaringan Broadcom dengan kartu Intel => tidak membuat perbedaan
- Ganti root pool dengan SATA SSD (saat ini memori USB stick SLC yang bekerja dengan baik selama lebih dari 3 tahun) => tidak membuat perbedaan
- Periksa jaringan di antaranya (perangkat keras, dengan koneksi langsung ke server)
- Tangkapan lalu lintas dengan WireShark: sulit jika Anda tidak tahu persis apa yang Anda cari
- Kembalikan ke lingkungan / versi boot OmniOS sebelumnya untuk mengesampingkan konflik perangkat lunak => tidak membuat perbedaan
- Kembalikan pembaruan Windows / Office untuk menyingkirkan bug
Hapus file dengan
:
(titik dua) dalam nama file dari snapshot, saran oleh txgsync pada utas reddit yang dibuat oleh ewwhite => tidak membuat perbedaanSaya telah melihat sesuatu yang mirip dengan ini ketika fitur "versi sebelumnya" Windows diaktifkan dengan snapshot otomatis yang menyertakan karakter ":". Hanya menembaki angin dengan ini, tetapi mungkin patut dilihat karena karakter ":" tidak diperbolehkan dalam nama file Windows.
Pemantauan akses file: seperti yang disarankan oleh shodanshok, saya menggunakan
DTrace
dan skrip ini untuk memonitor akses file. Saya menggunakannya saat menyimpan file terbuka yang sudah dibaca, menghapus output yang tidak terkait dan informasi pribadi, dan hasilnya berpusat di sekitar tiga file:CPU ID FUNCTION:NAME 1 18753 fop_open:entry Open: Workbook 0 18181 fop_create:return Create: temp_1 0 18753 fop_open:entry Open: temp_1 0 18753 fop_open:entry Open: Workbook 0 18753 fop_open:entry Open: Workbook 0 18753 fop_open:entry Open: temp_1 0 18888 fop_rename:entry Rename: Workbook -> temp_2 0 18888 fop_rename:entry Rename: temp_1 -> Workbook 0 18753 fop_open:entry Open: Workbook 0 18753 fop_open:entry Open: temp_2 0 18892 fop_remove:entry Remove: temp_2 0 18753 fop_open:entry Open: Workbook 0 18753 fop_open:entry Open: Workbook
Prosedur yang sama di server lain di mana masalah tidak terjadi menghasilkan hasil yang serupa:
CPU ID FUNCTION:NAME 1 25182 fop_create:return Create: temp_1 1 25750 fop_open:entry Open: temp_1 1 25750 fop_open:entry Open: Workbook 1 25750 fop_open:entry Open: temp_1 1 25750 fop_open:entry Open: Workbook 1 25750 fop_open:entry Open: temp_1 1 25889 fop_rename:entry Rename: Workbook -> temp_2 1 25889 fop_rename:entry Rename: temp_1 -> Workbook 1 25750 fop_open:entry Open: Workbook 1 25750 fop_open:entry Open: temp_2 1 25893 fop_remove:entry Remove: temp_2 1 25750 fop_open:entry Open: Workbook 1 25750 fop_open:entry Open: Workbook 1 25750 fop_open:entry Open: Workbook
Saya juga menambahkan cap waktu (
walltimestamp
) ke skrip, tetapi dalam kedua kasus semua operasi file berlangsung pada saat yang sama. => tidak membuat perbedaan- Impor disk pada host lain untuk memeriksa apakah pool fragmentasi atau disk rusak => tidak membuat perbedaan
- Pindahkan data dan kumpulan akar ke mesin yang identik untuk mengesampingkan pemasangan kabel, mainboard, dll. => Masalah tetap ada, jadi harus berupa kumpulan akar (perangkat lunak) atau perangkat keras tertentu yang tidak kompatibel dengan perangkat lunak (atau tiba-tiba menjadi tidak kompatibel. ..)
Bisakah Anda menyarankan hal lain yang menjadi penyebab perilaku ini? Atau apakah Anda mengalami hal serupa? karena saya tidak dapat menemukan sesuatu yang membantu online, saya curiga itu adalah masalah perangkat keras yang aneh (karena terbatas pada satu mesin) atau masalah dengan Windows / Office.