আমি জানি হার্ড লিঙ্কগুলি কী, তবে কেন আমি সেগুলি ব্যবহার করব? হার্ড লিঙ্কটির ইউটিলিটি কী?
আমি জানি হার্ড লিঙ্কগুলি কী, তবে কেন আমি সেগুলি ব্যবহার করব? হার্ড লিঙ্কটির ইউটিলিটি কী?
উত্তর:
হার্ড লিঙ্কগুলির প্রধান সুবিধাটি হ'ল নরম লিঙ্কগুলির সাথে তুলনা করে কোনও আকার বা গতির জরিমানা নেই। সফট লিঙ্কগুলি স্বাভাবিক ফাইল অ্যাক্সেসের শীর্ষে ইন্ডিয়ারেশনের একটি অতিরিক্ত স্তর; আপনি ফাইলটি খোলার সময় কার্নেলটিকে লিঙ্কটি অবলম্বন করতে হবে এবং এতে খুব কম সময় লাগে। লিঙ্কটির পাঠ্য ধরে রাখতে এই লিঙ্কটি ডিস্কে অল্প পরিমাণে জায়গাও নেয়। এই জরিমানা হার্ড লিঙ্কগুলির সাথে বিদ্যমান নেই কারণ এগুলি ফাইল সিস্টেমের খুব কাঠামোর মধ্যে অন্তর্নির্মিত।
আমি এটি দেখতে সবচেয়ে ভাল উপায়টি হ'ল:
$ ls -id .
1069765 ./
$ mkdir tmp ; cd tmp
$ ls -id ..
1069765 ../
-iবিকল্পে lsএটা আপনাকে দিতে তোলে inode সংখ্যা ফাইলের। যে সিস্টেমে আমি উপরের উদাহরণটি প্রস্তুত করেছি, সেখানে আমি ইনডোড নম্বর 1069765 সহ একটি ডিরেক্টরিতে এসেছি, তবে নির্দিষ্ট মানটি কোনও ব্যাপার নয়। এটি কেবল একটি অনন্য মূল্য যা কোনও নির্দিষ্ট ফাইল / ডিরেক্টরি চিহ্নিত করে।
এটি যা বলে তা হ'ল আমরা যখন একটি উপ-ডিরেক্টরিতে যাই এবং নামক একটি ভিন্ন ফাইল সিস্টেম এন্ট্রি ..দেখি তখন এর একই ইনোড নম্বর থাকে যা আমরা আগে পেয়েছিলাম। ..এমএস-ডস এবং উইন্ডোজের সাথে শেলটি আপনার জন্য ব্যাখ্যা করার কারণে এটি ঘটছে না । ইউনিক্সে ফাইল সিস্টেমগুলি ..একটি আসল ডিরেক্টরি এন্ট্রি; এটি একটি পূর্ববর্তী ডিরেক্টরিতে নির্দেশ করে একটি লিঙ্ক।
হার্ড লিঙ্কগুলি হ'ল টেন্ডন যা ফাইল সিস্টেমের ডিরেক্টরিগুলি একসাথে বেঁধে দেয়। একসময়, ইউনিক্সের হার্ড লিঙ্ক ছিল না। এগুলি ইউনিক্সের মূল ফ্ল্যাট ফাইল সিস্টেমকে একটি শ্রেণিবিন্যাসের ফাইল সিস্টেমে পরিণত করার জন্য যুক্ত করা হয়েছিল ।
(এ সম্পর্কে আরও তথ্যের জন্য, দেখুন কেন '/' এর একটি '..' প্রবেশ রয়েছে? )
একই এক্সিকিউটেবল দ্বারা বিভিন্ন বিভিন্ন কমান্ড প্রয়োগ করার জন্য এটি ইউনিক্স সিস্টেমে কিছুটা সাধারণ। এটি আর লিনাক্সের ক্ষেত্রে বলে মনে হয় না, তবে আমি অতীতে যে সিস্টেমে ব্যবহার করেছি cp, mvএবং rmসমস্ত একই কার্যকর ছিল exec আপনি যদি এটির বিষয়ে চিন্তা করেন তবে তা বোধগম্য হয়: আপনি যখন কোনও ফাইলকে ভলিউমের মধ্যে সরিয়ে ফেলেন, তখন এটি কার্যকরভাবে একটি অনুলিপি হ'ল অপসারণের ফলে, mvইতিমধ্যে অন্য দুটি কমান্ডের কার্যকারিতা প্রয়োগ করতে হয়েছিল। এক্সিকিউটেবল কোন অপারেশনটি সরবরাহ করতে পারে তা নির্ধারণ করতে পারে কারণ এটি যে নামটি দিয়েছিল তার নামটি পাস হয়ে যায়।
আরেকটি উদাহরণ, এম্বেডেড Linuxes সাধারণ হয় busybox , একটি একক এক্সিকিউটেবল যে প্রয়োগ ডজন কম্যান্ডের।
আমার উল্লেখ করা উচিত যে বেশিরভাগ ফাইল সিস্টেমে ব্যবহারকারীদের ডিরেক্টরিতে হার্ড লিঙ্ক তৈরি করার অনুমতি দেওয়া হয় না। .এবং ..এন্ট্রি স্বয়ংক্রিয়ভাবে ফাইলসিস্টেম কোড, যা সাধারণত কার্নেল অংশ দ্বারা পরিচালিত হয়। বিধিনিষেধটি বিদ্যমান কারণ আপনি কীভাবে ডিরেক্টরি হার্ড লিঙ্কগুলি তৈরি এবং ব্যবহার করেন সে সম্পর্কে সতর্ক না হলে যদি গুরুতর ফাইল সিস্টেমের সমস্যা দেখা দেওয়া সম্ভব হয়। এটি নরম লিঙ্কগুলির বিদ্যমান অনেক কারণগুলির মধ্যে একটি; তারা একই ঝুঁকি বহন করে না।
হার্ডলিঙ্কগুলির একটির ব্যবহার যা অত্যন্ত উপযোগী তা হ'ল আরএসসিএন এর সাথে মিলিত বর্ধিত ব্যাকআপগুলি। এটি প্রচুর জায়গা সাশ্রয় করে এবং পুনরুদ্ধারের প্রক্রিয়াটিকে সত্যই সহজ করে তোলে। আমি আমার সার্ভারগুলিতে ব্যাকআপের জন্য সেই পদ্ধতিটি ব্যবহার করি।
এই ব্যাখ্যাটি পড়তে কিছুটা সময় নিন ।
সেই উইকিপিডিয়া পৃষ্ঠাটি পড়ার পরে যদি আপনার প্রশ্নটি হয় "আমি তাদের কেন কখনও ব্যবহার করব" তাহলে আপনি বুঝতে পারবেন না যে হার্ড লিঙ্কগুলি কী।
একটি লিঙ্ক একটি ডিরেক্টরি এন্ট্রি যা ডিস্কে থাকা ব্লকগুলিকে নির্দেশ করে। অন্য কথায় আপনার সিস্টেমে প্রতিটি ফাইলের কমপক্ষে একটি লিঙ্ক থাকে। আপনি যখন rmফাইল করেন তখন আসল সিস্টেম কল হয় unlink()। এটি ডিরেক্টরি এন্ট্রি সরিয়ে দেয়। ডিস্কে থাকা ব্লকগুলি পরিবর্তন হয়নি তবে লিঙ্কটি চলে গেছে, সুতরাং ফাইলটি ডিরেক্টরি তালিকা থেকে চলে গেছে।
আপনি ব্যক্তিগতভাবে কখনও হার্ড লিঙ্কগুলি ব্যবহার নাও করতে পারেন তবে সেগুলি আপনার সিস্টেমে রয়েছে। উদাহরণ স্বরূপ:
$ ls -li /bin | grep 53119771
53119771 -rwxr-xr-x 3 root root 26292 2010-08-18 10:15 bunzip2
53119771 -rwxr-xr-x 3 root root 26292 2010-08-18 10:15 bzcat
53119771 -rwxr-xr-x 3 root root 26292 2010-08-18 10:15 bzip2
আপনি যে দেখতে পারেন bunzip2, bzcatএবং bzipসব একই inode ব্যবহার করুন। সংক্ষেপে, এটি তিনটি নামের একটি ফাইল। আপনার কাছে ফাইলটির তিনটি অনুলিপি থাকতে পারে তবে কেন? এটি কেবল অযথা ডিস্কের স্থান ব্যবহার করবে।
/bin, আমার ধারণা এটি বিভ্রান্তির অন্যতম উত্স। কেন কখনও কখনও এক্সিকিউটেবলগুলিকে সিমলিংক করা হত এবং কখনও কখনও - হার্ডলিঙ্কযুক্ত?
ব্যবহারের সংখ্যা আছে। আমি ফাইল-ভিত্তিক লক তৈরি করতে এগুলি ব্যবহার করি। লিঙ্ক (2) সিস্টেম কলটি বেশিরভাগ অন্যান্য সিস্টেম কলের মতো নয়, পারমাণবিক।
আর ব্যবহার হ'ল আরএসএন্যাপশটের মধ্যে, যেখানে ডিস্ক জায়গার পরিমাণ হ্রাস করতে হার্ড-লিঙ্কগুলি ব্যবহার করে ব্যাকআপগুলি সময়ের সাথে নেওয়া হয়। যদি কোনও ফাইল পরিবর্তিত না হয়, তবে ফাইলটি ফাইলের পুরানো দৃষ্টান্তগুলির সাথে হার্ড-লিঙ্কযুক্ত, যে ফাইলগুলি পরিবর্তিত হয়েছে সেগুলি নতুনভাবে অনুলিপি করা হয়।
আমি সেগুলি সার্ভারে কনফিগারেশন ফাইলগুলি অদলবদল করতেও ব্যবহার করি: rm file.cfg && ln ~/tmp/file.cfg file.cfgতারপরে ~ / tmp / * ফাইলগুলি নিরাপদে মোছা যায়।
lnএবং rmপরিবর্তে শুধু একটি mv?
ইতিমধ্যে উপস্থিত বেশ কয়েকটি ভাল আলোচনায় যোগ করতে ...
(inode, name)জোড়া মানে hardlinks (থাকার ফাইলসিস্টেম মধ্যে কোন অতিরিক্ত খরচ নেই ভাল, যতদিন আমরা চেয়ে ডিরেক্টরি থেকে hardlinke নামঞ্জুর করার (অন্যান্য দ্বারা চক্র প্রতিরোধ হিসাবে .এবং ..(এটি কি অন্য কারও কাছে লিস্পের মতো অনুভব করা শুরু করে?)))সুতরাং আমরা তাদের বিনামূল্যে পান।
আমার পক্ষে সম্ভবত হার্ড লিঙ্কগুলির একটি দুর্যোগ দৃশ্যটি আবরণ করা উচিত । একটি হার্ড লিঙ্কটি অন্য কোনও নাম এবং / অথবা মূল লিঙ্কযুক্ত ফাইলের অস্তিত্বের মধ্যে অন্য কোনও পৃথক অবস্থানের সাথে একই ফাইল হবে । ফাইলটিকে "আসল" হিসাবে ভাবা এমনকি সঠিক নয়: উভয়ই নিজের ডাইরেক্টরিতে ডিরেক্টরি এন্ট্রি এবং উভয় (বা আরও) সমস্ত সমান সমবয়সী। দীর্ঘস্থায়ী ফাইলগুলির জন্য, এটি একটি আশীর্বাদ হতে পারে তবে জোড়ার কোনও একটি যদি মুছে ফেলা হয় এবং তারপরে একই নাম এবং বিষয়বস্তু দিয়ে তৈরি করা হয় তবে ফাইলগুলি পৃথক হবে will
মনে করুন আপনি একটি /foo/myfileলিঙ্ক যুক্ত করে তৈরি করেছেন /repo/myfile। উভয়ই একই ফাইল ডেটারের পয়েন্টার; একটি পরিবর্তন, অন্য পরিবর্তন। তবে ধরুন এটি /repoএকটি গিট সংগ্রহস্থল রাখার জন্য ঘটেছে। যদি আপনি myfileএটিতে অন্তর্ভুক্ত না করে এমন একটি শাখা পরীক্ষা করেন তবে এটি /repo/myfileমুছে ফেলা হবে। এই মুহুর্তে, /foo/myfileএকটি সহজ অনুলিপিতে পরিণত হয় /repo/myfile, যেমনটি এই মুহুর্তে জুটির অন্যটি লিঙ্কযুক্ত ছিল। এমনকি আপনি যখন শাখাগুলির মধ্যে যে পরিবর্তনগুলি ফাইলের মধ্যে ফ্লিপ করেছেন তার মধ্যে লক্ষ্য করা সহজ নয়, তবে, আপনি যখন মূল শাখাটি চেকআউট করবেন তখন একটি নতুন ফাইল/repo/myfileগিট দ্বারা নির্মিত হয়। আপনি যদি মনোযোগ না দিয়ে থাকেন তবে আপনি অবাক হবেন যে কেন এখন দুটি ফাইলের আলাদা আলাদা বিষয়বস্তু রয়েছে, যদিও এটি আঁকানো সহজ, কারণ ফাইলগুলির মধ্যে হার্ড লিঙ্ক সম্পর্কের নাম সম্পর্কে কোনও ধারণা নেই has বিপরীতে একটি নরম লিঙ্ক, এই মোছা-তৈরি চক্রের মাধ্যমে বেঁচে থাকবে।
অন্যদিকে, হার্ড লিঙ্কগুলি ব্যবহার করে এমন সফ্টওয়্যারগুলি এ সম্পর্কে তীব্র সচেতন এবং গিট একটি প্রধান উদাহরণ। গিট প্রায় একই ফ্রি সিস্টেম সিস্টেমে একটি সংগ্রহস্থল ক্লোন করে, কারণ এটি ফাইলগুলি অনুলিপি না করে ডিফল্টরূপে হার্ড লিঙ্কগুলি ব্যবহার করে। গিটের জন্য হার্ড লিঙ্কটি একটি নিখুঁত ব্যবহারের কেস, কারণ এর অবজেক্ট এবং প্যাক ফাইলগুলি কখনই পরিবর্তন হয় না, তাই সংগ্রহস্থলের একটি ক্লোন কখনই অন্যটিকে সংশোধন করে না (গিট হার্ড লিঙ্ক পরিবর্তনকারী ফাইলগুলিতে না জানে), এবং ক্লোনগুলির কোনওটি হতে পারে কোনও সতর্কতা ছাড়াই মুছে ফেলা হয়েছে: কোনটি "আসল" এবং আসলে ফাইলগুলি অন্তর্ভুক্ত রয়েছে তা ট্র্যাক করার দরকার নেই : হার্ড লিঙ্কগুলির যে কোনও একটি সমান অংশীদার এবং সম্পূর্ণ ফাইল "অন্তর্ভুক্ত" থাকে। সফট লিঙ্কগুলি এখানে কাজ করবে না।
হার্ড লিঙ্কের আর একটি সুবিধা হ'ল ফাইলের সামগ্রীতে অ্যাক্সেস না ভেঙে যে কোনও লিঙ্ক সরানো যেতে পারে। নরম লিঙ্কগুলির সাথে, আসল ফাইলটি সরানো এর সাথে সমস্ত নরম লিঙ্কগুলিকে রেন্ডার করে।
মূল কথাটি হ'ল অনেক ব্যবহারের ক্ষেত্রে লিংক প্রকারটি সমানভাবে ভাল কাজ করে তবে কিছুতে একটি বা অন্য ধরণের সুবিধাজনক। দক্ষতা, এখানে অনেক উত্তরে উল্লিখিত, সম্ভবত আধুনিক মেশিন এবং ফাইলসিস্টেমগুলির সাথে খুব সামান্য উদ্বেগের বিষয়, যদি না আপনি কোনও পেনী এম্বেডড কন্ট্রোলারের একটি ফ্ল্যাশ চিপে ফাইলসাইমকে স্ক্যাভেঞ্জ না করেন। ক্রিয়ামূলক পার্থক্য বেশি গুরুত্বপূর্ণ, এবং সাধারণত ইঞ্জিনিয়ারিং সীমাবদ্ধতার এবং অন্তিম পছন্দ নির্দেশ:
এছাড়াও, আমার অবশ্যই উল্লেখ করতে হবে যে লাইব্রেরি কল যে কোনও ফাইল মুছে ফেলা unlink()একটি কারণে ডাকা হয়েছিল! প্রতিটি ডিরেক্টরি এন্ট্রি তার ইনোডের জন্য প্রাথমিকভাবে একক একক হার্ড লিঙ্ক।