জেডএফএস থেকে 10 এম + ফাইলগুলি কার্যকরভাবে মুছুন


30

আমি একটি বগি প্রোগ্রাম লিখেছি যা দুর্ঘটনাক্রমে প্রায় 30 এম ফাইল / টিএমপি এর অধীনে তৈরি করেছে। (কিছু সপ্তাহ আগে বাগটি প্রবর্তিত হয়েছিল এবং এটি প্রতি সেকেন্ডে কয়েকটি উপ-ডিরেক্টরি তৈরি করছিল)) আমি / tmp এর নাম / টিএমপি 2 রাখতে পারি এবং এখন আমার ফাইলগুলি মুছতে হবে। সিস্টেমটি ফ্রিবিএসডি 10, মূল ফাইল সিস্টেম zfs f

ইতিমধ্যে আয়নাতে থাকা একটি ড্রাইভ ভুল হয়ে গেছে এবং আমি এটি প্রতিস্থাপন করেছি। ড্রাইভে দুটি 120 গিগাবাইট এসএসডি ডিস্ক রয়েছে।

এখানে প্রশ্নটি রয়েছে: হার্ড ড্রাইভটি প্রতিস্থাপন এবং পুরো অ্যারেটিকে পুনরায় সজ্জিত করতে এক ঘণ্টারও কম সময় লেগেছিল। ফাইল / টিএমপি 2 মুছে ফেলা অন্য গল্প। আমি ফাইলগুলি অপসারণ করতে অন্য একটি প্রোগ্রাম লিখেছি এবং এটি প্রতি সেকেন্ডে 30-70 সাব-ডাইরেক্টরিগুলি মুছতে পারে। সমস্ত ফাইল মুছতে 2-4 দিন সময় লাগবে।

কীভাবে এটি সম্ভব যে পুরো অ্যারেটিকে পুনর্নির্মাণ করতে এক ঘন্টা সময় লাগে, তবে ডিস্ক থেকে মুছতে 4 দিন সময় লাগে? আমার এত খারাপ অভিনয় কেন? 70 টি মোছা / সেকেন্ড খুব খারাপ অভিনয় বলে মনে হচ্ছে।

আমি নিজে / tmp2 এর জন্য ইনোডটি মুছে ফেলতে পারি, তবে এটি স্থান খালি করবে না, তাই না?

এটি কি জেডএফএস, বা হার্ড ড্রাইভগুলির সমস্যা হতে পারে?


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

দয়া করে পোষ্ট আপনার df -hএবং zpool listএবং zfs list
ew white

5
আরেকটি প্রোগ্রাম লিখেছেন: কাজ rm -rf /tmp2করবেন না?
থরবজর্ন রাভন অ্যান্ডারসন

2
আপনি কি কেবল বুবুট করতে পারবেন না? /tmpএকটি tmpfsফাইল সিস্টেম হওয়া উচিত এবং মেমরিতে সঞ্চয় করা উচিত ।
ব্লেন্ডার

উত্তর:


31

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

আপনার /tmpমধ্যে থাকা ডেটার পরিবর্তে ডিরেক্টরি মুছে ফেলা ভাল ।

যদি /tmpজেডএফএস ফাইল সিস্টেম হয় তবে এটি মুছুন এবং আবার তৈরি করুন।


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

9
আমি ভৃল ছিলাম. এটি একটি পৃথক ফাইল সিস্টেম ছিল। এখানে যা কাজ হয়েছিল তা এখানে রয়েছে: একক ব্যবহারকারী মোডে পুনরায় বুট করুন, তারপরে "zfs zroot / tmp মুছুন; zfs zroot / tmp তৈরি করুন; chmod 41777 / tmp"
নাগাইলিজ

6
এটি মোট ডাউনটাইম ছিল 5 মিনিট। ফ্যান্টাস্টিক! :-)
নাগিলিজ

1
ঠিক আছে, এটি আমার যে উদ্বেগ ছিল তা বোঝায়, যে স্নিপশটের কারণে ফিলিকগুলি মুছে ফেলা কখনও স্থান মুক্ত করে না। তবে স্বয়ংক্রিয় পর্যায়ক্রমিক স্ন্যাপশট না তৈরি করার জন্য টিএমপি সেট আপ করা হবে, তাই না ?
জেডিগোসস

