কেন হার্ড লিঙ্কগুলি একই ফাইল সিস্টেমের মধ্যে বৈধ?


22

আমি এই পরিচয়টি মার্ক বেটসের কমান্ড লাইনে পড়ছি ।

প্রথম অধ্যায়ে তিনি উল্লেখ করেছিলেন যে হার্ড লিঙ্কগুলি ফাইল সিস্টেমকে ছড়িয়ে দিতে পারে না।

হার্ড লিঙ্কগুলি সম্পর্কে একটি গুরুত্বপূর্ণ বিষয় লক্ষণীয় হ'ল তারা কেবলমাত্র বর্তমান ফাইল সিস্টেমে কাজ করে। আপনি কোনও আলাদা ফাইল সিস্টেমে কোনও ফাইলের জন্য একটি হার্ড লিঙ্ক তৈরি করতে পারবেন না। এটি করতে আপনাকে প্রতীকী লিঙ্কগুলি ব্যবহার করতে হবে, বিভাগ 1.4.3।

আমি কেবল একটি ফাইল সিস্টেম জানি know মূল থেকে শুরু করে ( /)। এই বিবৃতিটি যে হার্ড লিঙ্কগুলি ফাইল সিস্টেমে বিস্তৃত হতে পারে তা আমার কাছে বোধগম্য নয়।

ইউনিক্স ফাইল সিস্টেমে উইকিপিডিয়া নিবন্ধটিও সহায়ক নয়।

উত্তর:


29

আশা করি আমি এর উত্তরটি এমনভাবে দিতে পারব যা আপনার জন্য অর্থবোধ করে। লিনাক্সে একটি ফাইল সিস্টেম সাধারণত একটি পার্টিশন দিয়ে তৈরি হয় যা বিভিন্ন উপায়ে ফর্ম্যাট করা হয় (আপনার পছন্দ পছন্দ করতে হবে!) যা আপনি নিজের ফাইলগুলিতে সঞ্চয় করেন। আপনার সিস্টেম ফাইলগুলি বা আপনার ব্যক্তিগত ফাইল হোন ... সেগুলি কোনও ফাইল সিস্টেমে সঞ্চিত রয়েছে। এই অংশটি আপনি বুঝতে পারছেন বলে মনে হচ্ছে।

তবে যদি আপনি আপনার হার্ড ড্রাইভকে একাধিক পার্টিশন (পার্টিশন ভাবেন অ্যাপল পাই টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো করে) ভাগ করে নিতে পারেন, বা একটি অতিরিক্ত হার্ড ড্রাইভ (সম্ভবত কোনও ইউএসবি স্টিক?) যুক্ত করেন তবে কী হবে? তর্কের খাতিরে, তাদের সমস্তগুলিতে পাশাপাশি তাদের ফাইল ফাইল রয়েছে।

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

image.jpg             image2.jpg
          \           /
           [your data]

এখানে, image.jpg, এবং image2.jpg উভয়ই আপনার ডেটাতে সরাসরি নির্দেশ করে। তারা দুজনই হার্ডলিঙ্ক। যাহোক...

image.jpg    <-----------  image2.jpg
           \ 
             [your data]

এই (অপরিশোধিত) উদাহরণে, ইমেজ 2.jpg আপনার ডেটার দিকে নির্দেশ করে না, এটি ইমেজ.জেপিজিকে নির্দেশ করে ... যা আপনার ডেটার লিঙ্ক to

প্রতীকী লিঙ্কগুলি ফাইল সিস্টেমের সীমানা জুড়ে কাজ করতে পারে (ধরে নিবেন যে ফাইল সিস্টেমটি সংযুক্ত এবং মাউন্ট করা হয়েছে, যেমন আপনার ইউএসবি স্টিকের মতো)। তবে একটি হার্ড লিঙ্ক পারে না। এটি আপনার অন্যান্য ফাইল সিস্টেমে কী আছে বা যেখানে আপনার ডেটা সঞ্চিত রয়েছে সে সম্পর্কে কিছুই জানে না।

আশা করি এটি আরও ভাল ধারণা তৈরি করতে সহায়তা করে।


ধন্যবাদ। আমি বুঝতে পারি না যে বিভিন্ন ফাইল-পার্টিশনগুলিকে "ফাইল সিস্টেম" বলা হয়।
অ্যান্টন পারস

1
পার্টিশনের মাধ্যমে আপনি যে কাজটি করতে পারেন তার মধ্যে একটি ফাইল সিস্টেম স্থাপন করা হয়, এমন অন্যান্য জায়গাগুলি রয়েছে যেগুলি আপনি ফাইল সিস্টেম রাখতে পারেন এবং পার্টিশনগুলি সহ অন্যান্য জিনিসগুলি করতে পারেন, তবে সর্বাধিক সাধারণ বিকল্পটি এটি।
জেসেন

10
"/" থেকে শুরু করে একটি ফাইল শ্রেণিবিন্যাস রয়েছে
এটিতে

@ এমপিজ ০: এমনকি নয়, উদাহরণস্বরূপ chroot(2)বা বাস্তব ধারককরণের সাথে আপনার একাধিক স্তরক্রমও থাকতে পারে, যার একে অপরের সাথে কিছু করার নেই।
কেভিন

কেভিন, chrootপ্রক্রিয়া এবং এর বংশধরদের জন্য শ্রেণিবিন্যাসের একটি অংশকে বিচ্ছিন্ন করে, তবে পিতামাতার এখনও একটি সম্পূর্ণ শ্রেণিবিন্যাস রয়েছে। কোনও ভিএম এর কতটা কাছাকাছি তার উপর নির্ভর করে ধারককরণ এটি করতে পারে। তবে একটি মন্তব্যে কতটা বিশদ প্যাক করতে পারে? ধন্যবাদ,
mpez0

