কোনও ফাইল স্থানান্তরিত করার সময় বাধাগ্রস্থ হলে ফাইল সিস্টেমটি কি বেমানান হতে পারে?


13

একই পার্টিশনে আমার দুটি ফোল্ডার রয়েছে (EXT2) আমি mv folder1/file folder2এবং কিছু বিঘ্ন ঘটলে (উদাহরণস্বরূপ বিদ্যুৎ ব্যর্থতা) ফাইল সিস্টেমটি কি কখনও বেমানান হতে পারে?

নন mvঅপারেশন পারমাণবিক?

আপডেট: এখন পর্যন্ত আইআরসি-তে আমি নিম্নলিখিত দৃষ্টিভঙ্গি পেয়েছি:

  1. এটি পারমাণবিক তাই অসঙ্গতি ঘটতে পারে না
  2. প্রথমে আপনি নতুন dir এ dir এন্ট্রিটি অনুলিপি করুন এবং তারপরে আগের dir এন্ট্রি মুছুন, যাতে আপনার কাছে দুবার একটি ফাইল রেফারেন্সের অসঙ্গতি থাকতে পারে তবে রেফ গণনাটি 1
  3. এটি প্রথমে পয়েন্টারটি মুছে দেয় এবং তারপরে পয়েন্টারটি অনুলিপি করে যাতে অসঙ্গতিটি ফাইলটিতে রেফারেন্স 0 থাকে

কেউ কি স্পষ্ট করতে পারেন?

উত্তর:


11

প্রথমে কিছু কল্পকাহিনী দূর করা যাক।

এটি পারমাণবিক তাই অসঙ্গতি ঘটতে পারে না

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

তবুও, যদি বাগ, ডিস্ক ত্রুটি বা বিদ্যুৎ হ্রাসের কারণে সিস্টেমটি ক্র্যাশ হয়ে যায়, তবে ফাইল সিস্টেমটি একটি সামঞ্জস্যপূর্ণ অবস্থায় রয়েছে কিনা তার কোনও গ্যারান্টি নেই, তবে চলুন যে পদক্ষেপটি অর্ধ-সম্পন্ন হয়নি। লিনাক্স সাধারণত হার্ডওয়্যার ইভেন্টের ক্ষেত্রে পারমাণবিকতার গ্যারান্টি দেয় না।

প্রথমে আপনি নতুন dir এ dir এন্ট্রিটি অনুলিপি করুন এবং তারপরে আগের dir এন্ট্রি মুছুন, যাতে আপনার কাছে দুবার একটি ফাইল রেফারেন্সের অসঙ্গতি থাকতে পারে তবে রেফ গণনাটি 1

এটি একটি নির্দিষ্ট বাস্তবায়ন কৌশল বোঝায়। অন্যরাও আছেন।

এটি লিনাক্সের ext2 (কার্নেল 3.16 হিসাবে) এই বিশেষ কৌশলটি ব্যবহার করে happens তবে, এটি বোঝায় না যে ডিস্কের সামগ্রীটি [পুরানো অবস্থান] sequ [উভয় অবস্থান] → [নতুন অবস্থান] অনুসারে চলেছে, কারণ দুটি ক্রিয়াকলাপ (নতুন এন্ট্রি যুক্ত করুন, পুরাতন এন্ট্রি সরান) হার্ডওয়্যার স্তরেও পারমাণবিক নয় : ফাইল সিস্টেমটিকে একটি অসামঞ্জস্য অবস্থায় রেখে, তার মধ্যে একটির বাধা দেওয়া সম্ভব। (আশা করি fsck এটি মেরামত করবে)) তদতিরিক্ত ব্লক স্তরটি পুনরায় অর্ডার করতে পারে লেখাগুলি, সুতরাং প্রথমার্ধটি ক্র্যাশের ঠিক আগে ডিস্কে প্রতিশ্রুতিবদ্ধ হতে পারে এবং দ্বিতীয়ার্ধটি তখন সম্পাদন করা হত না।

যতক্ষণ সিস্টেম ক্রাশ না হয় (উপরে দেখুন) ততক্ষণ রেফারেন্স গণনাটি 1 টির থেকে পৃথক হতে পারে না তবে এই গ্যারান্টিটি সিস্টেম ক্র্যাশ পর্যন্ত প্রসারিত হয় না।

এটি প্রথমে পয়েন্টারটি মুছে দেয় এবং তারপরে পয়েন্টারটি অনুলিপি করে যাতে অসঙ্গতিটি ফাইলটিতে রেফারেন্স 0 থাকে

আবার, এটি একটি নির্দিষ্ট বাস্তবায়ন কৌশল বোঝায়। সিস্টেমটি ক্র্যাশ না হলে একটি ঝোলা ফাইল পর্যবেক্ষণ করা যায় না, তবে এটি কোনও সিস্টেমের ক্রাশের সম্ভাব্য পরিণতি, কমপক্ষে কিছু কনফিগারেশনে in


