"ডিভাইসে কোনও স্থান বাকি নেই" এর জন্য অন্য কোনও কারণ আছে কি?

Question

আমি বাইরের ইউএসবি 3.0 ড্রাইভে কোনও এইচডি ব্যাক আপ করার জন্য একটি উবুন্টু সার্ভার সিস্টেমে ডারভিশ ব্যবহার করছি। কিছু দিন আগে পর্যন্ত, সবকিছু ঠিকঠাক কাজ করেছিল, তবে এখন প্রতিটি ব্যাকআপ "ডিভাইসে কোনও স্থান বাকি নেই (28)" এবং "ফাইল সিস্টেম পূর্ণ" ails দুর্ভাগ্যক্রমে এটি এত সহজ নয়: ডিভাইসে> 500 জিবি নিখরচায় রয়েছে।

বিবরণ:

rsync_error:

rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename1>.eDJiD9": No space left on device (28)
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename2>.RHuUAJ": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename3>.9tVK8Z": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename4>.t3ARSV": No space left on device (28)
[... some more files ...]
rsync: connection unexpectedly closed (2712185 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]

লগটি হিট না হওয়া অবধি স্বাভাবিক হিসাবে বেশ দেখাচ্ছে:

<SomeFilename1>
<SomeFilename2>
<SomeFilename3>
<SomeFilename4>
<PartOfAFilename>filesystem full
write error, filesystem probably full
broken pipe
RESULTS: warnings = 0, errors = 1

তবে উপরে যেমন বলা হয়েছে, ডিভাইসে প্রচুর জায়গা রয়েছে:

df -h
/dev/sdg1       2.7T  2.0T  623G  77% /mnt/backupsys/shd

এবং প্রচুর আইনোড বাকি আছে:

df -i
/dev/sdg1      183148544 2810146 180338398    2% /mnt/backupsys/shd

ডিভাইসটি rw হিসাবে মাউন্ট করা হয়েছে:

mount
/dev/sdg1 on /mnt/backupsys/shd type ext3 (rw)

প্রক্রিয়াটি মূল হিসাবে চলছে।

আমি বলতে যাচ্ছিলাম যে আমি কিছুই পরিবর্তন করি নি তবে এটি সত্য নয়: আমি যে ড্রাইভটি ব্যাক আপ করছি তার জন্য আমি এসিএল চালু করেছি:

/dev/md0 on /mnt/md0 type ext4 (rw,acl)

সেটা কি সমস্যা হতে পারে? যদি হ্যাঁ, কিভাবে? রুটটিতে এখনও ফাইলগুলিতে সম্পূর্ণ অ্যাক্সেস রয়েছে।

সম্পাদনা করুন:

আমি কেবল অস্থায়ী ডিরেক্টরিগুলি পরীক্ষা করেছি:

• / টিএমপি-তে কেবল একটি .webmin ফোল্ডার থাকে যা খালি
• / var / tmp খালি আছে

এই ডিরেক্টরিতে থাকা ফাইল সিস্টেমে প্রচুর পরিমাণে ফাঁকা জায়গা এবং ইনোড রয়েছে:

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       289G   55G  220G  20% /

df -i
Filesystem        Inodes   IUsed     IFree IUse% Mounted on
/dev/sda1       19202048  167644  19034404    1% /

EDIT2:

ডিরেক্টরিগুলি বেশ বড় তবে 2 জিবি নয়। ব্যাকআপ ব্যর্থ হ'ল এটির মধ্যে একটিও বড় নয়, এটিতে 7530 ফাইল রয়েছে।

EDIT3:

একটি প্রশ্ন যা আমি এই প্রশ্ন পোস্ট করার সময় প্রাসঙ্গিক বিবেচনা করি নি:

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

আজ একটি খালি ডিস্কে একটি পূর্ণ ব্যাকআপ নির্দোষভাবে কাজ করেছে। আমি পরবর্তীতে একটি ইনক্রিমেন্টাল ব্যাকআপ চেষ্টা করব। এটি দেখায় যে অ্যাকসিলগুলি অ্যাক্টিভেট করা সমস্যার কারণ ছিল whether

Comments

সম্পর্কিত: স্ট্যাকওভারফ্লো

— সেকশনস / 24671621/no-space-left-on-device

Answer 1

আমার সন্দেহ (EDIT3 দেখুন) আপাতদৃষ্টিতে ঠিক ছিল: ফাইল সিস্টেমে এসিএল সমর্থন যুক্ত করার ফলে rsync / dirvish বলে মনে হয় যে সমস্ত ফাইল পরিবর্তিত হয়েছিল। সুতরাং একটি ইনক্রিমেন্টাল ব্যাকআপ তৈরি না করে এবং ইতিমধ্যে বিদ্যমান ফাইলগুলিতে কেবলমাত্র হার্ড লিঙ্ক তৈরি করার পরিবর্তে এটি একটি সম্পূর্ণ ব্যাকআপ তৈরি করার চেষ্টা করেছিল যা অবশ্যই ব্যর্থ হয়েছিল কারণ হার্ডডিস্কটির পক্ষে পর্যাপ্ত স্থান ছিল না।

সুতরাং ত্রুটি বার্তাটি আসলে সঠিক ছিল।

খালি ব্যাকআপ ডিস্ক দিয়ে আবার শুরু করার পরে, ইনক্রিমেন্টাল ব্যাকআপগুলি আগের মতো কাজ করেছিল।

Answer 2

বাম 2% আইওডের দিকে তাকানো আমাকে এক্সট ফাইল সিস্টেমের দ্বারা আরোপিত মূল সংরক্ষণাগার সম্পর্কে ভাবতে বাধ্য করে। আপনি এগুলি পরীক্ষা করে দেখতে চাইতে পারেন:

