কেন একটি অনিবদ্ধ ব্যবহারকারী `সিঙ্ক` কমান্ড কার্যকর করতে পারেন?


11

বর্তমানে উবুন্টু লিনাক্সে, তবে আমি এটি অন্যান্য ওএসেও লক্ষ্য করেছি। স্পষ্টত কোনও ব্যবহারকারী syncকমান্ডটি কার্যকর করতে পারে - তবে এটি কেন? আমি কেবল অসুবিধা দেখতে পাচ্ছি: অপ্রয়োজনীয় ডিস্কের কারণে সিস্টেমটি ধীর হয়ে যায়।

কেন প্রতিটি ব্যবহারকারী কার্যকর করতে পারেন sync?


1
এই বিষয়টিতে আমার প্রশ্নটি হবে: ব্যবহারকারীদের সিঙ্ক () ব্যবহার করা থেকে বিরত রাখার কি কোনও উপায় আছে?
বনসি স্কট

@ বনসিস্কট অবশ্যই, আপনি এক্সিকিউটেবল থেকে অনুমতি বিট অপসারণ করতে পারেন। তবে আমি জানি না আপনি যখন এমনটি করবেন তখন কিছু ভেঙে যাবে কিনা।
জিপ্পি

কেবল কোনও ব্যবহারকারীই সিঙ্ক চালাতে পারবেন না, আপনার কোনও অ্যাকাউন্টেরও দরকার নেই। অ্যাকাউন্ট 'সিঙ্ক' রান /bin/syncখোলের যেমন, তাই আপনি লগ ইন না করে সিঙ্ক করতে পারে।
camh

কি জন্য এটি দরকারী? বিটিডব্লিউ সিঙ্ক অ্যাকাউন্টে বর্তমানে যে বাক্সে আমি কাজ করছি তাতে কোনও পাসওয়ার্ড নেই, যাতে এটি কাজ করবে না।
জিপ্পি

উত্পাদন সিস্টেমগুলির জন্য- syncকলগুলির (যেমন এইচপি-ইউনিক্সে) মধ্যে অপেক্ষা-সময় কমিয়ে আনার জন্য সুপারিশ করা হয় । একসাথে ডিস্কে বকেয়া লেখাগুলির প্রচুর লেখার কারণে অপ্রয়োজনীয় প্রত্যাশাগুলি এড়ানোর কারণ।
নীল

উত্তর:


16

একটি অনিবদ্ধ ব্যবহারকারীকে সিস্টেমকে ধীর করার জন্য প্রচুর উপায় রয়েছে এবং সিঙ্ক চালানো আরও দক্ষ হওয়া থেকে অনেক দূরে। অন্যদিকে, ডিস্কে প্রতিশ্রুতিবদ্ধ ফাইল সিস্টেমের ডেটা থাকা বেশ বৈধ অনুরোধ তাই ব্যবহারকারীদের (এবং এইভাবে তাদের প্রক্রিয়াগুলি) এটি করতে নিষেধ করা অত্যধিক হবে।

যাই হোক না কেন, আপনার "অপ্রয়োজনীয় ডিস্ক লেখার" বিবৃতি সম্পর্কে আমি একমত নই। এই লেখাগুলি অবশ্যই প্রয়োজনীয় এবং যাইহোক যাইহোক অল্প সময়ের পরে স্বয়ংক্রিয়ভাবে ঘটবে।

এমনকি সিঙ্ক কলটি এর প্রয়োগের উপর নির্ভর করে কিছু বিশেষ কিছু করবে এমন কোনও গ্যারান্টি নেই। কলিং সিঙ্ক, যেমন পসিক্স স্ট্যান্ডার্ড সংজ্ঞায়িত করেছে, ওএসের ফাইল সিস্টেম ক্যাশেগুলি ফ্লাশ করার জন্য কেবল একটি "পরামর্শ", এটি তাত্ক্ষণিকভাবে ফ্লাশগুলি ঘটতে বাধ্য করে না। আরও স্পষ্টভাবে, কলগুলি ওএসকে ক্যাশে ফ্লাশের সময় নির্ধারণের জন্য বলেছে তবে ইতিমধ্যে নির্ধারিত সময়ের আগে এটি হওয়ার কোনও গ্যারান্টি নেই যদিও লিনাক্স বাস্তবায়ন এটি ফিরে আসার আগে অপেক্ষা করে না।

