ডিস্ক পূর্ণ, du আলাদা বলে। কীভাবে আরও তদন্ত করবেন?

Question

আমার কাছে একটি সার্ভারে একটি এসসিএসআই ডিস্ক রয়েছে (হার্ডওয়্যার রাইড 1), 32 জি, এক্স 3 ফাইলসাইট tem dfআমাকে বলে যে ডিস্কটি 100% পূর্ণ। আমি যদি 1 জি মুছে ফেলি তবে এটি সঠিকভাবে প্রদর্শিত হবে।

যাইহোক, যদি আমি একটি চালানো du -h -x /তারপর duআমাকে বলে যে শুধুমাত্র 12G ব্যবহৃত হয় (আমি ব্যবহার -xকারণ কিছু সাম্বা মাউন্ট)।

সুতরাং আমার প্রশ্ন ডু এবং ডিএফ কমান্ডের মধ্যে সূক্ষ্ম পার্থক্য সম্পর্কে নয় তবে কীভাবে আমি জানতে পারি যে এই বিশাল পার্থক্যের কারণ কী?

আমি মেশিনটিকে এমন একটি fsck জন্য পুনরায় বুট করেছি যা ডাব্লু / আউট ত্রুটিগুলিতে চলে গেছে। আমার কি দৌড়াতে হবে badblocks? lsofআমাকে কোনও খোলা মুছে ফেলা ফাইলগুলি দেখায় না, lost+foundখালি রয়েছে এবং বার্তাগুলির ফাইলে কোনও স্পষ্ট সতর্কতা / ভুল / ব্যর্থতার বিবৃতি নেই।

সেটআপটির আরও বিশদ জানতে দ্বিধা বোধ করুন।

Comments

এটি প্রশ্নের খুব কাছাকাছি: লিনাক্স - ডু বনাম ডিএফ পার্থক্য ( সার্ভারফ্লাট / প্রশ্ন / 7070০৯৮ / বিদ্যু- ভিএস- ডিএফ-ডিফারেন্স )। ওল্ডট্রোল উত্তর হিসাবে সমাধানটি ছিল একটি মাউন্ট পয়েন্টের নীচে ফাইলগুলি।

— ক্রিস টিং

Answer 1

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

Comments

ডিরেক্টরিগুলি আনমাউন্ট করার প্রয়োজন ছাড়াই আপনি এই লুকানো ফাইলগুলি সন্ধান করতে পারেন। নীচে মার্সেল জি এর উত্তরটি দেখুন যা কীভাবে ব্যাখ্যা করে।

— মহেশেভাত

আপনার উত্তরে এটি করার জন্য আপনার সিএলআই কমান্ডগুলি দেখা উচিত

— জোনাথন

আপনি যদি ভাবেন যে এটি আপনার পক্ষে কোনও অর্থবোধ করে না!

— ক্রিস ২