1. " একটি ফাইল সিস্টেমে মূলের জন্য সংরক্ষিত স্থান - কেন? "
2. " নন-ওএস ডিস্কের জন্য" ফাইল সিস্টেম সংরক্ষিত ব্লকগুলির "জন্য যুক্তিসঙ্গত আকার? "

আমি পুরানো ব্যাকআপগুলির কয়েকটি .tar.gz চেষ্টা করে দেখব যে এটি ব্যবহারে ইনোডের সংখ্যা হ্রাস করবে।

Comments

dfআউটপুট -এর আগের-শেষ কলামটি ব্যবহৃত আইওনডের শতাংশ, সুতরাং 2% ইনোড ব্যবহৃত হয়, এবং 98% বাকি থাকে।

— দেভে

Answer 3

আমি দেখতে পাচ্ছি যে ডাম্মুজুচ তার সমস্যার সমাধান খুঁজে পেয়েছে তবে বাস্তবে আমি আরও একটি কেস পেয়েছি যেখানে ডিস্কে পর্যাপ্ত ইনোড / ফ্রি স্পেস থাকতে পারে এবং নির্দিষ্ট ডিরেক্টরি স্থানান্তর করার চেষ্টা করার পরেও "ডিভাইসে কোনও স্থান অবশিষ্ট নেই" দেখায়।

এটি ext4 ফাইল সিস্টেমের সাথে ফর্ম্যাট হওয়া ব্লক ডিভাইসে হ্যাশ সংঘর্ষের কারণে ঘটে যেখানে ডিরেক্টরি সূচীকরণ সক্ষম করা হয় বিশেষত যেখানে একক ডিরেক্টরি এতে 100k এর বেশি ফাইল হোস্ট করে এবং ফাইলগুলির নাম একই অ্যালগরিদম থেকে তৈরি করা হয় (ক্যাশে ফাইল, এমডি 5সাম ফাইলের নাম ইত্যাদি) ।)

সমাধানটি অন্য ডিরেক্টরি সূচীকরণ অ্যালগরিদম দিয়ে চেষ্টা করার চেষ্টা করা হয়:

tune2fs -E "hash_alg=tea" /dev/blockdev_name

বা block ব্লক ডিভাইসের জন্য সম্পূর্ণ ডিরেক্টরি সূচক অক্ষম করতে (কার্যকারিতা ক্ষতিগ্রস্থ করতে পারে)

tune2fs -O ^dir_index /dev/blockdev_name

আর একটি সমাধান হ'ল এই জাতীয় ফাইলগুলির সাহায্যে ডিরেক্টরিটি কী পূরণ করা হচ্ছে তা এবং সফ্টওয়্যারটি ঠিক করা।

সম্ভাব্য সমাধান হ'ল ফোল্ডারের বিশাল আকারের ফাইলগুলির একাধিক পৃথক সাবফোল্ডারগুলিতে বিভক্ত সামগ্রী।

সমস্যার পুরো বিবরণটি এখানে এক্সেল ওয়াগনার উপস্থাপন করেছেন

http://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html

চিয়ার্স।

Answer 4

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

সুতরাং এটি খুব বেশি সাহায্য নাও করতে পারে - তবে আপনার ব্যাকআপ ডিভাইসে এক্সট 4 ব্যবহার করে দেখুন?

Comments

ডিরেক্টরিগুলি এত বড় নয়। বীজ সম্পাদনা।

— dummzeuch

আপনার সম্পাদনাগুলি ডিরেক্টরিগুলির প্রকৃত আকার দেখায় না। এটি ব্যবহার করে দেখুন: find /mnt/backupsys/shd -type d -exec ls -ld {} \;ডিরেক্টরিগুলির আসল আকার দেখতে।

— জেনি ডি

Answer 5

সিস্টেটিলে আপনার ইনোটাইফাই প্রহরীদের সীমা বাড়ান:

fs.inotify.max_user_watches = 100000 

এবং পুনরায় বুট করুন, বা এর sysctl -wসংস্করণও করুন।

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

Comments

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

— dummzeuch

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

— স্টিভ

Answer 6

আমি আপনাকে অন্য কয়েকটি জিনিস পরীক্ষা করার পরামর্শ দিচ্ছি:

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

Comments

পরীক্ষিত / tmp এবং / var / tmp। সম্পাদনাগুলি দেখুন।

— dummzeuch

কোটা (ব্যবহারকারীর সীমা) দেখুন। আপনি স্থানীয় ব্যাকআপের জন্য কেন rsync ব্যবহার করছেন তা নিশ্চিত নয়। : ~ /

— ডেনিস

Answer 7

আমার সমস্যার সমাধান অনুসন্ধান করার সময় আমি এই বিষয়টি সবেমাত্র পেয়েছি।

প্রকৃতপক্ষে ENOSPC এর অন্যান্য কারণের জন্য কমপক্ষে রয়েছে। এবং আমি এটি জেএসএফএস ফাইল সিস্টেম থেকে একটি এক্সটি 4 এ অনুলিপি করার সময় আরএসসিএন-র সাথেও জোর দিয়েছি:

rsync: rsync_xal_set: lsetxattr(""/my/file/path"","example.xattr.attribute") failed: No space left on device (28)

এক্ষেত্রে:

   ENOSPC - There is insufficient space remaining to store the extended attribute.

man 7 xattr ব্যাখ্যা করে:

   In the current ext2, ext3, and ext4 filesystem implementations, the total bytes used by the names and values of all of a file's extended attributes
   must fit in a single filesystem block (1024, 2048 or 4096 bytes, depending on the block size specified when the filesystem was created).

আমার ক্ষেত্রে, এর অর্থ হল আমাকে পুরো ফাইল সিস্টেমটি পুনরায় ফর্ম্যাট করতে হবে। :-(