তদুপরি, একাধিকবার সিঙ্ককে একাধিকবার কল করা সিস্টেমগুলিকে এত ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে যান

আপনি যদি সত্যই আপনার সিস্টেমে সিঙ্ক চালানোর জন্য ব্যবহারকারীদের আটকাতে চান তবে আপনি কেবল এই আদেশগুলি চালাতে পারেন:

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

এটি বেশিরভাগ ক্ষেত্রে ব্যবহারকারীদের নজরে আসতে পারে এবং কেবলমাত্র সিঙ্ক চালায় এমন লোকেরা ছাড়া স্টোরেজ ডিভাইসগুলি (যেমন: ইউএসবি থাম্বড্রাইভ) আনমাউন্ট না করে মুছে ফেলা ছাড়া এটির কোনও নেতিবাচক প্রভাব নেই, তবে এই ব্যবহারকারীরা ইতিমধ্যে যেভাবেই বোকামি আচরণ করছে।

মনে রাখবেন যে আমি পূর্ববর্তী / বিন / সিঙ্ক লিঙ্কটি / বিন / সত্যের সাথে সুপারিশ করব না। syncকিছু ক্ষেত্রে অবশ্যই দরকারী। উদাহরণস্বরূপ, যদি আপনি ভয় পান যে একটি নির্মম শাটডাউন (বিদ্যুতের ঘাটতি, সিস্টেম আতঙ্ক, ...) খুব শীঘ্রই ঘটতে পারে তবে এটি ফাইল সিস্টেমের সামগ্রী সংরক্ষণে সহায়তা করবে। এটাকেই আমি বৈধ অনুরোধ বলি।


2
@ জিপ্পি সমস্ত syncবাইনারি করে sync()ফাংশনটি কল করা হয় , সুতরাং (বনস স্কট যেমন বলেছিল) আপনি সত্যিই যা জিজ্ঞাসা করছেন তা কেন sync()
কর্নাল অবাঞ্ছিত

2
@ জিপ্পি আমি মনে করি আপনি পয়েন্টটি মিস করছেন। সমস্ত সিঙ্ক যে কোনও ক্ষেত্রেই সংঘটিত হতে হবে (তত্ক্ষণাত্) ডিস্ক জিনিসগুলিতে প্রতিশ্রুতিবদ্ধ। আমি যখন কোনও ফ্ল্যাশ ড্রাইভ সরাতে যাই, আমি নিশ্চিত করতে চাই যে আমি এতে যা লিখেছি তা আসলেই লিখিত হয়েছে। এবং যখন অ্যামাউন্টটি এটির গ্যারান্টি দেবে বলে মনে করা হচ্ছে, তখনও আমি আশ্বাসপ্রাপ্ত নই, সুতরাং আমি এটি ব্যবহার করার আগে (ব্যবহারকারী হিসাবে) নিশ্চিত হওয়া চাই। সিস্টেমে বাফারকে ডিস্কে ফ্লাশ করতে বাধ্য করার মতো কোনও ক্ষয়ক্ষতি নেই। সবচেয়ে খারাপ সময়ে, কিছু জিনিস সেকেন্ডের জন্য পিছিয়ে থাকে যখন সিস্টেমটি সক্রিয়ভাবে বাফারগুলিকে ফ্লাশ করে। বিপত্তিটি ব্যবহারকারীদের এই ক্রিয়াকলাপটিকে অস্বীকার করার মধ্যে রয়েছে।
হত্যাকারী 1