আলেকজান্ডার লারসনের একটি ব্লগ পোস্ট অনুসারে , ext2 কোনও সিস্টেম ক্র্যাশের ক্ষেত্রে ধারাবাহিকতার কোনও গ্যারান্টি দেয় না, তবে ext3 data=orderedমোডে দেয়। (দ্রষ্টব্য যে এই ব্লগ পোস্টটি নিজের সম্পর্কে renameনয়, তবে কোনও ফাইলে লেখার এবং renameসেই ফাইলটিতে কল করার সংমিশ্রণ সম্পর্কে ))

Ext2, ext3 এবং ext4 ফাইল সিস্টেমের প্রধান লেখক থিওডোর সো'ও একই ইস্যুতে একটি ব্লগ পোস্ট লিখেছিলেন । এই ব্লগ পোস্টে পারমাণবিকতা (কেবলমাত্র সফ্টওয়্যার পরিবেশের সাথে সম্মানজনক) এবং স্থায়িত্ব (যা ক্র্যাশগুলির সাথে সম্মতিযুক্ত পারমাণবিকতা এবং প্রতিশ্রুতির গ্যারান্টি, অর্থাৎ অপারেশনটি সম্পন্ন হয়েছে তা জেনেও) আলোচনা করে। দুর্ভাগ্যক্রমে আমি একাই ক্র্যাশ করার বিষয়ে পারমাণবিকতার তথ্য খুঁজে পাই না। যাইহোক, ext4 এর জন্য দেওয়া স্থায়িত্ব গ্যারান্টির জন্য এটি renameঅবশ্যই পারমাণবিক। Ext4- র জন্য কার্নেল ডকুমেন্টেশন সূচিত করে যে auto_da_allocবিকল্পটি সহ ext4 (যা আধুনিক কার্নেলগুলির মধ্যে পূর্বনির্ধারিত), পাশাপাশি ext4, একটি writeঅনুসরণ করার জন্য একটি স্থায়িত্ব গ্যারান্টি সরবরাহ করেrename, যা বোঝায় যে renameহার্ডওয়্যার ক্র্যাশগুলির ক্ষেত্রে এটি পারমাণবিক।

Btrfs জন্য, একটি renameএকটি বিদ্যমান ফাইল মুছে ফেলা হয় ক্র্যাশ থেকে সম্মান সঙ্গে পারমাণবিক হতে নিশ্চিত করা হয়, কিন্তু একটি renameকরে একটি ফাইলটি প্রতিস্থাপন না তন্ন তন্ন ফাইল বা বিদ্যমান উভয় ফাইল হতে পারে।


সংক্ষেপে বলা যায়, আপনার প্রশ্নের উত্তর যে না শুধুমাত্র একটি ফাইল চলন্ত দ্বারা ext2 উপর ক্র্যাশ থেকে সম্মান সঙ্গে পারমাণবিক নয়, কিন্তু এটা এমনকি একটি সামঞ্জস্যপূর্ণ রাজ্যের ফাইল ত্যাগ করার নিশ্চিত করা হয় না (যদিও ব্যর্থতা যে fsckকরতে পারবেন মেরামতি বিরল) - সুন্দর কিছুই কিছুই না, তাই ভাল ফাইল সিস্টেম উদ্ভাবিত হয়েছে। Ext3, ext4 এবং btrfs সীমিত গ্যারান্টি সরবরাহ করে।


13

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

যদি আপনার বিদ্যুৎ ব্যর্থতার মুখে দৃust় হতে কোনও ফাইল সিস্টেমের প্রয়োজন হয় তবে আপনার একটি জার্নালিং ফাইল সিস্টেম যেমন এনটিএফএস, এক্সটি 3, বা এক্সএফএস ব্যবহার করা উচিত । বেশিরভাগ আধুনিক সিস্টেমগুলি ডিফল্টরূপে একটি জার্নালিং ফাইল সিস্টেম ব্যবহার করবে, যদিও আপনার সচেতন হওয়া উচিত যে আপনি যদি বাহ্যিক ড্রাইভের জন্য এটি ব্যবহার করেন তবে FAT জার্নালিং ফাইল সিস্টেম নয়।

একটি জার্নালিং ফাইল সিস্টেম একটি "ডাবল এন্ট্রি" সিস্টেম ব্যবহার করে - এটি জার্নাল ফাইলটিতে এটি স্থানান্তরিত করার ইচ্ছা রাখে এবং তারপরে সঞ্চালন করে writes প্রারম্ভকালে ফাইল সিস্টেমটি পরীক্ষা করা হয়, যদি এটি বাধাগ্রস্ত হয়, তবে এটি লক্ষ্য করবে যে সরানোটি সম্পূর্ণ হয়নি এবং তখন এটি পুনরায় করা হবে।

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


লোকেরা যখন নাম পরিবর্তনের অপারেশনটিকে পারমাণবিক বলে নিয়ে কথা বলেন, তখন তাদের অর্থ হ'ল এটি সিস্টেমে অন্য কোনও প্রক্রিয়া দ্বারা মিড-ট্রানজিশনটি লক্ষ্য করা যায় না, এবং এটি অর্ধ-সমাপ্ত হতে পারে না যেমন mvকমান্ডটি নিজেই বাধা দিয়ে ^C। প্রতিটি ডিরেক্টরিতে লেখার শারীরিক প্রক্রিয়া, যার স্টোরেজ স্পেসটি ডিস্কের বিভিন্ন স্থানে থাকতে পারে, সম্ভবত হার্ডওয়্যার স্তরে সত্যিকারের পারমাণবিক ক্রিয়াকলাপ হতে পারে না।