1
আসলে এটি ছিল: zfs create -o compression = on -o exec = on -o setuid = off zroot / tmp; chmod 1777 / zroot / tmp; zfs মাউন্টপয়েন্টটি সেট করে = / tmp zroot / tmp; তবে কীভাবে অটো স্ন্যাপশট বন্ধ করবেন তা আমি নিশ্চিত নই। "Zfs সেট com.sun আছে: অটো-স্ন্যাপশট = মিথ্যা" তবে এটি কেবল সোলারিসে কাজ করে, আমি মনে করি।
নাগিলিজ

27

কীভাবে এটি সম্ভব যে পুরো অ্যারেটিকে পুনর্নির্মাণ করতে এক ঘন্টা সময় লাগে, তবে ডিস্ক থেকে মুছতে 4 দিন সময় লাগে?

একটি অফিস ভবন বিবেচনা করুন।

সমস্ত ফ্লোরের সমস্ত অফিস থেকে সমস্ত কম্পিউটার এবং আসবাব এবং ফিক্সিংগুলি সরিয়ে ফেলার ক্ষেত্রে অনেক দিন সময় লাগে তবে অন্য ক্লায়েন্ট কর্তৃক অফিসগুলিকে অবিলম্বে ব্যবহারযোগ্য করে চলে যায়।

দ্য RDX দিয়ে পুরো ভবন ধ্বংস একটি হল সম্পূর্ণ অনেক দ্রুততর, কিন্তু পরবর্তী ক্লায়েন্ট বেশ কিভাবে drafty স্থান সম্পর্কে অভিযোগ করার সম্ভাবনা বেশি।


5
জেডএফএস কোনও অফিসের বিল্ডিং নয় :)
developerbmw

9
@ বিকাশকারী সেখানে আসলে কোনও ফাইল বা ফোল্ডারও নেই তবে কী চলছে তা বোঝার জন্য আমাদের রূপক ধারণা প্রয়োজন।
জেমসআরয়ান

2
@ জেমসআরয়ান হ্যাঁ এটি আসলে একটি দুর্দান্ত উপমা ... আমি কেবল বোকা ছিলাম
developerbmw

5

এখানে বেশ কয়েকটি জিনিস চলছে।

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

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

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

কীভাবে এটি সম্ভব যে পুরো অ্যারেটিকে পুনর্নির্মাণ করতে এক ঘন্টা সময় লাগে, তবে ডিস্ক থেকে মুছতে 4 দিন সময় লাগে?

রিসিলভারিং এমন একটি জিনিস যা ডিস্কগুলি আসলেই দ্রুত এবং মুছে ফেলা এমন কিছু যা ডিস্কগুলি ধীর করে দেয় are প্রতি মেগাবাইট ডিস্কে আপনাকে কেবল কিছুটা পুনর্নির্মাণ করতে হবে। আপনার কাছে সেই জায়গাতে এক হাজার ফাইল থাকতে পারে যা মুছতে হবে।

70 টি মোছা / সেকেন্ড খুব খারাপ অভিনয় বলে মনে হচ্ছে

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

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


