ডিভিতে যখন প্রচুর পরিমাণে জায়গা থাকে তখন এমভি চলাকালীন কীভাবে মধ্যবর্তী "ডিভাইসে কোনও স্থান অবশিষ্ট থাকবে না" ত্রুটি সমাধান করা যায়?


21
  • একটি ডেস্কটপে উবুন্টু 14.04
  • উত্স ড্রাইভ: / dev / sda1: 5TB এক্সট 4 একক
    ড্রাইভ ভলিউম
  • টার্গেট ভলিউম: / ডিভ / ম্যাপার / আর্কাইভ-লাভারচাইভ: রেড 6 (এমডিএডিএম) lvm
    পার্টিশন এবং ext4 সহ 18 টিবি ভলিউম

সরানোর জন্য প্রায় 15 মিলিয়ন ফাইল রয়েছে এবং কয়েকটি ডুপ্লিকেট হতে পারে (আমি নকলকে ওভাররাইট করতে চাই না)।

ব্যবহৃত কমান্ড (উত্স ডিরেক্টরি থেকে) ছিল:

ls -U |xargs -i -t mv -n {} /mnt/archive/targetDir/{}

এটি প্রত্যাশার মতো কয়েক দিন ধরে চলছে, তবে ফ্রিকোয়েন্সি বাড়ানোর ক্ষেত্রে আমি ত্রুটি পাচ্ছি। যখন এটি শুরু হয়েছিল লক্ষ্য ড্রাইভটি প্রায় 70% পূর্ণ ছিল, এখন এটি প্রায় 90%। এটি প্রায় 1/200 মুভগুলি বলত এবং ত্রুটি করত, এখন এটি প্রায় 1/5। কোনও ফাইলই 100Mb এর বেশি নয়, বেশিরভাগই 100kb এর কাছাকাছি

কিছু তথ্য:

$ df -h
Filesystem                     Size  Used Avail Use% Mounted on
/dev/sdb3                      155G  5.5G  142G   4% /
none                           4.0K     0  4.0K   0% /sys/fs/cgroup
udev                           3.9G  4.0K  3.9G   1% /dev
tmpfs                          797M  2.9M  794M   1% /run
none                           5.0M  4.0K  5.0M   1% /run/lock
none                           3.9G     0  3.9G   0% /run/shm
none                           100M     0  100M   0% /run/user
/dev/sdb1                       19G   78M   18G   1% /boot
/dev/mapper/archive-lvarchive   18T   15T  1.8T  90% /mnt/archive
/dev/sda1                      4.6T  1.1T  3.3T  25% /mnt/tmp

$ df -i
Filesystem                       Inodes    IUsed     IFree IUse% Mounted on
/dev/sdb3                      10297344   222248  10075096    3% /
none                            1019711        4   1019707    1% /sys/fs/cgroup
udev                            1016768      500   1016268    1% /dev
tmpfs                           1019711     1022   1018689    1% /run
none                            1019711        5   1019706    1% /run/lock
none                            1019711        1   1019710    1% /run/shm
none                            1019711        2   1019709    1% /run/user
/dev/sdb1                       4940000      582   4939418    1% /boot
/dev/mapper/archive-lvarchive 289966080 44899541 245066539   16% /mnt/archive
/dev/sda1                     152621056  5391544 147229512    4% /mnt/tmp

এখানে আমার আউটপুট:

mv -n 747265521.pdf /mnt/archive/targetDir/747265521.pdf 
mv -n 61078318.pdf /mnt/archive/targetDir/61078318.pdf 
mv -n 709099107.pdf /mnt/archive/targetDir/709099107.pdf 
mv -n 75286077.pdf /mnt/archive/targetDir/75286077.pdf 
mv: cannot create regular file ‘/mnt/archive/targetDir/75286077.pdf’: No space left on device
mv -n 796522548.pdf /mnt/archive/targetDir/796522548.pdf 
mv: cannot create regular file ‘/mnt/archive/targetDir/796522548.pdf’: No space left on device
mv -n 685163563.pdf /mnt/archive/targetDir/685163563.pdf 
mv -n 701433025.pdf /mnt/archive/targetDir/701433025.pd

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

ধন্যবাদ।

সম্পাদনা: এখানে একটি নমুনা ব্যর্থ এবং সফল ফাইল রয়েছে:

ব্যর্থ (এখনও উত্স ড্রাইভ)

ls -lhs 702637545.pdf
16K -rw-rw-r-- 1 myUser myUser 16K Jul 24 20:52 702637545.pdf