সম্পূর্ণতার জন্য, আমি নোট করব যে গন্তব্য ডিরেক্টরিতে নতুন লিঙ্ক তৈরি করা এবং এটি পুরানোটিতে অপসারণ করা ছাড়াও একটি নতুন নামের সাথে সম্পর্কিত কিছু ঘটনামূলক I / O ক্রিয়াকলাপ রয়েছে - উভয় ডিরেক্টরিগুলির এমটাইম আপডেট করা, সম্ভবত প্রসারিত গন্তব্য ডিরেক্টরিতে বরাদ্দের আকার, ..লিঙ্ক পরিবর্তন করা এবং যদি ফাইলটি ডিরেক্টরি থাকে তবে মূল ডিরেক্টরিগুলির লিঙ্ক গণনা করা হয়। এছাড়াও, আমি নিশ্চিত নই যে ফাইলটির সময়কাল নিজেই প্রভাবিত হয়েছে কিনা।


একটি জার্নাল পারমাণবিকতা আর্ট শক্তি ব্যর্থতার গ্যারান্টি দেয় না। আমি মনে করি যে ext3 এবং ext4 গ্যারান্টি দেয় যা renameপারমাণবিক, তবে বিটিআরএফএস উইকি অনুসারে হয় না (আমার উত্তর দেখুন)। জার্নাল ছাড়া পারমাণবিকতার গ্যারান্টি দেওয়াও সম্ভব (লিনাক্সের উদাহরণগুলি আমি জানি না তবে কিছু থাকতে পারে)। আপনার এক্সট 2 সম্পর্কে নির্ভরযোগ্য তথ্য আছে?
গিলস 'অশুভ হওয়া বন্ধ করুন'

@ গিলস এর কাছে কী কোনও জার্নাল ছাড়া তাত্ত্বিকভাবে গ্যারান্টি দেওয়া যেতে পারে সে সম্পর্কে আপনার কাছে কি কোনও তথ্য আছে? আমি বলতে চাইছি, বেসিক স্তরে, আমরা দু'টি পৃথক ফাইলের সাথে সিঙ্ক্রোনাইজ করার কথা বলছি গ্যারান্টি দিতে যে আপনি কখনই ফলাফল পাবেন না যে কেবলমাত্র তাদের মধ্যে একটিরই সম্পাদিত হয়েছিল।
র্যান্ডম 832

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

1

এই প্রশ্নটি সুপার ব্যবহারকারীকে কিছুটা ভিন্ন পদ্ধতিতে জিজ্ঞাসা করা হয়েছেmvকমান্ডের উইকিপিডিয়া পৃষ্ঠাও এটি বেশ ভালভাবে ব্যাখ্যা করেছে :

একই ফাইল সিস্টেমের মধ্যে ফাইলগুলি সরানো সাধারণত ফাইলটি অনুলিপি করা এবং তারপরে মূলটি অপসারণের চেয়ে আলাদাভাবে প্রয়োগ করা হয়। প্ল্যাটফর্মগুলিতে যেগুলি পুনরায় নাম সিস্কাল সমর্থন করে না, তাদের নতুন ডিরেক্টরিতে নতুন লিঙ্ক যুক্ত করা হবে এবং আসলটি মুছে ফেলা হবে is ফাইলের ডেটা অ্যাক্সেস করা হয় না।

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


2
পুনর্নবীকরণকারী সিস্ট কি কোনও অসম্প্রেশন কল করে? হার্ডওয়্যার
ওয়াইজ

না, এটি কোনও ওএস বিমূর্ততা নয়, তবে আমি ভেবেছিলাম "এই কারণে ফাইল সিস্টেমটি বেমানান হওয়ার খুব সম্ভাবনা নেই ..." বিষয়গুলি অতিরিক্ত জটিল করে তুলবে। যদিও আমি আপনার সাথে একমত।
বেনিয়ামিন বি।

2
এই উত্তরটি পাতার আমাকে হতাশ কেনrename সিস্টেম কল ফাইলসিস্টেম কোনো অসঙ্গত স্থিতিতে একটি শক্তি ব্যর্থতা আছে এমনকি যদি হচ্ছে ফলে করতে পারবে না। আমি অনুভব করেছি যে এটি @ লেখচিত্রের92 প্রশ্নের মূল বিষয়।
ট্যানার সোয়েট

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

2
পারমাণবিকতার যে গ্যারান্টি আপনি উল্লেখ করেছেন তা হ'ল অন্যান্য প্রক্রিয়া পর্যবেক্ষণের ক্ষেত্রে। সিস্টেমটি ক্রাশ হলে এটি ধরে না।
গিলস 'অশুভ হওয়া বন্ধ করুন'
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.