দ্রষ্টব্য: এই উত্তরটি মাউন্ট পয়েন্টগুলির নীচে অবস্থিত ফাইলগুলির বিষয়ে কথা বলছে (অর্থাত্ মূল ফাইল সিস্টেমের আড়ালে), মাউন্ট পয়েন্টগুলির মধ্যে নয় । (আমার মতো বোকা হয়ে

— উঠবেন

Answer 2

কোনও স্থানীয় সার্ভারে কোনও সমস্যা ট্র্যাক করার চেষ্টা করার সময় এই পৃষ্ঠায় হোঁচট খেয়েছে।

আমার ক্ষেত্রে df -hএবং du -shহার্ড ডিস্ক আকারের প্রায় 50% এর সাথে মিল নেই।

এটি অ্যাপাচি (httpd) বড় লগ ফাইলগুলি মেমরিতে রেখেছিল যা ডিস্ক থেকে মুছে ফেলা হয়েছে।

এই চলমান নিচে অনুসরণ করা হয়নি lsof | grep "/var" | grep deletedযেখানে /varপার্টিশন আমি পরিষ্কার করা প্রয়োজন ছিল।

আউটপুট এ জাতীয় লাইন দেখিয়েছে:
httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/apache/awstats_log (deleted)

এরপরে অ্যাপাচি ( service httpd restart) পুনরায় চালু করে পরিস্থিতিটি সমাধান করা হয়েছিল এবং মুছে ফেলা ফাইলগুলিতে থাকা লকগুলি সাফ করার অনুমতি দিয়ে 2 জিবি ডিস্কের স্থান সাফ করে দেওয়া হয়েছিল।

Comments

আমার জন্য, লকগুলি যেখানে আমি প্রোগ্রাম বন্ধ করার পরেও মুক্তি পায় না (জম্বি?)। আমাকে kill -9 'pid'তালা ছেড়ে দিতে হয়েছিল। উদাহরণস্বরূপ: আপনার httpd এর জন্য এটি হত kill -9 32617।

— মিকা

গৌণ দ্রষ্টব্য: আপনাকে সমস্ত ফাইল ফাইল বর্ণনাকারী lsofহিসাবে প্রদর্শিত হবে sudoবা না হতে পারে

— ক্রিসউইউ

আমি এইচ 2 এর সাথে ছুটে এসেছি, যা প্রতিদিন একটি লগফাইলে বেশ কয়েকটি জিগ যুক্ত করে। এইচ 2 (ধীর) পুনরায় চালু করার পরিবর্তে, আমি ব্যবহার করেছি sudo truncate -s0 /proc/(h2 PID)/(descriptor number obtained from ls /proc/h2pid/fd)।

— Desty

আমার ক্ষেত্রে, পুনরায় আরম্ভ httpdকরার পরেও স্থানটি প্রকাশিত হয় না। আমি যখন /etc/init.d/rsyslog restartএটি চালিয়েছি: ডি

— থানহ এনগুইন ভ্যান

আপনি গ্রেপগুলি এড়িয়ে যেতে পারেন এবং ঠিক তেমন করতে পারেন lsof -a +L1 /var, যেখানে এর -aঅর্থ এবং সমস্ত শর্ত (ডিফল্ট OR হয়), +L1মানে কেবলমাত্র 1 টিরও কম সংখ্যক লিঙ্কযুক্ত ফাইলগুলি তালিকা তৈরি করুন (অর্থাত, ওপেন ফাইল বর্ণনাকারী ফাইলগুলি মুছে ফেলা হয়েছে), এবং /varসেই মাউন্ট পয়েন্টের নীচে থাকা ফাইলগুলিতে সীমাবদ্ধ

— kbolino

Answer 3

আপনার "অনুপস্থিত" জায়গার সর্বাধিক সম্ভাব্য কারণ হিসাবে আমি ওল্ডট্রোলের জবাবের সাথে একমত।

লিনাক্সে আপনি সহজেই পুরো রুট পার্টিশনটি (বা অন্য কোনও পার্টিশন) আপনার ফাইল সিস্টেমে অন্য কোনও জায়গায় সহজেই পুনঃস্থাপন করতে পারেন / mnt উদাহরণস্বরূপ, কেবল একটি ইস্যু করুন

mount -o bind / /mnt

তাহলে আপনি একটি করতে পারেন

du -h /mnt

এবং আপনার স্থান ব্যবহার করে দেখুন।

PS: একটি নতুন উত্তর যুক্ত করার জন্য দুঃখিত এবং কোনও মন্তব্য নয় তবে এই পোস্টটি পড়ার জন্য আমার কিছু ফর্ম্যাটিং দরকার।

Comments

এই টিপ জন্য অনেক ধন্যবাদ। আমাকে ডাউনটাইম ছাড়াই আমার বড়, "লুকানো" ফাইলগুলি সন্ধান এবং মুছতে অনুমতি দিয়েছে!

— চয়নকারী

ধন্যবাদ - এটি দেখিয়েছে যে ডকার আমার হার্ড ড্রাইভটি /var/lib/docker/aufs/diff/

— ডিফগুলি

Answer 4

কি df -iবলে দেখুন । এটি হতে পারে যে আপনি ইনোডের বাইরে চলে গেছেন, যা যদি সেই ফাইল সিস্টেমে প্রচুর সংখ্যক ছোট ফাইল থাকে, যা সমস্ত উপলব্ধ স্থান ব্যয় না করে সমস্ত উপলব্ধ ইনড ব্যবহার করে।

Comments

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

— মার্সিন

Answer 5

আমার ক্ষেত্রে এটি বড় মুছে ফেলা ফাইলগুলির সাথে করতে হয়েছিল। এই পৃষ্ঠাটি খুঁজে পাওয়ার আগে এটি সমাধান করা মোটামুটি বেদনাদায়ক ছিল, যা আমাকে সঠিক পথে চালিত করেছে।

অবশেষে আমি ব্যবহার করে সমস্যাটি সমাধান করেছিলাম lsof | grep deleted, যা আমাকে দেখিয়েছিল যে কোন প্রোগ্রামটি দুটি খুব বড় লগ ফাইল (আমার উপলব্ধ 8 জিবি রুট পার্টিশনের মোট 5 জিবি) ধারণ করছে ing

Comments

এই উত্তরটি আমাকে বিস্মিত করে তোলে যে আপনি কেন রুট বিভাজনে লগ ফাইলগুলি সংরক্ষণ করছেন, বিশেষত একটি ছোট ... তবে তাদের প্রত্যেকের কাছে আমি মনে করি ...

— একটি সিএনএন

আমার অনুরূপ সমস্যা ছিল, আমি মুছে ফেলা ফাইলটি ব্যবহার করে এমন সমস্ত অ্যাপ্লিকেশন পুনরায় চালু করেছি, আমি অনুমান করি যে একটি জম্বি প্রক্রিয়া এখনও একটি বড় মুছে ফেলা ফাইলটিতে ধরে আছে

— user1965449

আমাদের ক্ষেত্রে এটি ছিল, একটি লগ প্রসেসিং লিনাক্স অ্যাপ্লিকেশন, ফাইলবিট হিসাবে রাখা ফাইলগুলি খোলা রাখে।

— পাইকলার

@ পাইক্লার আমাদের জন্য এটি ফাইলবিটও ছিল। ভকভগক!

— মারটিজন হিমেলস

Answer 6

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

Comments

ওপি বলেছে যে তিনি সিস্টেমটি পুনরায় চালু করবেন এবং সমস্যাটি অব্যাহত রয়েছে।

— ওল্ডট্রোল

আমার কাছে এমন জম্বি ছিল যেগুলি ফাইলগুলিতে লকগুলি ছাড়বে না, আমি kill -9 'pid'লকগুলি ছেড়ে দিতে এবং ডিস্কের স্থানটি ফিরে পেতে।

— মিকা

Answer 7

ডিস্কে লেখার সময় কোনও মৃত / স্তব্ধ প্রক্রিয়াটি লক হয়েছে কিনা তা দেখার চেষ্টা করুন: lsof | গ্রেপ "/ এমএনটি"

তারপরে আটকে থাকা কোনও পিআইডি হত্যার চেষ্টা করুন (বিশেষত "(মুছে ফেলা") এর শেষ হওয়া লাইনগুলি দেখুন)