সফল (লক্ষ্যমাত্রার উপর)

ls -lhs /mnt/archive/targetDir/704886680.pdf
104K -rw-rw-r-- 1 myUser myUser 103K Jul 25 01:22 /mnt/archive/targetDir/704886680.pdf

এছাড়াও, সমস্ত ফাইল ব্যর্থ না হওয়ার পরেও যে ফাইলটি ব্যর্থ হয় তা সর্বদা ব্যর্থ হয়। আমি যদি আবার চেষ্টা করি তবে এটি ধারাবাহিক।

সম্পাদনা: @mjturner দ্বারা অনুরোধ প্রতি কিছু অতিরিক্ত কমান্ড

$ ls -ld /mnt/archive/targetDir
drwxrwxr-x 2 myUser myUser 1064583168 Aug 10 05:07 /mnt/archive/targetDir

$ tune2fs -l /dev/mapper/archive-lvarchive
tune2fs 1.42.10 (18-May-2014)
Filesystem volume name:   <none>
Last mounted on:          /mnt/archive
Filesystem UUID:          af7e7b38-f12a-498b-b127-0ccd29459376
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              289966080
Block count:              4639456256
Reserved block count:     231972812
Free blocks:              1274786115
Free inodes:              256343444
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              128
RAID stripe width:        512
Flex block group size:    16
Filesystem created:       Thu Jun 25 12:05:12 2015
Last mount time:          Mon Aug  3 18:49:29 2015
Last write time:          Mon Aug  3 18:49:29 2015
Mount count:              8
Maximum mount count:      -1
Last checked:             Thu Jun 25 12:05:12 2015
Check interval:           0 (<none>)
Lifetime writes:          24 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      3ea3edc4-7638-45cd-8db8-36ab3669e868
Journal backup:           inode blocks

$ tune2fs -l /dev/sda1
tune2fs 1.42.10 (18-May-2014)
Filesystem volume name:   <none>
Last mounted on:          /mnt/tmp
Filesystem UUID:          10df1bea-64fc-468e-8ea0-10f3a4cb9a79
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              152621056
Block count:              1220942336
Reserved block count:     61047116
Free blocks:              367343926
Free inodes:              135953194
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      732
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         4096
Inode blocks per group:   256
Flex block group size:    16
Filesystem created:       Thu Jul 23 13:54:13 2015
Last mount time:          Tue Aug  4 04:35:06 2015
Last write time:          Tue Aug  4 04:35:06 2015
Mount count:              3
Maximum mount count:      -1
Last checked:             Thu Jul 23 13:54:13 2015
Check interval:           0 (<none>)
Lifetime writes:          150 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      a266fec5-bc86-402b-9fa0-61e2ad9b5b50
Journal backup:           inode blocks

ফাইলগুলি কি একাধিক ডিরেক্টরিতে অনুলিপি করা হচ্ছে, বা আপনি কোনও একক লক্ষ্য ডিরেক্টরিতে 1.5M ফাইল লেখার চেষ্টা করছেন?
স্নুপি

1.5 মি, 15 মি, এবং হ্যাঁ না, সমস্ত একই ডিরেক্টরিতে। প্রকৃতপক্ষে সেখানে 40 মিলিয়ন এরও বেশি রয়েছে, এবং মোট যেতে প্রায় 30 মিটার বেশি।
ক্রিস.ক্যালডওয়েল

ওহ, দেখুন এলোমেলো ডাউনভোট ট্রল আবার আঘাত হানে। আমি অনুমান করি না যে আপনি কেন ডাউনটोट করেছেন তা উল্লেখ করা আপনার যত্ন নেবে?
ক্রিস.ক্যালডওয়েল

1
ডাউন ভোটটি সম্ভবত কারণ আপনার প্রশ্নটি ইউনিক্স.স্ট্যাকেক্সচেঞ্জ বা জিজ্ঞাসুবন্টুর পক্ষে উপযুক্ত কারণ এটি প্রোগ্রামিং সম্পর্কিত নয়। যদি আপনার ট্যাগগুলিতে কোনও প্রোগ্রামিং ভাষা না থাকে তবে এটি সম্ভবত ডাউন ভোট পাবে।
টেকনোসরাস

@ ক্রিস - এসএফ-তে এই ইস্যুটির সাথে সমান বলে মনে হচ্ছে: সার্ভারফ্রন্ট
স্নোপি

উত্তর:


25

