পৃষ্ঠা ক্যাশে 100% পেজ থাকা কোনও ফাইল অন্য প্রক্রিয়া দ্বারা সংশোধিত হয়ে গেলে কী হয়


14

আমি জানি যে যখন কোনও পৃষ্ঠার ক্যাশে পৃষ্ঠাটি সংশোধন করা হয়, তখন এটি নোংরা হিসাবে চিহ্নিত হয় এবং লিখিতব্যাকের প্রয়োজন হয়, তবে কী ঘটে যখন:

পরিস্থিতি: ফাইল / অ্যাপস / এক্সইএইচ, যা একটি এক্সিকিউটেবল ফাইল, সম্পূর্ণরূপে পৃষ্ঠা ক্যাশে পেজ করা হয় (এর সমস্ত পৃষ্ঠাগুলি ক্যাশে / স্মৃতিতে রয়েছে) এবং প্রক্রিয়া পি দ্বারা সম্পাদন করা হয়

অবিচ্ছিন্ন রিলিজ তারপরে / অ্যাপ্লিকেশনগুলি / এক্সইএইকে নতুন এক্সিকিউটেবলের সাথে প্রতিস্থাপন করে।

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

অনুমান 2: আমি ধরে নিয়েছি যে যদি ফাইলের সমস্ত পৃষ্ঠাগুলি মেমরির মধ্যে ম্যাপ না করা হয় তবে ফাইলটি প্রতিস্থাপন করা পৃষ্ঠাগুলির জন্য প্রয়োজনীয় একটি পৃষ্ঠার ত্রুটি না হওয়া পর্যন্ত জিনিস ঠিক থাকবে, এবং সম্ভবত একটি সেগফল্ট ঘটবে?

প্রশ্ন 1: আপনি যদি ভিএমটিচ এর মতো কিছু দিয়ে ফাইলের সমস্ত পৃষ্ঠাগুলি লক করেন তবে দৃশ্যপটটি কি আদৌ বদলে যায়?

প্রশ্ন ২: যদি / অ্যাপস / এএসইই একটি রিমোট এনএফএসে থাকে তবে তাতে কি কোনও পার্থক্য হবে? (আমি ধরে নেই)

আমার 2 অনুমানগুলি সংশোধন করুন বা যাচাই করুন এবং আমার 2 টি প্রশ্নের উত্তর দিন।

ধরে নেওয়া যাক এটি কোনও CentOS 7.6 বাক্স যা কোনও ধরণের 3.10.0-957.el7 কার্নেল সহ

আপডেট: এ সম্পর্কে আরও চিন্তা করে, আমি অবাক হয়েছি যদি এই দৃশ্যটি অন্য কোনও নোংরা পৃষ্ঠাগুলির চেয়ে আলাদা না হয় ..

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

আমার সন্দেহ হয় যখন বর্তমানে সম্পাদনকারী প্রোগ্রামগুলি শেষ হয়, অন্য কিছু বাইনারি ব্যবহার করবে। এগুলি সব সঠিক বলে ধরে নিচ্ছি, আমি অনুমান করি এটি কেবলমাত্র আকর্ষণীয় যখন কেবলমাত্র কিছু ফাইল ফাইল করা থাকে।


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

উত্তর:


12

অবিচ্ছিন্ন রিলিজ তারপরে / অ্যাপ্লিকেশনগুলি / এক্সইএইকে নতুন এক্সিকিউটেবলের সাথে প্রতিস্থাপন করে।

এটি গুরুত্বপূর্ণ অংশ।

একটি নতুন ফাইল প্রকাশের উপায়টি হ'ল একটি নতুন ফাইল তৈরি করা (উদাঃ /apps/EXE.tmp.20190907080000), বিষয়বস্তু লিখে, অনুমতি এবং মালিকানা নির্ধারণ এবং অবশেষে (2) নামটি চূড়ান্ত নামে যুক্ত /apps/EXEকরে পুরানো ফাইলটি প্রতিস্থাপন করে।

ফলাফলটি হ'ল নতুন ফাইলে একটি নতুন ইনোড নম্বর রয়েছে (যার অর্থ, বাস্তবে এটি একটি ভিন্ন ফাইল।)