Comments

ধন্যবাদ! আমি সন্ধান করতে পেরেছিলাম যে এসএফটিপি সার্ভার প্রক্রিয়াটি মুছে ফেলা ফাইলটি ধরে রেখেছে

— লাইওমি

Answer 8

বড় ফাইলগুলি খুঁজে পাওয়ার জন্য আমি আজ অবধি এটি সবচেয়ে সহজ পদ্ধতি!

আপনার রুট মাউন্টটি পূর্ণ / (মাউন্ট / রুট) পূর্ণ হলে এখানে একটি উদাহরণ রয়েছে:

সিডি / (সুতরাং আপনি মূলে আছেন)

ls | xargs du -hs

উদাহরণ আউটপুট:

 9.4M বিন
 63 এম বুট
 4.0K সিগ্রুপ
 680 কে দেব
 ৩১ মি ইত্যাদি
 6.3 জি বাড়ি
 313M lib
 32 এম lib64
 16 কে হারিয়েছে + পাওয়া গেছে
 61 জি মিডিয়া
 4.0K mnt
 113 এম অপ্ট
 du: access proc / 6102 / কার্য / 6102 / fd / 4 'অ্যাক্সেস করতে পারবেন না: এ জাতীয় কোনও ফাইল বা ডিরেক্টরি নেই
 0 প্রকল্প
 19M মূল
 840K রান
 19 এম এসবিন
 4.0 কে সেলিনাক্স
 4.0K srv
 25 জি স্টোর
 26M tmp