পরিশিষ্ট: মুছে ফেলা মন্থর কেন?

  • একটি ফাইল মুছতে বিভিন্ন পদক্ষেপ প্রয়োজন requires ফাইল মেটাডেটা অবশ্যই 'মুছে ফেলা' হিসাবে চিহ্নিত করতে হবে এবং শেষ পর্যন্ত এটি পুনরায় দাবি করতে হবে যাতে স্থানটি পুনরায় ব্যবহার করা যায়। জেডএফএস হ'ল 'লগ স্ট্রাকচার্ড ফাইল সিস্টেম' যা আপনি যদি কখনও জিনিস তৈরি করেন তবে সেগুলি কখনও মুছবেন না সে ক্ষেত্রে সেরা অভিনয় করে। লগ স্ট্রাকচারের অর্থ হ'ল আপনি যদি কিছু মুছে ফেলেন তবে লগের মধ্যে একটি ফাঁক রয়েছে এবং শূন্যস্থান পূরণের জন্য অবশ্যই অন্যান্য ডেটা পুনরায় সাজানো (ডিফ্র্যাগমেন্টেড) করতে হবে। এটি ব্যবহারকারীর কাছে অদৃশ্য তবে সাধারণভাবে ধীর।
  • পরিবর্তনগুলি অবশ্যই এমনভাবে করা উচিত যে যদি বিদ্যুৎটি আংশিকভাবে ব্যর্থ হয় তবে ফাইল সিস্টেমটি সুসংগত থাকে। প্রায়শই, এর অর্থ ডিস্কের নিশ্চিত হওয়া অবধি অপেক্ষা করা মানে ডেটাটি সত্যই মিডিয়াতে রয়েছে; একটি এসএসডি-র জন্য, এটি একটি দীর্ঘ সময় নিতে পারে (শত মিলি সেকেন্ড)। এর নেট এফেক্টটি হ'ল আরও অনেক বুককিপিং রয়েছে (যেমন ডিস্ক আই / ও অপারেশন)।
  • সমস্ত পরিবর্তন ছোট। পুরো ফ্ল্যাশ ব্লকগুলি (বা চৌম্বকীয় ডিস্কের জন্য সিলিন্ডারগুলি) পড়ার, লেখার এবং মুছে ফেলার পরিবর্তে আপনাকে কিছুটা পরিবর্তন করতে হবে। এটি করার জন্য, হার্ডওয়্যার অবশ্যই একটি সম্পূর্ণ ব্লক বা সিলিন্ডারে পড়তে হবে, এটিকে মেমরিতে সংশোধন করতে হবে, তারপরে এটি আবার মিডিয়ায় লিখতে হবে। এটি একটি দীর্ঘ সময় লাগে।

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

2

কীভাবে এটি সম্ভব যে পুরো অ্যারেটিকে পুনর্নির্মাণ করতে এক ঘন্টা সময় লাগে, তবে ডিস্ক থেকে মুছতে 4 দিন সময় লাগে?

দুটি সিস্টেম অপারেশন ফাইল সিস্টেম স্ট্যাকের বিভিন্ন স্তরে কাজ করার কারণে এটি সম্ভব। রিসিলভারিং লো-লেভেল চালাতে পারে এবং প্রকৃতপক্ষে একক সময়ে প্রচুর পরিমাণে ডেটা অনুলিপি করে পৃথক ফাইলগুলি দেখার প্রয়োজন হয় না।

আমার এত খারাপ অভিনয় কেন? 70 টি মোছা / সেকেন্ড খুব খারাপ অভিনয় বলে মনে হচ্ছে।

এটি প্রচুর বুককিপিং করতে হবে ...

আমি নিজে / tmp2 এর জন্য ইনোডটি মুছে ফেলতে পারি, তবে এটি স্থান খালি করবে না, তাই না?

আমি জেডএফএসের জন্য জানি না, তবে এটি যদি স্বয়ংক্রিয়ভাবে এটি থেকে পুনরুদ্ধার করতে পারে তবে এটি শেষ পর্যন্ত পটভূমিতে আপনি ইতিমধ্যে একই ক্রিয়াকলাপগুলি করবেন।

এটি কি জেডএফএস, বা হার্ড ড্রাইভগুলির সমস্যা হতে পারে?

না zfs scrubকিছু বলতে?


2

প্রচুর ফাইল মুছে ফেলা সত্যিই দ্রুত অপারেশন হয় না।

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

এমনকি জেডএফএসের অদ্ভুততা ছাড়াই পরিচয় করিয়ে দেওয়া হয়েছে, 30 মিলিয়ন ফাইল মুছে ফেলার অর্থ সাধারণত একশ মিলিয়ন পৃথক আই / ও অপারেশন। এটি দ্রুত এসএসডি সহ দীর্ঘ সময় নিবে । অন্যরা যেমন উল্লেখ করেছেন, জেডএফএসের নকশা এই সমস্যাটিকে আরও সংহত করে।


2

ইয়ান হাওসন কেন ধীর হয় তার একটি ভাল উত্তর দেয়।

আপনি যদি সমান্তরালভাবে ফাইলগুলি মুছতে পারেন তবে মুছে ফেলার কারণে গতি বৃদ্ধি হতে পারে একই ব্লকগুলি ব্যবহার করতে পারে এবং এইভাবে একই ব্লকে অনেক বার পুনরায় লেখা সংরক্ষণ করতে পারে।