2
@ কিলারমিস্ট: সিঙ্কটি জোর করছে না, কেবল পরামর্শ দিচ্ছে। সিঙ্কটি ডিস্কে কোনও কিছু না ফেলেই সাফল্যের প্রস্থান স্থিতির সাথে ফিরে আসতে পারে, ডিস্কের উল্লেখ না করা নিজেই হুডের নিচে লেখায় বিলম্ব করতে পারে। আমি সাধারণভাবে মতামতটি জানাতে গিয়ে উইন্ডোজ প্রয়োজনীয় বৈশিষ্ট্যগুলি হারিয়েছে, তবে একটি সিঙ্ক কমান্ডটি আমার উদ্বেগের মধ্যে সবচেয়ে কম হবে।
jlliagre

3
@ কিলারমিস্ট @ জিপ্পি সঠিক। আপনার আরও ভাল বিশ্বাস করা উচিত umount, যা ওএস যাই হোক না কেন, সর্বদা বাফারগুলিকে ফ্লাশ করে (যতক্ষণ না ডিস্ক না চলে ...) syncওএসের উপর নির্ভর করে এটি করার নিশ্চয়তা দেয় না to নোট করুন যে লিনাক্স syncফ্লাশ কার্যকর হওয়ার জন্য অপেক্ষা করে তাই বিশ্বাস করা যায়।
jlliagre

1
linux.die.net/man/2/sync -> স্ট্যান্ডার্ড স্পেসিফিকেশন (উদাহরণস্বরূপ, POSIX.1-2-2001) অনুসারে, সিঙ্ক () লেখার সময়সূচী দেয়, তবে আসল লেখা শেষ হওয়ার আগে ফিরে আসতে পারে। যাইহোক, সংস্করণ 1.3.20 যেহেতু লিনাক্স আসলে অপেক্ষা করে। (এটি এখনও ডেটা অখণ্ডতার গ্যারান্টি দেয় না: আধুনিক ডিস্কগুলিতে বড় ক্যাশে রয়েছে))
বনসী স্কট

5

syncসিস্টেমের কোনও ক্ষতি করতে পারে না। এটি এটি ধীর করতে পারে, তবে ডিস্ক অ্যাক্সেস করে এমন প্রোগ্রামগুলি চালানোর চেয়ে বেশি নয়। কেন এটি সীমাবদ্ধ করা উচিত?

যে কোনও ব্যবহারকারীর চালনার অনুমতি দেওয়ার পক্ষে যুক্তিসঙ্গত কারণ রয়েছে sync। সিস্টেমটি ক্র্যাশ হয়ে গেলে বা শক্তি হারিয়ে ফেললেও কিছু ক্রিয়াকলাপ অবশ্যই সম্পাদন করতে হবে এটি প্রয়োজনীয়। উদাহরণস্বরূপ, কোনও মেল স্থানান্তর এজেন্ট বিবেচনা করুন যা কোনও ইমেল গ্রহণ করে। এটি স্পুলে ইমেলযুক্ত ফাইলটি একবার লিখে ফেললে এটি কল করে syncএবং তারপরেই ইমেলটি প্রেরণ করা মেশিনকে এটি ইমেলটি পেয়েছে বলে জানিয়ে দেয়। যদি এটি কল না করে sync, এবং গ্রহণের মেশিন কেবল অভ্যর্থনা বিজ্ঞপ্তি প্রেরণের পরে কিন্তু ডিস্কে ফাইলটি প্রতিশ্রুতি দেওয়ার আগে শক্তি হারিয়ে ফেলে, তবে ইমেলটি হারিয়ে যাবে।

অপারেটিং সিস্টেমের বিলম্ব ডিস্ক দক্ষতার জন্য লেখেন। কখনই কোনও অ্যাপ্লিকেশনটির লেখার প্রয়োজন হয় তা তারা জানতে পারে না। সুতরাং অ্যাপ্লিকেশনগুলিকে অপারেটিং সিস্টেমকে এখন লিখতে বলার একটি উপায় দেওয়া হয়েছে, সহ sync(1)এবং sync(2)এবং fsync(2)

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.