শিংলেড ডিস্কে দ্রুততম লিনাক্স ফাইল সিস্টেম


13

শিংলড ড্রাইভগুলিতে যথেষ্ট আগ্রহ রয়েছে। এগুলি ডেটা ট্র্যাকগুলি একসাথে এতটা সংযুক্ত করে রাখে যে আপনি পরের ক্লোবার্বিং না করে কোনও ট্রাকে লিখতে পারবেন না। এটি 20% বা ততোধিক ক্ষমতা বাড়িয়ে তুলতে পারে, তবে ফল লেখার সমস্যাগুলিতে ফল দেয়। শিংলেড ড্রাইভগুলির জন্য অনুকূলিত ফাইল সিস্টেমগুলির কাজ চলছে, উদাহরণস্বরূপ দেখুন: https://lwn.net/Articles/591782/

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

লিনাক্স কার্নেলের একটি মূলধারার ফাইল সিস্টেমটি এক্সপ্লোরেশনের চেয়ে শিংলেড ডিস্কের পারফরম্যান্স পেনাল্টি এড়ানো আরও ভাল ?


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

আমি এফএসকে মূলধারার মধ্যে সীমাবদ্ধ রেখেছি, এটি সম্ভবত সিগেট শৈলী হতে হবে?
gmatht

বর্তমান ড্রাইভে প্রয়োগ করা এসএমআর এর ফলে "এসএসডি-র মতো এমপ্লিফিকেশন সমস্যাগুলি লিখুন" " তারা কেবল এসএসডি এর মতো অস্পষ্টভাবে খুব অল্প কিছু উপায়ে পরিচালনা করে ।
qasdfdsaq

@ কাসদফডসাক আমার অর্থ "এসএসডি'র মতো"।
gmatht

উত্তর:


4

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

Nilfs2 ফাইল সিস্টেম এসএমআর ডিস্কে বেশ ভাল পারফরম্যান্স দিয়েছে। যাইহোক, এটি কারণ আমি পুরো 8 টিবি বিভাজন বরাদ্দ করেছি, এবং বেলমার্ক কেবল ~ 0.5TB লিখেছিল যাতে নীলফ ক্লিনারটি চালাতে না পারে। আমি যখন পার্টিশনটি 200 জিবিতে সীমাবদ্ধ করেছি তখন নীলফস বেঞ্চমার্কগুলি সফলভাবেও শেষ হয় নি। নীলফএস 2 আপনি পছন্দ করতে পারেন তবে আপনি যদি সংরক্ষণাগার ডিস্ক হিসাবে "সংরক্ষণাগার" ডিস্কটি সত্যই ব্যবহার করেন যেখানে আপনি সমস্ত ডেটা এবং স্ন্যাপশটকে চিরতরে ডিস্কে রাখেন, ততক্ষণে নীলফ ক্লিনারটি চালাতে হবে না।


আমি বুঝতে পারি যে ST8000AS0002-1NA17Zপরীক্ষার জন্য আমি 8TB সিগেট ড্রাইভটি ব্যবহার করেছি GB 20 গিগাবাইটের ক্যাশে অঞ্চল। আমি ডিফল্ট ফাইলবেঞ্চ ফাইলসার্ভার সেটিংস পরিবর্তন করেছি যাতে বেঞ্চমার্ক সেটটি sh 125 গিগাবাইট হয়ে যায়, আনশিলিং ক্যাশে অঞ্চল থেকে বড়:

set $meanfilesize=1310720
set $nfiles=100000
run 36000

এখন আসল তথ্য জন্য। অপশনের সংখ্যা "সামগ্রিক" ফাইলসার্ভার কর্মক্ষমতা পরিমাপ করে যখন এমএস / ওপেন এলোমেলোভাবে সংযোজনটির বিলম্বকে পরিমাপ করে এবং এলোমেলো লেখার পারফরম্যান্সের জন্য একটি রুক্ষ গাইড হিসাবে ব্যবহৃত হতে পারে।

$ grep rand *0.out | sed s/.0.out:/\ / |sed 's/ - /-/g' |  column -t
SMR8TB.nilfs   appendfilerand1   292176ops 8ops/s   0.1mb/s   1575.7ms/op    95884us/op-cpu [0ms - 7169ms]
SMR.btrfs      appendfilerand1  214418ops  6ops/s   0.0mb/s  1780.7ms/op  47361us/op-cpu  [0ms-20242ms]
SMR.ext4       appendfilerand1  172668ops  5ops/s   0.0mb/s  1328.6ms/op  25836us/op-cpu  [0ms-31373ms]
SMR.xfs        appendfilerand1  149254ops  4ops/s   0.0mb/s  669.9ms/op   19367us/op-cpu  [0ms-19994ms]
Toshiba.btrfs  appendfilerand1  634755ops  18ops/s  0.1mb/s  652.5ms/op   62758us/op-cpu  [0ms-5219ms]
Toshiba.ext4   appendfilerand1  466044ops  13ops/s  0.1mb/s  270.6ms/op   23689us/op-cpu  [0ms-4239ms]
Toshiba.xfs    appendfilerand1  368670ops  10ops/s  0.1mb/s  195.6ms/op   19084us/op-cpu  [0ms-2994ms]