এবং পুরাতন ফাইলটির নিজস্ব ইনোড নম্বর ছিল যা ফাইলের নামটি আর দেখায় না, যদিও এটি এখনও প্রায় কাছাকাছি রয়েছে (বা সেই ইনোডের দিকে ইশারা করার কোনও ফাইলের নাম নেই))

সুতরাং, এখানে মূল কথাটি হ'ল আমরা যখন লিনাক্সে "ফাইলগুলি" সম্পর্কে কথা বলি, আমরা প্রায়শই "আইওনড" সম্পর্কে কথা বলি যেহেতু একবার কোনও ফাইল খোলার পরে, ইনোডটি সেই ফাইলটিকে আমরা রেফারেন্সে রাখি।

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

সঠিক।

অনুমান 2 : আমি ধরে নিয়েছি যে যদি ফাইলের সমস্ত পৃষ্ঠাগুলি মেমরিতে ম্যাপ না করা হয় তবে ফাইলটি প্রতিস্থাপন করা হয়েছে এমন পৃষ্ঠাগুলির জন্য প্রয়োজনীয় একটি পৃষ্ঠা ত্রুটি না হওয়া পর্যন্ত জিনিস ঠিক থাকবে, এবং সম্ভবত একটি সেগফল্ট ঘটবে?

ত্রুটিপূর্ণ. পুরাতন ইনোডটি এখনও রয়েছে, সুতরাং পুরাতন বাইনারি ব্যবহার করে প্রক্রিয়াটি থেকে থাকা পৃষ্ঠা ত্রুটিগুলি এখনও সেই পৃষ্ঠাগুলিকে ডিস্কে সন্ধান করতে সক্ষম হবে।

পুরানো বাইনারি চালানোর প্রক্রিয়াটির জন্য /proc/${pid}/exeসিমলিংক (বা সমতুল্যভাবে lsofআউটপুট) দেখে আপনি এর কিছু প্রভাব দেখতে পাচ্ছেন , যা /app/EXE (deleted)দেখায় যে নামটি আর নেই, তবে ইনোডটি এখনও রয়েছে।

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

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

প্রশ্ন 1 : আপনি যদি ভিএমটিচ এর মতো কিছু দিয়ে ফাইলের সমস্ত পৃষ্ঠাগুলি লক করেন তবে দৃশ্যপটের পরিবর্তন ঘটে

এই প্রশ্নটি ভুল অনুমান 2 এর উপর ভিত্তি করে যে পৃষ্ঠাগুলি লক না করা সেগফাল্টের কারণ হবে। এটা হবে না।

প্রশ্ন ২ : যদি / অ্যাপস / এএসইই একটি রিমোট এনএফএসে থাকে তবে তাতে কি কোনও পার্থক্য হবে? (আমি ধরে নেই)

এটি একইভাবে কাজ করার বোঝায় এবং বেশিরভাগ সময় এটি করে তবে এনএফএসের সাথে কিছু "গোটচাস" রয়েছে।

কখনও কখনও আপনি এনএফএস-এ এখনও খোলা একটি ফাইল মোছার নিদর্শনগুলি দেখতে পারেন (সেই ডিরেক্টরিতে একটি লুকানো ফাইল হিসাবে প্রদর্শিত হবে))

এনএফএস রফতানিতে ডিভাইস নম্বর নির্ধারণ করার জন্য আপনার কাছেও কিছু উপায় রয়েছে, এনএফএস সার্ভার পুনরায় চালু হওয়ার পরে সেগুলি "রদবদল" হবে না তা নিশ্চিত করে।

তবে মূল ধারণাটি একই। এনএফএস ক্লায়েন্ট ড্রাইভার এখনও ইনোড ব্যবহার করে এবং ইনোডটি এখনও রেফারেন্স করার সময় ফাইলগুলি (সার্ভারে) রাখার চেষ্টা করবে।


1
পুরানো নাম ফাইলের রেফ গণনা শূন্যে না যাওয়া পর্যন্ত কি নাম পরিবর্তন (2) অবরুদ্ধ করে?
গ্রেগ লেভেন্টাল

