परिस्थिति:
OmniOS r151018 (95eaa7e) पर चलने वाले सिंगल फ़ाइल सर्वर पर निम्नलिखित अजीब समस्या आई है, जो SMB से विंडोज और OS X मेहमानों के लिए फाइल परोस रहा है।
कुछ फ़ाइलों (.docx, .xlsx, कुछ छवियों) को सेव करके "Save as ..." के माध्यम से SMB शेयर पर डायलॉग विंडो लगभग 3 से 5 सेकंड के अंतराल में परिणामित होती है, जहां एप्लिकेशन बिल्कुल भी जवाब नहीं देता है। फ़ाइल सामान्य रूप से सहेजी जाती है।
समस्या सर्वर पर कुछ भी किए बिना "ओवर नाइट" हुई, लेकिन सटीक तारीख को इंगित करना मुश्किल है, क्योंकि उपयोगकर्ता की शिकायतें केवल पहली घटना के बाद कुछ समय में आई थीं। सर्वर के रिबूट के बाद, मिरर किए गए रूट पूल का एक vdev अनुपलब्ध था, लेकिन निकट निरीक्षण में डिवाइस पर कोई दोष नहीं मिला और इसे पूल में रीटेट किया गया। समस्या अभी भी बनी हुई है।
कुछ अवलोकन:
- यह सभी विंडोज 7 क्लाइंट्स पर होता है
- यह सभी फ़ाइल आकारों के लिए होता है
- यह इस मशीन के सभी शेयरों पर होता है, बिना अनुमति के
- यह अन्य सर्वर से iSCSI पर होस्ट पर आयात किए गए तेज़ संग्रहण के लिए होता है
- GBit ईथरनेट पर सामान्य कॉपी स्पीड 110 एमबी / सेकंड है
- डेटा और रूट पूल ठीक लग रहे हैं
- यह अन्य फ़ाइल सर्वरों पर नहीं होता है
- ऐसा नहीं होता है जब फ़ाइल स्थानीय रूप से सहेजी जाती है, तो एक्सप्लोरर के माध्यम से कॉपी की जाती है
- यह ओएस एक्स पर नहीं होता है (केवल ओपनऑफिस के साथ इसका परीक्षण कर सकता है)
dmesg
NOTICE: bge0: interrupt: flags 0x0 - not updated?
विभिन्न मूल्यों के साथ कई मायने रखता है , लेकिन यह पहले भी मामला था और कोई नुकसान नहीं हुआ
आगे के विचार / योजना:
जैसा कि कोई स्पष्ट त्रुटि संदेश नहीं मिला है, मुझे कारण की खोज के लिए कुछ परीक्षण और त्रुटि करने की आवश्यकता हो सकती है। कुछ चीजें जिन पर मैं विचार करूंगा ( परिणाम इटैलिक में हैं ):
- ब्रॉडकॉम नेटवर्क कार्ड को इंटेल कार्ड से बदलें => कोई फर्क नहीं पड़ा
- रूट पूल को SATA SSDs के साथ बदलें (वर्तमान में SLC मेमोरी USB स्टिक जो 3 साल से अधिक के लिए ठीक काम करता है) => मुझे फर्क नहीं पड़ा
- बीच में नेटवर्क की जाँच करें (हार्डवेयर, सर्वर से सीधे कनेक्शन द्वारा)
- वायरशर्क के साथ ट्रैफ़िक पर कब्जा: यदि आपको नहीं पता कि आप वास्तव में क्या देख रहे हैं
- पिछले ओमनीओस बूट वातावरण / संस्करण को वापस करने के लिए सॉफ़्टवेयर संघर्षों को नियंत्रित करने के लिए => कोई फर्क नहीं पड़ा
- बग्स को हटाने के लिए Windows / Office अपडेट्स रोल करें
:
स्नैपशॉट से फ़ाइल नाम में (कोलन) फ़ाइलों को निकालें , txgsync द्वारा सुझाव reddit धागे पर ewwhite द्वारा बनाई गई => कोई फर्क नहीं पड़ामैंने कुछ इसी तरह से देखा है जब विंडोज "पिछले संस्करणों" की सुविधा स्वचालित स्नैपशॉट के साथ सक्षम होती है जिसमें ":" वर्ण शामिल होता है। बस इसके साथ हवा में शूटिंग, लेकिन विंडोज फ़ाइल नामों में ":" चरित्र की अनुमति नहीं है।
फ़ाइल अभिगम की निगरानी: जैसा कि शोडांशोक द्वारा सुझाया गया है, मैंने फ़ाइल अभिगम की निगरानी के लिए इस लिपि का उपयोग किया
DTrace
और किया । मैंने इसका उपयोग अल्ट्रेड ओपन फाइल को सेव करते समय, असंबंधित आउटपुट और व्यक्तिगत जानकारी को हटा दिया, और परिणाम तीन फाइलों के आसपास होता है: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
किसी अन्य सर्वर पर समान प्रक्रिया जहां समस्या उत्पन्न नहीं होती है, एक समान परिणाम देता है:
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
मैंने
walltimestamp
स्क्रिप्ट में टाइमस्टैम्प ( ) भी जोड़ा , लेकिन दोनों ही मामलों में सभी फ़ाइल संचालन एक ही सेकंड में होते हैं। => कोई फर्क नहीं पड़ा- पूल विखंडन या डिस्क दोषपूर्ण हैं या नहीं, यह जांचने के लिए किसी अन्य होस्ट पर आयात डिस्क = कोई फर्क नहीं पड़ा
- केबलिंग, मेनबोर्ड आदि को नियंत्रित करने के लिए डेटा और रूट पूल को समान मशीन पर ले जाएं => समस्या बनी रहती है, इसलिए या तो रूट पूल (सॉफ़्टवेयर) या एक विशिष्ट हार्डवेयर होना चाहिए जो सॉफ़्टवेयर के साथ असंगत है (या अचानक असंगत हो गया था। ..)
क्या आप कुछ और सुझा सकते हैं जो इस व्यवहार का कारण हो सकता है? या आपको भी कुछ ऐसा ही अनुभव हुआ? क्योंकि मुझे ऑनलाइन कुछ भी उपयोगी नहीं मिला, मुझे संदेह है कि यह या तो एक अजीब हार्डवेयर समस्या है (क्योंकि यह एक मशीन तक सीमित है) या विंडोज / कार्यालय के साथ एक समस्या है।