क्यों एक अनपेक्षित उपयोगकर्ता `सिंक` कमांड निष्पादित कर सकता है?

Question

वर्तमान में उबंटू लिनक्स पर, लेकिन मैंने अन्य ओएस पर भी इस पर ध्यान दिया। जाहिरा तौर पर कोई भी उपयोगकर्ता syncकमांड निष्पादित कर सकता है - लेकिन यह क्यों है? मैं केवल नुकसान देख सकता हूं: अनावश्यक डिस्क लिखने के कारण सिस्टम धीमा हो जाता है।

प्रत्येक उपयोगकर्ता क्यों निष्पादित कर सकता है sync?

Comments

इस विषय पर मेरा प्रश्न होगा: क्या उपयोगकर्ताओं को सिंक () का उपयोग करने से रोकने का कोई तरीका है?

— बोनसी स्कॉट

@ BonsiScott ज़रूर, आप निष्पादन योग्य से अनुमति बिट्स को हटा सकते हैं। लेकिन मुझे नहीं पता कि जब आप ऐसा करेंगे तो कुछ टूट जाएगा।

— जिप्सी

न केवल कोई भी उपयोगकर्ता सिंक चला सकता है, आपको एक खाते की भी आवश्यकता नहीं है। खाता 'सिंक' /bin/syncइसके शेल के रूप में चलता है , इसलिए आप लॉग इन किए बिना सिंक कर सकते हैं।

— camh

वह किसके लिए उपयोगी है? BTW उस बॉक्स पर सिंक खाते पर कोई पासवर्ड नहीं है जो मैं वर्तमान में काम कर रहा हूं, इसलिए यह काम नहीं करेगा।

— जिप्पी

यह उत्पादन प्रणालियों के लिए प्रतीक्षा- syncकाल (जैसे HP-Unix) के बीच प्रतीक्षा-अवधि को कम करने के लिए अनुशंसित है । इसका कारण यह है कि अनावश्यक प्रतीक्षा से बचने के लिए एक साथ सभी डिस्क पर लिखे गए उत्कृष्ट लेखों के द्रव्यमान के कारण।

— निल्स

Answer 1

एक अनपेक्षित उपयोगकर्ता के लिए सिस्टम को धीमा करने के लिए बहुत सारे तरीके हैं और सिंक चलाना अधिक कुशल होने से बहुत दूर है। दूसरी ओर, डिस्क के लिए फ़ाइल सिस्टम डेटा का होना काफी वैध अनुरोध है, ताकि उपयोगकर्ताओं (और इस प्रकार उनकी प्रक्रिया) को यह करने के लिए मना किया जाए कि यह अत्यधिक होगा।

किसी भी मामले में, मैं आपके "अनावश्यक डिस्क लिखता हूं" कथन के बारे में असहमत हूं। ये लिखना निश्चित रूप से आवश्यक है और किसी भी समय छोटी अवधि के बाद स्वचालित रूप से हो जाएगा।

यहां तक ​​कि कोई गारंटी नहीं है कि सिंक कॉल इसके कार्यान्वयन के आधार पर विशेष रूप से कुछ भी करेगा। कॉलिंग सिंक, जैसा कि POSIX मानक परिभाषित करता है , केवल OS के लिए "फाइल सिस्टम कैश" को फ्लश करने के लिए एक "सुझाव" है, यह जरूरी नहीं कि फ्लश को तुरंत होने के लिए मजबूर किया जाए। अधिक सटीक रूप से, कॉल OS को कैश फ्लश शेड्यूल करने के लिए कहते हैं, लेकिन इसकी कोई गारंटी नहीं है कि यह पहले से ही निर्धारित समय से पहले होगा, हालांकि लिनक्स कार्यान्वयन इसके लौटने से पहले होने की प्रतीक्षा करता है।

इसके अलावा, एक पंक्ति में कई बार सिंक को कॉल करने से सिस्टम धीमा नहीं होगा, क्योंकि एक बार कैश फ्लश हो जाने के बाद, यदि कोई प्रक्रिया सक्रिय रूप से फाइलों को लिख नहीं रही है तो कैश खाली है इसलिए सिंक एक सेशन नहीं है।

क्या आप वास्तव में उपयोगकर्ताओं को अपने सिस्टम पर सिंक चलाने से रोकने के लिए चाहते हैं, तो आप बस ये कमांड चला सकते हैं:

mv /bin/sync /bin/.sync
ln /bin/true /bin/sync

यह काफी हद तक उपयोगकर्ताओं द्वारा किसी का ध्यान नहीं जाएगा और लोगों के अलावा कोई नकारात्मक प्रभाव नहीं है कि बस सिंक चलाएं, फिर भंडारण उपकरणों (जैसे: यूएसबी थंबड्राइव) को अनमाउंट किए बिना हटा दें, लेकिन ये उपयोगकर्ता वैसे भी पहले से ही मूर्खतापूर्ण कार्य कर रहे थे।

ध्यान दें कि मैं / bin / true के साथ पिछले / बिन / सिंक लिंक की सिफारिश नहीं करूंगा। syncकुछ मामलों में निश्चित रूप से उपयोगी है। उदाहरण के लिए यदि आप एक क्रूर शटडाउन (बिजली की कमी, सिस्टम आतंक, ...) से डरते हैं, तो शीघ्र ही हो सकता है, जो फ़ाइल सिस्टम सामग्री को संरक्षित करने में मदद करेगा। इसे मैं एक वैध अनुरोध कहता हूं।