dir_indexআপনি আপনার গন্তব্য ফাইল সিস্টেমে ব্যবহার করছেন যে ext4 বৈশিষ্ট্যটির বাস্তবায়নে ত্রুটি ।

সমাধান: dir_index ছাড়াই ফাইলসাইম পুনরায় তৈরি করুন। বা অক্ষম বৈশিষ্ট্য tune2fs ব্যবহার (কিছু সাবধানতা প্রয়োজন, দেখতে সংশ্লিষ্ট লিংক নোভেল SUSE 10/11: অক্ষম এইচ-বৃক্ষ ইন্ডেক্সিং একটি, ext3 ফাইলসিস্টেম-এর যা যদিও সম্পর্কিত , ext3 অনুরূপ সাবধানতা প্রয়োজন হতে পারে।

(get a really good backup made of the filesystem)
(unmount the filesystem)
tune2fs -O ^dir_index /dev/foo
e2fsck -fDvy /dev/foo
(mount the filesystem)

ডিফল্টরূপে ext4- র একটি বৈশিষ্ট্য রয়েছে যা হ্যাশ-সংঘর্ষের জন্য যথেষ্ট সংবেদনশীল।

......

ext4 এর সামগ্রীর ফাইলের নামগুলি হ্যাশ করার সম্ভাবনা রয়েছে has এটি কর্মক্ষমতা বাড়ায়, তবে একটি "ছোট" সমস্যা রয়েছে: এক্সট 4 এর হ্যাশটেবলটি বাড়বে না, যখন এটি পূরণ শুরু করে। পরিবর্তে এটি ফিরে আসে -ENOSPC বা "ডিভাইসে কোনও স্থান অবশিষ্ট নেই"।


3
ওহ ক্রেপ, এটি হুবহু মনে হচ্ছে এবং ঠিক করার মতো সম্পূর্ণ ব্যথার মতো। এটি পুনরায় খোলার প্রায় এক মাস। বিষয়বস্তু হারানো ছাড়া এটি করা যেতে পারে? আমি আগামীকাল dir_index ইত্যাদি নিয়ে গবেষণা করতে হবে। বাহ, এটা কখনই ভাবিনি।
ক্রিস.ক্যালডওয়েল

আপনি যদি চেষ্টা করতে চান তবে সূচকে অক্ষম করতে টিউন 2fs কমান্ডটি যুক্ত করা হয়েছে।
স্টিভ

6
ভাল স্পটেড @ স্টিভ দুর্ভাগ্যক্রমে বন্ধ dir_indexকরা সম্ভবত এক ডিরেক্টরিতে 70 মি ফাইলের সাহায্যে অ্যাক্সেস কর্মক্ষমতা হারাবে।
mjturner

3
হ্যাঁ। আমার শিখর পারফরম্যান্সের প্রয়োজন নেই, তবে প্রতিটি ফাইলের জন্য একটি fs অনুসন্ধান করা ভয়াবহ হবে। সুতরাং এখন আমি xfs বা 10k বা তাই সাবফোল্ডারগুলির একটি অ্যারে দেখছি। সাবফোল্ডারগুলি একটি যুক্তিসঙ্গত সমাধান, তবে ext4 এর সাথে আমি এখনও সংঘর্ষের ঝুঁকিটি চালাই। xfs একই সমস্যা থেকে ভুগছে না? আমি পড়লাম এটি একটি বি + গাছ ব্যবহার করে তবে এটির সংঘাত কখনও ঘটবে না তা নিশ্চিত করে আমার পক্ষে এতটা অর্থ হয় না। সেখানে ভুল তথ্য রচনার একটি পৃথিবী আছে, এবং আমি দাবি শুনেছি যে এটি মিলিয়ন ফাইলের চেয়ে যথেষ্ট ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে।
ক্রিস.ক্যালডওয়েল

2
আমি মনে করি এটি একটি দুর্দান্ত উত্তর, এবং আইডি এটির মতো চিহ্নিত করতে পছন্দ করে, তবে আমি মনে করি এটি কেবল ভাল হবে যদি আমরা কেবল কোনও রোগ নির্ণয়ের জন্যই স্থির না হয়ে যাই। Xfs এই জাতীয় কিছুতে ভুগছে কিনা তা কি কেউ জানেন? আমি মিশ্র পর্যালোচনাগুলি পড়েছি যে এটি 1 মিটারের বেশি নয়, এটি জরিমানা করে।
ক্রিস.ক্যাল্ডওয়েল

8

ছোট ফাইলের জনসাধারণের জন্য অতিরিক্ত -4-এর চেয়ে ভাল বিকল্পগুলির জন্য পরামর্শগুলি:

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

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

সুইফ্ট আপনার জন্য প্রতিলিপি / লোড-ব্যালেন্সিং করে এবং আপনাকে পরামর্শ দেয় যে আপনি এটিকে RAID নয় , কাঁচা ডিস্কগুলিতে তৈরি ফাইল- সিস্টেমগুলি দিন । এটি উল্লেখ করে যে এর কাজের চাপ মূলত RAID5 এর জন্য সবচেয়ে খারাপ-পরিস্থিতি (যা আমরা যদি ছোট ফাইলগুলি লেখার সাথে কোনও কাজের চাপের কথা বলি তবে তা বোঝা যায় X এক্সএফএস সাধারণত তাদের মাথার টু লেজ প্যাক করে না, তাই আপনি করবেন না ফুল স্ট্রিপ লেখার জন্য পান এবং প্যারিটি স্ট্রিপ আপডেট করার জন্য RAID5- র কিছু পাঠ করা দরকার। সুইফ্ট ডক্সে প্রতি ড্রাইভে 100 পার্টিশন ব্যবহার করার কথা বলা হয়েছে I SATA ডিস্ক।

প্রতিটি ডিস্কের জন্য পৃথক এক্সএফএস চালানো আসলে একটি বিশাল পার্থক্য । একটি বিশাল ফ্রি-ইনোড মানচিত্রের পরিবর্তে প্রতিটি ডিস্কে পৃথক ফ্রি-তালিকা সহ পৃথক এক্সএফএস থাকবে। এছাড়াও, এটি ছোট লেখার জন্য RAID5 জরিমানা এড়ায়।

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

প্রায় কোনও সাধারণ ফাইল সিস্টেমের সাহায্যে এটি এর মতো কাঠামো ব্যবহার করতে সহায়তা করবে

1234/5678   # nested medium-size directories instead of
./12345678   # one giant directory

সম্ভবত 10 কে এন্ট্রি যুক্তিসঙ্গত, সুতরাং আপনার অবজেক্ট নামগুলির 4 টি বর্ণের ভাল বিতরণ করা এবং সেগুলি ডিরেক্টরি হিসাবে ব্যবহার করা সহজ সমাধান। এটি খুব ভাল সুষম হতে হবে না। বিজোড় 100k ডিরেক্টরি সম্ভবত একটি লক্ষ্যযোগ্য সমস্যা হবে না এবং কিছু খালি ডিরেক্টরিও হবে না।

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

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

আমি জানি না বিটিআরএফএস এতে ভাল কিনা , তবে আমি মনে করি এটি হতে পারে। আমি মনে করি ফেসবুক কোনও কারণে তার শীর্ষস্থানীয় বিকাশকারীকে নিয়োগ দেয়। : পি আমি কিছু মানদণ্ড দেখেছি, যেমন লিনাক্স কার্নেল উত্সটি না পাওয়ার মতো জিনিস, বিটিআরএফগুলি ভাল করে does

আমি জানি যে রিসিফরা এই মামলার জন্য অনুকূলিত হয়েছিল, তবে এটি সবেমাত্র, যদি তা না হয় তবে আর রক্ষণাবেক্ষণ করা হয়। আমি সত্যিই রিসার 4 নিয়ে যাওয়ার পরামর্শ দিতে পারি না। যদিও এটি পরীক্ষা করা আকর্ষণীয় হতে পারে। তবে এটি এখন পর্যন্ত ভবিষ্যতের-প্রমাণ পছন্দ। আমি বয়স্ক রিসারফের উপর কর্মক্ষমতা হ্রাসের রিপোর্টগুলিও দেখেছি এবং কোনও ভাল ডিফ্র্যাগ সরঞ্জাম নেই। (গুগল filesystem millions of small files, এবং বিদ্যমান স্ট্যাকেক্সচেঞ্জের কয়েকটি উত্তর দেখুন))

আমি সম্ভবত কিছু অনুভব করছি, তাই চূড়ান্ত সুপারিশ: সার্ভারফল্টে এটি সম্পর্কে জিজ্ঞাসা করুন! যদি এখনই আমাকে কিছু বাছাই করতে হবে, আমি বলব বিটিআরএফএস ব্যবহার করে দেখুন, তবে নিশ্চিত হয়ে নিন যে আপনার ব্যাকআপ রয়েছে। (উদাহরণস্বরূপ, আপনি যদি বিটিআরএফএসের বিল্ট-ইন একাধিক ডিস্ক রিডানডেন্সি ব্যবহার করেন, এটি RAID এর উপরে চালানোর পরিবর্তে The


1
অনেক ধন্যবাদ. আমি অনেক লোককে সাব-ফোল্ডার ব্যবহার করতে দেখেছি এবং বাস্তবে কয়েক বছর আগে আমার কাছে আলাদা সেটআপে এই ধরণের সমাধান ছিল, তবে এটির অন্য স্তরটি আমি এড়াতে আশা করছিলাম। দেখে মনে হচ্ছে যে এটি ওভারহেডটি সেভাবে এটি করা থেকে নেই, তবে, কেবলমাত্র এই উদ্দেশ্যে কাজ করে এমন কোনও fs সন্ধানের চেয়ে অনেক কম হতে চলেছে। পুনরায়: এক্সএফএস, এটি আশ্চর্যজনক যে তার হাঁটু-ঝাঁকির উত্তরটি ঘন ঘন দেওয়া হওয়ার পরে ফাইলগুলির উচ্চ সংখ্যায় এটি এত খারাপ। বিটিআরএফএস, উইকি: "ডিরেক্টরি এন্ট্রি ডিরেক্টরি আইটেম হিসাবে উপস্থিত হয়, যার ডান হাতের কী মানগুলি তাদের ফাইলের নামের একটি সিআরসি 32 সি হ্যাশ"। আমাদের কি একই সমস্যা নেই?
ক্রিস.ক্যালডওয়েল

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

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

@ ক্রিস.ক্যালডওয়েল: আমার উত্তরটি সত্যই এটি প্রাসঙ্গিক কোনও প্রশ্নের কাছে অনুলিপি করা উচিত। কয়েকটি বিদ্যমান আছে। অবজেক্ট স্টোরেজ করার জন্য যা "অনুমিত" তা ব্যবহার করার জন্য আমি আগ্রহী ছিলাম এবং সুইফ্ট সম্পর্কে কিছু ডক্স পেয়েছি found স্পষ্টতই এটি এক্সএফএসে পৃথক ফাইল হিসাবে বস্তুগুলি সঞ্চয় করে (তবে প্রতিটি ডিস্কের জন্য পৃথক এক্সএফএসের সাহায্যে, রেড নয় red
পিটার কর্ডেস

1

এই ইস্যুটির জন্য নীচে আমি কী ঠিক করেছি (নীচের পদক্ষেপগুলির জন্য আপনার sudo অ্যাক্সেসের প্রয়োজন হতে পারে):

  1. ইনোডের ব্যবহৃত স্পেস ছিল 100% যা নীচের কমান্ড ব্যবহার করে পুনরুদ্ধার করা যেতে পারে

    ডিএফ -আই /

ফাইল সিস্টেম আইওডস আইওএস আইফ্রি আইইউএস% মাউন্ট করা আছে

/dev/xvda1            524288   524288  o     100% /
  1. আইনোটেডটি খালি করা দরকার, সুতরাং নীচের কমান্ডটি ব্যবহার করে এখানে এমন অনেকগুলি নোড রয়েছে এমন ফাইলগুলি সন্ধান করতে হবে:

এটি কোনও আইনের সাথে সমস্যা কিনা তা জানার চেষ্টা করুন:

df -ih

বড় বড় ইনোড গণনা সহ রুট ফোল্ডারগুলি সন্ধান করার চেষ্টা করুন:

for i in /*; do echo $i; find $i |wc -l; done

নির্দিষ্ট ফোল্ডারগুলি সন্ধান করার চেষ্টা করুন:

for i in /src/*; do echo $i; find $i |wc -l; done
  1. এখন আমরা ফোল্ডারে এতে প্রচুর পরিমাণে ফাইল শূন্য করে ফেলেছি। কোনও ত্রুটি এড়াতে নীচের আদেশগুলি একের পর এক চালান (আমার ক্ষেত্রে আসল ফোল্ডারটি ছিল / var / spool / clientmqueue):
find /var/spool/clientmqueue/ -type f -mtime +1050 -exec rm -f {} +

find /var/spool/clientmqueue/ -type f -mtime +350 -exec rm -f {} +

find /var/spool/clientmqueue/ -type f -mtime +150 -exec rm -f {} +

find /var/spool/clientmqueue/ -type f -mtime +50 -exec rm -f {} +
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.