23

ফাইল সিস্টেম একটি ডিরেক্টরি ডিরেক্টরির এন্ট্রি ফাইল সংগঠিত করার জন্য স্থিরীকৃত গঠন দ্বারা গঠিত হয়। প্রতিটি ডিরেক্টরি এন্ট্রি একটি ইনোডের সাথে একটি ফাইল-নাম যুক্ত করে ।

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

হার্ড লিঙ্কগুলি ডিরেক্টরি এন্ট্রি যা ফাইলের নাম এবং ইনোড নম্বর ধারণ করে । আপনি শেষ হার্ড লিঙ্কটি সরিয়ে ফেললে আপনি আর ফাইলটি অ্যাক্সেস করতে পারবেন না।

সফট-লিঙ্ক এবং হার্ড-লিঙ্কের মধ্যে পার্থক্য

উপসংহার:

ইনোডটি কোনও ফাইল-সিস্টেমের অবজেক্টকে উপস্থাপন করতে ব্যবহৃত ডেটা স্ট্রাকচার হিসাবে এটি ফাইল সিস্টেমের অভ্যন্তরীণ এবং আপনি অন্য কোনও ফাইল সিস্টেমের ইনোডকে নির্দেশ করতে পারবেন না ।

সুতরাং, হার্ড-লিঙ্কগুলি কেবল একই ফাইল সিস্টেমের মধ্যে বৈধ, তবে সফ্ট-লিঙ্কগুলি (সিম্বলিক লিঙ্ক) ফাইল সিস্টেমগুলি স্প্যান করতে পারে কারণ তারা কেবলমাত্র অন্য ডিরেক্টরি এন্ট্রি (ফাইল-সিস্টেমের ইন্টারফেস, এবং কোনও অভ্যন্তরীণ বস্তু নয়) নির্দেশ করে।


1
সুন্দর সংক্ষিপ্ত উত্তর।
দুবকাত

যদি অন্য ফাইল সিস্টেমের (যাক ইউএসবি বলি) একই NAME এর সাথে একটি ফাইল থাকে, তবে আমাদের প্রতীকী লিঙ্কটি আমাদের ফাইল সিস্টেমে সংযুক্ত আছে, তবে কী হবে?
জোসেফ ক্লিমুক

@ জোসেফক্লিমুক, একটি নরম লিঙ্ক একটি পথের দিকে ইঙ্গিত করবে, আসুন বলি /mnt/myfile। আপনি যদি অন্য একটি ফাইল সিস্টেম মাউন্ট করেন /mnt/। নরম লিঙ্কটি মাউন্ট করা ফাইল সিস্টেমের অধীনে প্রবেশের জন্য সমাধান করা হবে /mnt/। সুতরাং, আপনি যদি নিজের ইউএসবি ডিভাইস থেকে ফাইল সিস্টেমটি মাউন্ট করেন /mntতবে নরম লিঙ্কটি সেই ফাইল সিস্টেমে প্রবেশের সমাধান করবে।
Facundo ভিক্টর

2

মূল ফাইল সিস্টেমটি বেশ কয়েকটি ফাইল সিস্টেমের সমন্বয়ে গঠিত হতে পারে; /usr/localএকটি পৃথক পার্টিশনে মাউন্ট করা /homeহতে পারে এবং অন্য কোথাও একটি নেটওয়র্ক ডিস্কে অন্য পার্টিশনে থাকতে পারে। এই ক্ষেত্রে, /usr/local/bin/git(উদাহরণস্বরূপ) এর জন্য একটি হার্ড লিঙ্কটি বাইরে তৈরি নাও করা যেতে পারে /usr/local, কারণ এটি ফাইল সিস্টেমগুলিকে স্প্যান করে

এর কারণ হ'ল ইনোডগুলি আলাদাভাবে বরাদ্দ করা হয় /, /usr/localএবং /home(আবার এই উদাহরণে), এবং আপনি একটি হার্ড লিঙ্ক তৈরি করার সময় আপনি সত্যই একটি ইনোডের জন্য একটি অতিরিক্ত নাম তৈরি করেন।


2

হার্ড লিঙ্কগুলি তাদের লক্ষ্যকে বাঁচিয়ে রাখার প্রভাব রাখে। যতক্ষণ না কোনও হার্ড লিঙ্ক পৌঁছানো যায় ততক্ষণ সিস্টেমটি নিশ্চিত করবে যে তার লক্ষ্যটি মুক্তি পেতে পারে না। অতএব এটি প্রয়োজনীয় যে সমস্ত মিডিয়া যাতে একটি নির্দিষ্ট ইনোডের সাথে হার্ড লিঙ্ক থাকতে পারে সিস্টেম যে কোনও সময় এটির কোনও রেফারেন্স বিদ্যমান কিনা তা নির্ধারণের জন্য চেষ্টা করা হবে ounted

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


ভাল পয়েন্ট, তবে একটি ভাল উত্তর হতে খুব স্পর্শকাতর।
জো

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

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

1

প্রতিটি ফাইল সিস্টেমে ফাইল উপস্থাপন করতে একটি একক ইনোড নম্বর ব্যবহার করে। ইনড নম্বর অনুসারে সমস্ত হার্ড লিঙ্ক। ফাইল সিস্টেম রেফারেন্স লিংক এখানে

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