যেহেতু সীগেটটি 5980RPM হ'ল একরকমভাবে সম্ভবত তোশিবা 20% দ্রুত হওয়ার আশা করতে পারে। এই মানদণ্ডগুলি এটিকে প্রায় 3 বার (200%) দ্রুত হিসাবে দেখায়, তাই এই মানদণ্ডগুলি দ্যুতিযুক্ত পারফরম্যান্স পেনাল্টিকে আঘাত করছে। আমরা দেখতে পাই শিংলেড (এসএমআর) ডিস্কটি এখনও আনশিলিংহীন (পিএমআর) ডিস্কের সাথে এক্সটোর 4 পারফরম্যান্সের সাথে মেলে না। সেরা পারফরম্যান্সটি 8 টিবি বিভাজন সহ নীলফস 2 এর সাথে ছিল (সুতরাং ক্লিনারটি চালানোর দরকার ছিল না), তবুও এটি এক্সপি 4 সহ তোশিবার তুলনায় উল্লেখযোগ্যভাবে ধীর ছিল।

উপরের বেঞ্চমার্কগুলিকে আরও স্পষ্ট করে তুলতে, এটি প্রতিটি ডিস্কে ext4 এর পারফরম্যান্সের তুলনায় এগুলি স্বাভাবিক করতে সহায়তা করতে পারে:

                ops     randappend
SMR.btrfs:      1.24    0.74
SMR.ext4:       1       1
SMR.xfs:        0.86    1.98
Toshiba.btrfs:  1.36    0.41
Toshiba.ext4:   1       1
Toshiba.xfs:    0.79    1.38

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

আমি একটি অ্যাটিক ভিত্তিক বেঞ্চমার্কও চালাতাম। অ্যাটিক রানগুলির মেয়াদ (8 টিবি এসএমআর পূর্ণ ডিস্ক পার্টিশনগুলিতে) ছিল:

ext4:  1 days 1 hours 19 minutes 54.69 seconds
btrfs: 1 days 40 minutes 8.93 seconds
nilfs: 22 hours 12 minutes 26.89 seconds

প্রতিটি ক্ষেত্রে অ্যাটিক সংগ্রহস্থলের নিম্নলিখিত পরিসংখ্যান ছিল:

                       Original size      Compressed size    Deduplicated size
This archive:                1.00 TB            639.69 GB            515.84 GB
All archives:              901.92 GB            639.69 GB            515.84 GB

অ্যাটিকে একই 1 টিবি ডিস্কের একটি দ্বিতীয় অনুলিপি যুক্ত করতে এই তিনটি ফাইল সিস্টেমের প্রতিটিটিতে 4.5 ঘন্টা সময় নিয়েছে। মানদণ্ড এবং smartctlতথ্যের একটি কাঁচা ডাম্পটি এখানে রয়েছে: http://pastebin.com/tYK2Uj76 https://github.com/gmatht/joshell/tree/master/benchmark/SMR


আপনি কি নিশ্চিত যে এই পার্থক্যগুলি এসএমআর বনাম পিএমআরের সাথে সুনির্দিষ্ট?
আরজে-

আসলে তা না. আমি এই জাতীয় প্রশ্নের উত্তর দেওয়ার জন্য তাদের যেমন করি তেমন আমি আরও বেঞ্চমার্ক যুক্ত করব, তবে বেশি মানদণ্ডের অভিজ্ঞতা সম্পন্ন কেউ আমার চেয়ে আরও ভাল কাজ করতে পারে। আশা করা যায় এটি একটি এসএমআর ডিস্কে ext4 থেকে স্যুইচ করা বিবেচনা করা উপযুক্ত কিনা তা মোটামুটি ধারণা দেওয়ার জন্য এটি যথেষ্ট।
gmatht

3
Shingled ডিস্ক না না লেখার উপর কপি ব্যবহার করেন। তারা RAID-5 অ্যারেগুলিকে আংশিক লেখার মতোই পঠন-পরিবর্তন-লেখাকে ব্যবহার করে। এলোমেলো লিখেছেন এসএমআর ডিস্কগুলিকে ধীর করবেন না , বাস্তবে এটি তাদের গতি বাড়ায়। 6000RPM এসএমআর ড্রাইভগুলি এলোমেলো রাইটে 10x দ্রুততর 15000 আরপিএম নন-এসএমআর ড্রাইভের চেয়ে বেশি দীর্ঘ হয় যতক্ষণ এটি ক্যাশে ফিট হয়, যা আসলে 30 জিবি।
qasdfdsaq