সুতরাং চেষ্টা কর:

find /tmp -print0 | parallel -j100 -0 -n100 rm

এবং দেখুন যে এটি প্রতি সেকেন্ডে আপনার 70 টি মোছার চেয়ে আরও ভাল পারফর্ম করে।


0

আপনি যদি আপনার চিন্তাভাবনা উল্টে দেন তবে খুব সহজ।

  1. দ্বিতীয় ড্রাইভ পান (আপনার কাছে এটি ইতিমধ্যে মনে হয়েছে)

  2. / Tmp ডিরেক্টরি বাদ দিয়ে ড্রাইভ এ থেকে ড্রাইভ বি পর্যন্ত সমস্ত কিছু অনুলিপি করুন। Rsync একটি ব্লক কপির চেয়ে ধীর হবে।

  3. নতুন বুট ভলিউম হিসাবে ড্রাইভ বি ব্যবহার করে পুনরায় বুট করুন

  4. সংস্কার ড্রাইভ এ।

এটি আপনার ড্রাইভকে ডিফ্র্যাগমেন্টও দেবে এবং আপনাকে একটি নতুন ডিরেক্টরি দেবে (জরিমানা, কোনও এসএসডি এর সাথে ডিফ্র্যাগ এত গুরুত্বপূর্ণ নয় তবে আপনার ফাইলগুলিকে লিনিয়ারাইজ করা কখনই কোনও আঘাত দেয় না)


প্রথমে / টিএমপি বাদে সব কিছু অনুলিপি করবেন? সুতরাং / দেব এবং / প্রকোপ সহ? দ্বিতীয়ত, বিশেষত একটি প্রোডাকশন সার্ভারে আমার কাছে কিছুটা ক্লডজি শোনান।
হেনেস

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

আমি মনে করি আপনি zfs send/recvরুট ফাইল সিস্টেম (যেখানে / টিএমপি এই ক্ষেত্রে অবস্থিত) ব্যতীত অন্য সমস্ত ফাইল সিস্টেমে (ব্লক-স্তরের অনুলিপি) করতে পারবেন এবং অবশিষ্ট ডেটা ম্যানুয়ালি (অবশ্যই / tmp বাদে) অনুলিপি করতে পারবেন।
ব্যবহারকারী 121391

2
এটি স্ন্যাপশটগুলি হারাবে এবং নির্ভরযোগ্যতার কয়েকটি বৈশিষ্ট্যকে বাইপাস করবে। Zfs ব্যবহারের বিন্দুটি মিস করে।
জেডুগোস্জ

2
@ জেডিগোগোজ বৈধ পয়েন্ট, তবে কেবল ব্যবহারকারী প্রাসঙ্গিক হলে প্রাসঙ্গিক। "আমার ব্যাকআপগুলি নষ্ট হয়ে গেছে, কীভাবে মেরামত করবেন?" -> "আপনার কোনও ব্যাকআপ ফাইলের দরকার আছে?" -> "না" -> "পুনরায় ফর্ম্যাট"।
পিটার

-1

অরসোর্টড তালিকায় আপনার 30 মিলিয়ন এন্ট্রি রয়েছে। আপনি যে এন্ট্রিটি সরাতে চান তার জন্য তালিকাটি স্ক্যান করে আপনি এটি সরিয়ে ফেলুন। আপনার অচিরাচরিত তালিকায় এখন কেবল 29,999,999 টি প্রবেশ রয়েছে। যদি তারা সমস্ত / টেম্পে থাকে তবে কেবল পুনরায় বুট করবেন না কেন?


মন্তব্যগুলিতে তথ্য প্রতিবিম্বিত করতে সম্পাদিত: সমস্যার বিবৃতি: / এমএমপি-তে ভুলভাবে তৈরি করা 30 এম + এর মধ্যে বেশিরভাগ, তবে সমস্ত নয় , সরানো বেশ দীর্ঘ সময় নিচ্ছে।
সমস্যা 1) / tmp থেকে বিপুল সংখ্যক অযাচিত ফাইল সরানোর সর্বোত্তম উপায়।
সমস্যা 2) ফাইলগুলি মুছতে এত ধীর কারণ কেন।