2
না, নাম পরিবর্তন (2) অবরুদ্ধ করবে না। পুরানো ইনোডটি সম্ভাব্যভাবে দীর্ঘ সময়ের জন্য রাখা হয়।
ফিলাব্রেন্ডেন

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

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

1
@ গ্রাহামজ 42: পসিক্সের renameঅংশ। মঞ্জুর, এটি আইএসও সি (বর্তমান খসড়ায় 7.21.4.2 বিভাগ) রেফারেন্স দ্বারা অন্তর্ভুক্ত করা হয়েছে, তবে এটি সেখানে রয়েছে।
জার্গ ডব্লু মিট্টাগ

7

অনুমান 2: আমি ধরে নিয়েছি যে যদি ফাইলের সমস্ত পৃষ্ঠাগুলি মেমরিতে ম্যাপ না করা হয় তবে ফাইলটি প্রতিস্থাপন করা হয়েছে এমন পৃষ্ঠাগুলির জন্য প্রয়োজনীয় একটি পৃষ্ঠা ত্রুটি না হওয়া পর্যন্ত জিনিস ঠিক থাকবে, এবং সম্ভবত একটি সেগফল্ট ঘটবে?

না, এটি ঘটবে না, কারণ কার্নেল আপনাকে বর্তমানে সম্পাদিত কোনও ফাইলের অভ্যন্তরে কোনও প্রতিস্থাপন লিখতে দেয় না। ETXTBSY[1] এর সাথে এই জাতীয় পদক্ষেপ ব্যর্থ হবে :

cp /bin/sleep sleep; ./sleep 3600 & echo none > ./sleep
[9] 5332
bash: ./sleep: Text file busy

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

[1] এই জাতীয় সুরক্ষা অন্যান্য ফাইলগুলিতে প্রসারিত নয় যা "পাঠ্য" (লাইভ কোড / এক্সিকিউটেবল) হিসাবে বিবেচনা করা যেতে পারে: শেয়ার্ড লাইব্রেরি, জাভা ক্লাস, ইত্যাদি; যেমন একটি ফাইল পরিবর্তন অন্য প্রক্রিয়া দ্বারা ম্যাপ যখন হবে এটা বিপর্যস্ত হতে পারে। লিনাক্সে, গতিশীল লিঙ্কারটি যথাযথভাবে MAP_DENYWRITEপতাকাটিতে পাস করে mmap(2), তবে কোনও ভুল করবেন না - এটির কোনও প্রভাব নেই।


1
Dpkg দৃশ্যে, কোন মুহুর্তে পুনর্নামকরণটি এমনভাবে পূর্ণ হয় যে / অ্যাপস / এক্সইটির জন্য ডেন্ট্রি নতুন বাইনারিটির ইনোডকে রেফারেন্স করে? পুরোনোটির আর কোনও উল্লেখ নেই যখন? ওটা কিভাবে কাজ করে?
গ্রেগ লেভেন্টাল

2
rename(2)পারমাণবিক; যত তাড়াতাড়ি এটি সম্পন্ন হবে, dir এন্ট্রি নতুন ফাইল বোঝায়। যে প্রক্রিয়াগুলি এখনও সেই সময়ে পুরানো ফাইলটি ব্যবহার করছিল সেগুলি কেবল বিদ্যমান ম্যাপিংগুলির মাধ্যমে বা এটির জন্য খোলা হ্যান্ডলগুলির মাধ্যমে অ্যাক্সেস করতে সক্ষম হবে (যা অনাথ দন্তের রেফারেন্স দিতে পারে, এটি ছাড়া আর অ্যাক্সেসযোগ্য নয় /proc/PID/fd)।
ম্যাসাভি

1
আমি আপনার উত্তরটি সর্বোত্তম পছন্দ করি কারণ আপনার ETXTBSY উল্লেখ আমাকে এই utcc.utoronto.ca/~cks/space/blog/unix/WYTextFileBusyError এ নিয়ে গেছে যা আমার সমস্ত প্রশ্নের উত্তর দেয়।
গ্রেগ লেভেনথাল

4

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

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

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

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