Comments

@jippie सभी syncद्विआधारी करता है कहते हैं sync()समारोह है, तो (जैसे Bonsi स्कॉट ने कहा) आप वास्तव में क्या कह रहे हैं क्यों गिरी आम उपयोगकर्ताओं को कॉल करने देता हैsync()

— माइकल Mrozek

@ जिप्पी मुझे लगता है कि आप इस बिंदु को याद कर रहे हैं। सभी सिंक कभी भी (तुरंत) उन चीजों को डिस्क करने के लिए प्रतिबद्ध है जो वैसे भी प्रतिबद्ध होने वाले थे। जब मैं एक फ्लैश ड्राइव को हटाने के लिए जाता हूं, तो मैं यह सुनिश्चित करना चाहता हूं कि मैंने जो कुछ भी लिखा है वह वास्तव में लिखा गया है। और, जबकि umount को यह गारंटी दी जाती है, मैं आश्वस्त नहीं हूं, इसलिए मैं चाहता हूं कि (एक उपयोगकर्ता के रूप में) इससे पहले कि मैं यह सुनिश्चित करूं। बफ़र्स को डिस्क पर फ़्लश करने के लिए सिस्टम को मजबूर करने में कोई व्हाट व्हाट्सएवर नहीं है। सबसे खराब रूप से, कुछ चीजें एक सेकंड के लिए पिछड़ जाती हैं जबकि सिस्टम सक्रिय रूप से बफ़र्स को फ्लश करता है। उपयोगकर्ताओं को इस फ़ंक्शन को अस्वीकार करने में खतरा होगा।

— हत्यारे डेस

@killermist: सिंक मजबूर नहीं कर रहा है, बस सुझाव दे रहा है। डिस्क के लिए कुछ भी फ्लश किए बिना सिंक एक सफलता से बाहर निकलने की स्थिति के साथ वापस आ सकता है, डिस्क का उल्लेख नहीं करने के लिए खुद को हुड के नीचे लिखने में भी देरी हो सकती है। जबकि मैं आम तौर पर राय साझा करता हूं विंडोज आवश्यक विशेषताओं को याद कर रहा है, एक सिंक कमांड मेरी चिंताओं में से कम से कम होगा।

— जॉलीग्रे

@killermist @jippie सही है। आपको बेहतर विश्वास करना चाहिए umount, जो कि, जो भी ओएस है, हमेशा बफ़र्स को फ्लश करता है (जब तक कि डिस्क नहीं गई है ...) इसके बजाय syncओएस के आधार पर इसे करने की गारंटी नहीं है। ध्यान दें कि लिनक्स syncफ्लश के प्रभावी होने की प्रतीक्षा करता है इसलिए उस पर भी भरोसा किया जा सकता है।

— jlliagre

linux.die.net/man/2/sync -> मानक विनिर्देश के अनुसार (उदाहरण के लिए, POSIX.1-2001), सिंक () लेखन को शेड्यूल करता है, लेकिन वास्तविक लेखन से पहले वापस आ सकता है। हालाँकि, संस्करण 1.3.20 के बाद से लिनक्स वास्तव में प्रतीक्षा करता है। (यह अभी भी डेटा अखंडता की गारंटी नहीं देता है: आधुनिक डिस्क में बड़े कैश हैं।)

— बोन्सी स्कॉट

Answer 2

syncसिस्टम को कोई नुकसान नहीं पहुंचा सकता। यह इसे धीमा कर सकता है, लेकिन डिस्क तक पहुंचने वाले कार्यक्रमों से अधिक नहीं। इसे प्रतिबंधित क्यों किया जाना चाहिए?

किसी भी उपयोगकर्ता को चलाने की अनुमति देने का एक अच्छा कारण है sync। यह आवश्यक है यदि सिस्टम क्रैश हो जाता है या पावर खो देता है तो भी कुछ ऑपरेशन किए जाने चाहिए। उदाहरण के लिए, एक मेल ट्रांसफर एजेंट पर विचार करें जो एक ईमेल प्राप्त करता है। एक बार जब उसने ईमेल को स्पूल में लिखा है, तो वह कॉल करता है sync, और उसके बाद ही यह भेजने वाली मशीन को जवाब देता है कि ईमेल प्राप्त हो गया है। यदि यह कॉल नहीं करता है sync, और रिसेप्शन अधिसूचना भेजने के बाद ही प्राप्त मशीन ने बिजली खो दी है, लेकिन फ़ाइल को डिस्क पर करने से पहले, तो ईमेल खो जाएगा।

ऑपरेटिंग सिस्टम देरी डिस्क दक्षता के लिए लिखता है। उन्हें पता नहीं चल सकता है कि किसी एप्लिकेशन को वास्तव में लिखने के लिए क्या चाहिए। अनुप्रयोगों के तरीके के साथ, अब लिखने के लिए ऑपरेटिंग सिस्टम को बताने के लिए दिया जाता है तो sync(1)और sync(2)और fsync(2)।