@ কাসদফডসাক ধন্যবাদ, আমি CoW এর রেফারেন্স সরিয়ে দিয়েছি। আমি বুঝতে পারি যে প্ল্যাটারের স্তরে শিংলেড ড্রাইভগুলি পিএমআরের তুলনায় এলোমেলো লেখার জন্য অনেক ধীর, তবে এসএমআর ক্যাশের কারণে দ্রুত লেখার অনুকরণ করতে পারে; একটি পিএমআর ড্রাইভ + ক্যাশে সম্ভবত আবার দ্রুত হবে। আপনার কাছে 30 জিবি চিত্রের জন্য কোনও রেফারেন্স রয়েছে? কোনও অফিসিয়াল নম্বর বলে মনে হচ্ছে না, যেমন সীগেটের প্রযুক্তিগত বৈশিষ্ট্যগুলি। এছাড়াও, দ্যুতিযুক্ত ড্রাইভগুলির জন্য অনুকূলকরণ করা RAID 5 অ্যারে অনুকূলকরণের অনুরূপ সমস্যা হতে পারে?
gmatht

1
আমি বিষয়টিতে কিছু এলোমেলো অনুসন্ধান করছি এবং f2fs- তে একটি ব্লগ পোস্ট জুড়ে এসেছি: blog.schmorp.de/2015-10-08-smr-archive-drives-fast-now.html
লেস্টার চিউং

1

আপনি যদি একটি এসএমআর ড্রাইভ rsync থেকে থাকেন তবে নিশ্চিত করুন যে ফাইল সিস্টেমটি মাউন্ট করা হয়েছে read-onlyবা noatimeবিকল্পের সাথে।

অন্যথায় এসএমআর ড্রাইভটিতে প্রতিটি ফাইল আরএসসিএন পঠনের জন্য টাইমস্ট্যাম্প লিখতে হবে, যার ফলে একটি উল্লেখযোগ্য কর্মক্ষমতা হ্রাস পেতে পারে (প্রায় ৮০ এমবি / এস থেকে এখানে প্রায় 3-5 এমবি / এস পর্যন্ত) এবং মাথা পরিধান / ক্লিকের শব্দ।

আপনার যদি ইতিমধ্যে কোনও খারাপ কাজ সম্পাদন করে একটি rsync কাজ চলছে তবে এটি বন্ধ করার দরকার নেই, আপনি উত্স ফাইল সিস্টেমটি পুনরায় গণনা করতে পারবেন

sudo mount -o remount,ro  /path/to/source/fs

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


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

sudo mount -t fs_type -o rw,noatime device /path/to/dest/fs

এটি করতে হবে, আরএসসিএন চালানোর আগে; অন্যান্য উপাদানগুলি এই বিকল্পটিকে তুচ্ছ হিসাবে রেন্ডার করতে পারে, যেমন আনফারড এফএটি / এমএফটি আপডেটিং, ফাইলসিস্টেমটি প্রাথমিকভাবে এসএসডি ইত্যাদির জন্য অনুকূলিত করা হলে সমান্তরালভাবে লেখেন etc.


dd bs=32Mএসএমআর টার্গেটে ফাইল সিস্টেমটি ব্যবহার করার চেষ্টা করুন এবং তারপরে পুনরায় আকার দিন, যদি আপনি যে কোনও উপায়ে পূর্ণ ফাইল সিস্টেমকে ব্যাকআপ করতে চান (এই ক্ষেত্রে প্রতিটি ফাইল পরিবহণের জন্য এটি ইনস্টল করতে আরএসসিএন চালানোর দরকার নেই)।


প্রকৃত হার্ডওয়্যারটি ছিল সীগেট ড্রাইভ পরিচালিত এসএমআর 8 টিবি গ্রাহক ড্রাইভ। আপনার মাইলেজ অন্যান্য হার্ডওয়্যারের সাথে পরিবর্তিত হতে পারে।


2
এটি একটি ভাল উত্তর, তবে এই প্রশ্নের উত্তর নয় কারণ এটির মূল পোস্টারটি যা পোস্ট করেছে তার সাথে একেবারে কিছুই করার নেই। আমি আপনাকে এই উত্তরের জন্য একটি স্ব-উত্তরযুক্ত প্রশ্ন তৈরি করতে উত্সাহিত করব। যেমন "আমি একটি দমকা ড্রাইভ থেকে Rsync চেষ্টা করছি এবং অভিনয় খারাপ is আমি এটির উন্নতি করতে কী করতে পারি? "
জ্যাকগল্ড
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.