তারপরে আপনি লক্ষ্য করবেন যে স্টোরটি একটি সিডি / স্টোর থেকে বড়

এবং আবার চালান

ls | xargs du -hs

উদাহরণ আউটপুট: 
 109 এম ব্যাকআপ
 358M fnb
 4.0G iso
 8.0 কেএস
 16 কে হারিয়েছে + পাওয়া গেছে
 47M মূল
 11 এম স্ক্রিপ্ট
 79M tmp
 21 জি ভিএমএস

এক্ষেত্রে ভিএমএস ডিরেক্টরি হ'ল স্পেস হগ।

Comments

সরল সরঞ্জাম ব্যবহার করছেন না কেন baobab? (দেখুন marzocca.net/linux/baobab/baobab-getting-started.html )

— Yvan

এইচএম ls+ xargsওভারকিলের মতো বলে মনে হচ্ছে, du -sh /*নিজেরাই

— ঠিকঠাক

আপনি যদি এনসিডিইউ সম্পর্কে জানেন না ... আপনি পরে আমাকে ধন্যবাদ জানাতে পারেন: dev.yorhel.nl/ncdu

— ট্রয়

Answer 9

আমার জন্য, আমাকে চালানো দরকার sudo duকারণ এখানে প্রচুর পরিমাণে ডকার ফাইল ছিল /var/lib/dockerযে কোনও নন-সুডো ব্যবহারকারীর পড়ার অনুমতি নেই।

Comments

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

— রিচার্ড নিনাবার

Answer 10

আরও একটি সম্ভাবনা বিবেচনা করার বিষয়টি - আপনি যদি ডকার ব্যবহার করছেন তবে আপনার প্রায় একটি বড় বৈসাদৃশ্য দেখার গ্যারান্টিযুক্ত এবং আপনি ভলিউম মাউন্টগুলি ব্যবহার করে এমন একটি ধারকটির ভিতরে df / du চালান। ডকার হোস্টের একটি ভলিউমকে মাউন্ট করা ডিরেক্টরিগুলির ক্ষেত্রে ডিএফ HOST এর ডিএফ মোটের প্রতিবেদন করবে। আপনি যদি এটির বিষয়ে চিন্তা করেন তবে এটি স্পষ্ট। তবে আপনি যখন কোনও "ডিস্ক ভরাট পাতানো পাত্রে!" এর একটি প্রতিবেদন পাবেন, তখন নিশ্চিত হয়ে নিন যে আপনি ধারকটির ফাইলস্পেসের ব্যবহারটি এরকম কোনও কিছুর সাথে যাচাই করেছেন du -hs <dir>।

Answer 11

সুতরাং আমি সেন্টোস in-তেও এই সমস্যাটি পেয়েছি এবং ব্লিচবিত এবং পরিষ্কার / ইউএসআর এবং / ভেরির মতো একগুচ্ছ জিনিস চেষ্টা করার পরেও সমাধান পেয়েছি যদিও তারা কেবল প্রতিটি প্রায় 7G দেখিয়েছে। মূল পার্টিশনে ব্যবহৃত 50G এর 50G এখনও দেখানো হচ্ছে তবে কেবল 9G ফাইলের ব্যবহার দেখানো হয়েছে। লাইভ উবুন্টু সিডি চালান এবং আপত্তিকর 50 জি পার্টিশনটি আনমাউন্ট করে, টার্মিনালটি খোলেন এবং পার্টিশনে xfs_check এবং xfs_repair চালান। আমি তখন পার্টিশনটি পুনরায় স্মরণ করিয়েছি এবং আমার হারিয়ে যাওয়া + ডিরেক্টরিটি 40G-তে প্রসারিত হয়েছিল। হারানো + আকার অনুসারে সন্ধান করা হয়েছে এবং বাষ্পের জন্য একটি 38 জি পাঠ্য লগ ফাইল খুঁজে পেয়েছে যা কেবলমাত্র একটি এমপি 3 ত্রুটির পুনরাবৃত্তি করেছে। বড় ফাইলটি সরানো হয়েছে এবং এখন স্পেস রয়েছে এবং আমার ডিস্কের ব্যবহারটি আমার রুট পার্টিশনের আকারের সাথে সম্মত। আমি এখনও জানতে চাই যে কীভাবে বাষ্প লগটি এত বড় না হয় তা পেতে।

Comments

কর্মক্ষেত্রে কি আপনার সাথে এটি ঘটেছে? serverfault.com/help/on-topic

— ছানা

শুধু আমার বাড়ির কম্পিউটারে নেই।

— জাস্টিন চাদউইক

xfs_fsrআমাদের জন্য এই সমস্যাটি স্থির করুন

— দ্রুসকা

Answer 12

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

Answer 13

উত্পাদনেও আমাদের মতো একই ঘটনা ঘটেছে, ডিস্কের ব্যবহার 98% এ চলে গেছে। নিম্নলিখিত তদন্ত করেছেন:

ক) df -iইনোড ব্যবহার পরীক্ষা করার জন্য, ইনোডের ব্যবহার 6% ছিল তাই খুব কম ফাইল নয়

খ) মাউন্ট করা rootএবং লুকানো ফাইলগুলি পরীক্ষা করা। কোনও অতিরিক্ত ফাইল ফাইল করতে পারেনি । duফলাফল মাউন্ট হিসাবে আগের মত ছিল।

গ) অবশেষে, পরীক্ষিত nginxলগগুলি। এটি ডিস্কে লেখার জন্য কনফিগার করা হয়েছিল তবে কোনও বিকাশকারী nginxসমস্ত লগ-স্মৃতিতে রাখার কারণে লগ ফাইলটি সরাসরি মুছে ফেলে । যেহেতু ফাইলটি /var/log/nginx/access.logডিস্ক থেকে মুছে ফেলা হয়েছে rmএটি ব্যবহার করে দৃশ্যমান ছিল না duতবে ফাইলটি অ্যাক্সেস পেয়েছিল nginxএবং তাই এটি এখনও উন্মুক্ত ছিল

Answer 14

আমার একই সমস্যাটি ছিল যা এই বিষয়টিতে উল্লিখিত হয়েছে তবে একটি ভিপিএসে। সুতরাং আমি এই বিষয়ে বর্ণিত সমস্ত কিছুই পরীক্ষা করেছি তবে সাফল্য ছাড়াই। সমাধান আমাদের ভিপিএস প্রদানকারী এমন একজন কোটা: গণনার সঞ্চালিত এবং স্থান পার্থক্য সংশোধন সঙ্গে সমর্থনের জন্য একটি পরিচিতি ছিল df -hএবং du-sh /।

Answer 15

আমি আজ একটি ফ্রিবিএসডি বক্সে এই সমস্যায় পড়েছি। বিষয়টি হ'ল এটি একটি শৈল্পিক ছিল vi( vimনিশ্চিত নয় যে vimএই সমস্যাটি তৈরি করবে কিনা )। ফাইলটি স্থান গ্রহণ করছে তবে পুরোপুরি ডিস্কে লেখা হয়নি।

আপনি এটি দিয়ে যাচাই করতে পারেন:

$ fstat -f /path/to/mount/point |sort -nk8 |tail

এটি সর্বমোট দশটি আইটেম দেখিয়ে -n8 ম কলাম (কী, -k8) দ্বারা সমস্ত খোলা ফাইল এবং প্রকারের (সংখ্যার মাধ্যমে ) দেখায় ।

আমার ক্ষেত্রে, চূড়ান্ত (বৃহত্তম) প্রবেশদ্বারটি এরকম দেখাচ্ছে:

bob      vi         12345    4 /var      97267 -rwx------  1569454080 rw

এটি বোঝার প্রক্রিয়া (পিআইডি) 12345 ডিস্কটি duলক্ষ্য করার অভাব সত্ত্বেও 1.46G (1024³ দ্বারা বিভক্ত অষ্টম কলাম) গ্রাস করছিল । viঅত্যন্ত বড় ফাইলগুলি দেখে ভয়ঙ্কর; এমনকি এটির জন্য 100MB বড়। 1.5 জি (বা তবে বড় আকারের ফাইলটি আসলে ছিল) হাস্যকর।

সমাধানটি ছিল sudo kill -HUP 12345(যদি এটি কাজ না করে, আমি sudo kill 12345এবং এটিও যদি ব্যর্থ হয় তবে আতঙ্কিত হয়ে kill -9উঠবে)।

বড় ফাইলগুলিতে পাঠ্য সম্পাদকগুলি এড়ান। দ্রুত স্কিমিংয়ের জন্য নমুনা ওয়ার্কআউন্ডস:

যুক্তিসঙ্গত রেখার দৈর্ঘ্য ধরে নেওয়া:

• { head -n1000 big.log; tail -n1000 big.log } |vim -R -
• wc -l big.log |awk -v n=2000 'NR==FNR{L=$1;next}FNR%int(L/n)==1' - big.log |vim -R -

অযৌক্তিকভাবে বড় লাইন (গুলি) ধরে নেওয়া:

• { head -c8000 big.log; tail -c8000 big.log } |vim -R -

কারণ এটি ব্যবহারের vim -Rজায়গায় এটি প্রায় সর্বদা ভাল ... এটি ইনস্টল হওয়ার পরে। এগুলির পরিবর্তে বা পরিবর্তে এগুলিকে পাইপ করুন ।viewvimviewvi -R

যদি আপনি এটিকে সম্পাদনা করতে এত বড় ফাইলটি খোলেন তবে বিবেচনা করুন sedবা awkঅন্য কোনও প্রোগ্রাম্যাটিক অ্যাপ্রোচ।

Answer 16

আপনার সার্ভারে ওস্যাক এজেন্ট ইনস্টল আছে কিনা তা পরীক্ষা করুন। বা কিছু প্রসেস মুছে ফেলা লগ ফাইলগুলি ব্যবহার করছে। আমার এক সময় আগে অস্যাক্ট এজেন্ট ছিল।

Comments

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

— রালফ্রেডল

Answer 17

পাওয়া / হারিয়ে যাওয়া + পরীক্ষা করে দেখুন, আমার কাছে একটি সিস্টেম ছিল (সেন্টোস 7) এবং / হারানো + এর কিছু ফাইল সমস্ত জায়গা খেয়ে ফেলেছে।

Comments

প্রশ্নটিতে বর্ণিত ডিস্ক ব্যবহারের পার্থক্যের জন্য এই অ্যাকাউন্টটি কীভাবে হবে ?

— রোয়াইমা