সমাধান 1) - / tmp বেশিরভাগ * নিক্স বিতরণ করে বুটে ফাঁকাতে পুনরায় সেট করা হয়। ফ্রিবিএসডি তবে তাদের মধ্যে একটি নয়।
পদক্ষেপ 1 - আকর্ষণীয় ফাইল অন্য কোথাও অনুলিপি করুন।
পদক্ষেপ 2 - মূল হিসাবে

 $ grep -i tmp /etc/rc.conf  
 clear_tmp_enable="YES" # Clear /tmp at startup.  

পদক্ষেপ 3 - পুনরায় বুট করুন।
পদক্ষেপ 4 - ক্লিয়ার_টাম্প_এবল "না" এ ফিরে সক্ষম করুন।
অযাচিত ফাইলগুলি এখন ফ্রিবিএসডি- তে জেডএফএসের বৈশিষ্ট্য হিসাবে রয়েছে যে "ডেটাसेटে থাকা সমস্ত ফাইল মুছে ফেলার চেয়ে ডেটাসেট ধ্বংস করা তাত্ক্ষণিক, কারণ এতে সমস্ত ফাইল স্ক্যান করা এবং সংশ্লিষ্ট মেটাডেটা আপডেট করা জড়িত না। " সুতরাং বুট করার সময় যা করতে হয় তা হ'ল / টিএমপি ডেটাসেটের জন্য মেটাডেটা পুনরায় সেট করা। এটি খুব দ্রুত।

সমাধান 2) এটি এত ধীর কেন? জেডএফএস একটি দুর্দান্ত ফাইল সিস্টেম যা ধ্রুবক সময় ডিরেক্টরি অ্যাক্সেসের মতো বৈশিষ্ট্যগুলিকে অন্তর্ভুক্ত করে। আপনি কী করছেন তা যদি আপনি জানেন তবে এটি ভালভাবে কাজ করে তবে প্রমাণ থেকে বোঝা যায় যে ওপি কোনও জেডএফএস বিশেষজ্ঞ নয়। ওপিতে তারা কীভাবে ফাইলগুলি অপসারণের চেষ্টা করছে তা নির্দেশিত করেনি, তবে একটি অনুমানের ভিত্তিতে আমি বলব যে তারা "সন্ধানী রেজেক্স-এক্সেক আরএম {} \;" এ একটি প্রকরণ ব্যবহার করেছিল। এটি স্বল্প সংখ্যার সাথে ভাল কাজ করে তবে স্কেল করে না কারণ তিনটি ক্রমিক ক্রিয়াকলাপ চলছে 1) উপলব্ধ ফাইলগুলির তালিকা পান (হ্যাশ ক্রমে 30 মিলিয়ন ফাইল ফেরত দেয়), 2) পরবর্তী ফাইলটি মোছার জন্য বাছাই করার জন্য রেজেক্স ব্যবহার করুন, 3 ) ওএসকে 30 মিলিয়ন এর একটি তালিকা থেকে সেই ফাইলটি সন্ধান এবং অপসারণ করতে বলুন। এমনকি যদি ZFS মেমরি থেকে এবং একটি তালিকা ফেরৎ যদি এটি 'ক্যাশে' করে, রেজেক্সকে এখনও পরবর্তী ফাইলটি তালিকা থেকে প্রক্রিয়া করার জন্য চিহ্নিত করতে হবে এবং তারপরে ওএসকে তার পরিবর্তনটি প্রতিফলিত করতে তার মেটাডেটা আপডেট করতে এবং তারপরে তালিকাটি আপডেট করতে হবে যাতে এটি আবার প্রক্রিয়া করা হয় না।


1
আমি মনে করি আপনি প্রশ্নটি ভুল বুঝেছেন। আমার বেশিরভাগ ফাইল সরিয়ে ফেলা দরকার ছিল। অর্থাৎ 30M + ফাইল।
নাগিলিজ

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

ZFS ডিরেক্টরি হয় পাঁচমিশালী ? আমি ভেবেছিলাম zfs বিশেষত বড় ডিরেক্টরিগুলি পরিচালনা করে led
জেডিগোগস

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

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