টেকসই ডেটা স্টোরেজ এবং লিনাক্স ফাইল এপিআই

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

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

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

write() ফাংশন ব্যবহার করার বৈশিষ্ট্য

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

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

fsync() এবং fdatasync() ফাংশন

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

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

এই প্রক্রিয়াটি বিভিন্ন ফাইল সিস্টেমে ভিন্নভাবে প্রয়োগ করা যেতে পারে। আমি ব্যবহার করতাম blktrace ext4 এবং XFS ফাইল সিস্টেমে কোন ডিস্ক অপারেশন ব্যবহার করা হয় তা জানতে। উভয়ই ফাইলের বিষয়বস্তু এবং ফাইল সিস্টেম জার্নাল উভয়ের জন্য ডিস্কে নিয়মিত লিখতে আদেশ জারি করে, ক্যাশে ফ্লাশ করে এবং একটি FUA (ফোর্স ইউনিট অ্যাক্সেস, ডিস্কে সরাসরি ডেটা লেখা, ক্যাশে বাইপাস করে) জার্নালে লেখার মাধ্যমে প্রস্থান করে। তারা সম্ভবত লেনদেন হয়েছে তা নিশ্চিত করার জন্য এটি করে। FUA সমর্থন করে না এমন ড্রাইভে, এর ফলে দুটি ক্যাশে ফ্লাশ হয়। আমার পরীক্ষাগুলি তা দেখিয়েছে fdatasync() একটু দ্রুত fsync(). ইউটিলিটি blktrace নির্দেশ করে যে fdatasync() সাধারণত ডিস্কে কম ডেটা লেখে (ext4 এ fsync() লেখেন 20 KiB, এবং fdatasync() - 16 কিবি)। এছাড়াও, আমি খুঁজে পেয়েছি যে এক্সএফএস ext4 এর চেয়ে কিছুটা দ্রুত। এবং এখানে সাহায্যের সাথে blktrace যে খুঁজে বের করতে পরিচালিত fdatasync() ডিস্কে কম ডেটা ফ্লাশ করে (XFS-এ 4 KiB)।

fsync() ব্যবহার করার সময় উদ্ভূত অস্পষ্ট পরিস্থিতি

আমি সম্পর্কে তিনটি অস্পষ্ট পরিস্থিতিতে চিন্তা করতে পারেন fsync()যা আমি অনুশীলনে সম্মুখীন হয়েছি।

2008 সালে এই ধরনের প্রথম ঘটনা ঘটেছিল। তারপর ফায়ারফক্স 3 ইন্টারফেস হিমায়িত হয়ে যায় যদি প্রচুর সংখ্যক ফাইল ডিস্কে লেখা হয়। সমস্যাটি ছিল যে ইন্টারফেসের বাস্তবায়ন তার অবস্থা সম্পর্কে তথ্য সংরক্ষণ করতে একটি SQLite ডাটাবেস ব্যবহার করে। ইন্টারফেসে ঘটে যাওয়া প্রতিটি পরিবর্তনের পরে, ফাংশনটি কল করা হয়েছিল fsync(), যা স্থিতিশীল ডেটা স্টোরেজের ভাল গ্যারান্টি দিয়েছে। ext3 ফাইল সিস্টেমে তখন ফাংশন ব্যবহার করা হয় fsync() সিস্টেমের সমস্ত "নোংরা" পৃষ্ঠাগুলিকে ডিস্কে ডাম্প করে, এবং শুধুমাত্র সেইগুলি নয় যেগুলি সংশ্লিষ্ট ফাইলের সাথে সম্পর্কিত ছিল৷ এর মানে হল যে ফায়ারফক্সের একটি বোতামে ক্লিক করলে মেগাবাইট ডেটা একটি চৌম্বকীয় ডিস্কে লেখার জন্য ট্রিগার হতে পারে, যা অনেক সেকেন্ড সময় নিতে পারে। সমস্যার সমাধান, যতদূর থেকে বুঝলাম এটা উপাদান ছিল ডাটাবেসের সাথে কাজকে অ্যাসিঙ্ক্রোনাস ব্যাকগ্রাউন্ড টাস্কে স্থানান্তর করা। এর মানে হল যে Firefox আগে সত্যিকারের প্রয়োজনের চেয়ে আরও কঠোর স্টোরেজ প্রয়োজনীয়তা প্রয়োগ করেছিল এবং ext3 ফাইল সিস্টেমের বৈশিষ্ট্যগুলি এই সমস্যাটিকে আরও বাড়িয়ে তুলেছিল।

দ্বিতীয় সমস্যাটি 2009 সালে হয়েছিল। তারপরে, একটি সিস্টেম ক্র্যাশের পরে, নতুন ext4 ফাইল সিস্টেমের ব্যবহারকারীরা এই সত্যের মুখোমুখি হয়েছিল যে অনেক নতুন তৈরি ফাইলের দৈর্ঘ্য শূন্য ছিল, কিন্তু পুরানো ext3 ফাইল সিস্টেমের সাথে এটি ঘটেনি। পূর্ববর্তী অনুচ্ছেদে, আমি কীভাবে ext3 ডিস্কে অত্যধিক ডেটা ফ্লাশ করে তা নিয়ে কথা বলেছিলাম, যা জিনিসগুলিকে অনেক কমিয়ে দেয়। fsync(). পরিস্থিতির উন্নতির জন্য, ext4-এ শুধুমাত্র সেই নোংরা পৃষ্ঠাগুলি যা একটি নির্দিষ্ট ফাইলের সাথে প্রাসঙ্গিক, ডিস্কে ফ্লাশ করা হয়। এবং অন্যান্য ফাইলের ডেটা ext3 এর চেয়ে অনেক বেশি সময়ের জন্য মেমরিতে থাকে। এটি কর্মক্ষমতা উন্নত করার জন্য করা হয়েছিল (ডিফল্টরূপে, ডেটা 30 সেকেন্ডের জন্য এই অবস্থায় থাকে, আপনি এটি ব্যবহার করে কনফিগার করতে পারেন dirty_expire_centisecs; এখানে আপনি এই সম্পর্কে অতিরিক্ত উপকরণ খুঁজে পেতে পারেন)। এর মানে হল যে একটি ব্যর্থতার পরে প্রচুর পরিমাণে ডেটা অপূরণীয়ভাবে হারিয়ে যেতে পারে। এই সমস্যার সমাধান হল ব্যবহার করা fsync() যে অ্যাপ্লিকেশনগুলিতে স্থিতিশীল ডেটা সঞ্চয়স্থান নিশ্চিত করতে হবে এবং ব্যর্থতার পরিণতি থেকে যতটা সম্ভব তাদের রক্ষা করতে হবে। ফাংশন fsync() ext4 ব্যবহার করার চেয়ে ext3 ব্যবহার করার সময় অনেক বেশি দক্ষতার সাথে কাজ করে। এই পদ্ধতির অসুবিধা হল যে এটির ব্যবহার, আগের মতই, কিছু ক্রিয়াকলাপ যেমন প্রোগ্রামগুলি ইনস্টল করাকে ধীর করে দেয়। এই সম্পর্কে বিস্তারিত দেখুন এখানে и এখানে.

সম্পর্কে তৃতীয় সমস্যা fsync(), 2018 সালে উদ্ভূত। তারপর, PostgreSQL প্রকল্পের কাঠামোর মধ্যে, এটি যদি ফাংশন পাওয়া যায় fsync() একটি ত্রুটির সম্মুখীন হয়, এটি "নোংরা" পৃষ্ঠাগুলিকে "পরিষ্কার" হিসাবে চিহ্নিত করে। ফলস্বরূপ, নিম্নলিখিত কল fsync() তারা এই ধরনের পেজ দিয়ে কিছু করে না। এই কারণে, পরিবর্তিত পৃষ্ঠাগুলি মেমরিতে সংরক্ষণ করা হয় এবং কখনই ডিস্কে লেখা হয় না। এটি একটি বাস্তব বিপর্যয়, যেহেতু অ্যাপ্লিকেশনটি মনে করবে যে কিছু ডেটা ডিস্কে লেখা হয়েছে, তবে বাস্তবে তা হবে না। এই ধরনের ব্যর্থতা fsync() বিরল, এই ধরনের পরিস্থিতিতে অ্যাপ্লিকেশন সমস্যা মোকাবেলা করার জন্য প্রায় কিছুই করতে পারে না। আজকাল, যখন এটি ঘটে, PostgreSQL এবং অন্যান্য অ্যাপ্লিকেশন ক্র্যাশ হয়। এটা হল, "অ্যাপ্লিকেশনগুলি কি fsync ব্যর্থতা থেকে পুনরুদ্ধার করতে পারে?" উপাদানটিতে, এই সমস্যাটি বিশদভাবে অন্বেষণ করা হয়েছে। বর্তমানে এই সমস্যার সর্বোত্তম সমাধান হল পতাকার সাথে সরাসরি I/O ব্যবহার করা O_SYNC অথবা একটি পতাকা দিয়ে O_DSYNC. এই পদ্ধতির সাহায্যে, সিস্টেম নির্দিষ্ট লেখার ক্রিয়াকলাপের সময় ঘটতে পারে এমন ত্রুটিগুলি রিপোর্ট করবে, তবে এই পদ্ধতির জন্য অ্যাপ্লিকেশনটিকে নিজেই বাফারগুলি পরিচালনা করতে হবে। এই সম্পর্কে আরো পড়ুন এখানে и এখানে.

O_SYNC এবং O_DSYNC পতাকা ব্যবহার করে ফাইল খোলা হচ্ছে

চলুন স্থিতিশীল ডেটা স্টোরেজ প্রদানকারী লিনাক্স মেকানিজমের আলোচনায় ফিরে আসি। যথা, আমরা পতাকা ব্যবহারের কথা বলছি O_SYNC বা পতাকা O_DSYNC সিস্টেম কল ব্যবহার করে ফাইল খোলার সময় খোলা (). এই পদ্ধতির সাহায্যে, প্রতিটি ডেটা লেখার অপারেশন প্রতিটি কমান্ডের পরে সঞ্চালিত হয় write() সিস্টেম অনুযায়ী কমান্ড দেওয়া হয় fsync() и fdatasync()। দ্য POSIX স্পেসিফিকেশন একে বলা হয় "সিঙ্ক্রোনাইজড I/O ফাইল ইন্টিগ্রিটি কমপ্লিশন" এবং "ডেটা ইন্টিগ্রিটি কমপ্লিশন"। এই পদ্ধতির প্রধান সুবিধা হল ডেটা অখণ্ডতা নিশ্চিত করতে, আপনাকে দুটির পরিবর্তে শুধুমাত্র একটি সিস্টেম কল করতে হবে (উদাহরণস্বরূপ - write() и fdatasync()) এই পদ্ধতির প্রধান অসুবিধা হল সংশ্লিষ্ট ফাইল বর্ণনাকারী ব্যবহার করে সমস্ত লেখা সিঙ্ক্রোনাইজ করা হবে, যা অ্যাপ্লিকেশন কোড গঠন করার ক্ষমতা সীমিত করতে পারে।

O_DIRECT পতাকার সাথে সরাসরি I/O ব্যবহার করা

সিস্টেম কল open() পতাকা সমর্থন করে O_DIRECT, যা ডিস্কের সাথে সরাসরি ইন্টারঅ্যাক্ট করে I/O ক্রিয়াকলাপ সম্পাদন করতে অপারেটিং সিস্টেমের ক্যাশে বাইপাস করার জন্য ডিজাইন করা হয়েছে। এটি, অনেক ক্ষেত্রে, এর মানে হল যে প্রোগ্রাম দ্বারা জারি করা কমান্ডগুলি সরাসরি ডিস্কের সাথে কাজ করার লক্ষ্যে কমান্ডগুলিতে অনুবাদ করা হবে। কিন্তু, সাধারণভাবে, এই প্রক্রিয়াটি ফাংশনের প্রতিস্থাপন নয় fsync() বা fdatasync(). আসলে ডিস্ক নিজেই পারে defer or cache সংশ্লিষ্ট তথ্য লেখার আদেশ। এবং, বিষয়টিকে আরও খারাপ করার জন্য, কিছু বিশেষ ক্ষেত্রে পতাকা ব্যবহার করার সময় I/O অপারেশনগুলি সঞ্চালিত হয় O_DIRECT, সম্প্রচার ঐতিহ্যগত বাফার অপারেশন মধ্যে. এই সমস্যা সমাধানের সবচেয়ে সহজ উপায় হল ফাইল খুলতে পতাকা ব্যবহার করা O_DSYNC, যার অর্থ প্রতিটি লেখার ক্রিয়াকলাপ একটি কল দ্বারা অনুসরণ করা হবে fdatasync().

দেখা গেল যে XFS ফাইল সিস্টেম সম্প্রতি একটি "দ্রুত পথ" যোগ করেছে O_DIRECT|O_DSYNC-ডেটা রেকর্ডিং। যদি একটি ব্লক ব্যবহার করে পুনরায় লেখা হয় O_DIRECT|O_DSYNC, তারপর XFS, ক্যাশে ফ্লাশ করার পরিবর্তে, ডিভাইসটি সমর্থন করলে FUA রাইট কমান্ড চালাবে। আমি ইউটিলিটি ব্যবহার করে এটি যাচাই করেছি blktrace একটি লিনাক্স 5.4/উবুন্টু 20.04 সিস্টেমে। এই পদ্ধতিটি আরও দক্ষ হওয়া উচিত, যেহেতু ব্যবহার করার সময়, ডিস্কে একটি ন্যূনতম পরিমাণ ডেটা লেখা হয় এবং দুটির পরিবর্তে একটি অপারেশন ব্যবহার করা হয় (ক্যাশে লেখা এবং ফ্লাশ করা)। আমি একটি লিঙ্ক খুঁজে পেয়েছি তালি 2018 কার্নেল, যা এই প্রক্রিয়াটি প্রয়োগ করে। অন্যান্য ফাইল সিস্টেমে এই অপ্টিমাইজেশানটি প্রয়োগ করার বিষয়ে কিছু আলোচনা আছে, কিন্তু যতদূর আমি জানি, XFS হল একমাত্র ফাইল সিস্টেম যা এখনও পর্যন্ত এটিকে সমর্থন করে।

sync_file_range() ফাংশন

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

সিস্টেম কল যা ডেটা স্থিরতা নিশ্চিত করতে সাহায্য করে

আমি উপসংহারে পৌঁছেছি যে তিনটি পন্থা আছে যা I/O ক্রিয়াকলাপগুলি সম্পাদন করতে ব্যবহার করা যেতে পারে যা ডেটা স্থিরতা নিশ্চিত করে। তারা সব একটি ফাংশন কল প্রয়োজন fsync() যে ডিরেক্টরিতে ফাইলটি তৈরি করা হয়েছিল তার জন্য। এই পদ্ধতিগুলি হল:

1. একটি ফাংশন কলিং fdatasync() বা fsync() ফাংশন পরে write() (এটি ব্যবহার করা ভাল fdatasync()).
2. একটি পতাকা দিয়ে খোলা একটি ফাইল বর্ণনাকারীর সাথে কাজ করা O_DSYNC বা O_SYNC (ভাল - একটি পতাকা সহ O_DSYNC).
3. কমান্ড ব্যবহার করে pwritev2() পতাকা সহ RWF_DSYNC বা RWF_SYNC (বিশেষত একটি পতাকা দিয়ে RWF_DSYNC).

কর্মক্ষমতা নোট

আমি যে বিভিন্ন মেকানিজম পরীক্ষা করেছি তার কার্যকারিতা আমি সাবধানে পরিমাপ করিনি। তাদের কাজের গতিতে আমি যে পার্থক্য লক্ষ্য করেছি তা খুবই সামান্য। এর মানে হল যে আমি ভুল হতে পারি, এবং বিভিন্ন পরিস্থিতিতে একই জিনিস ভিন্ন ফলাফল আনতে পারে। প্রথমত, আমি কি কর্মক্ষমতা বেশি প্রভাবিত করে, এবং তারপর কর্মক্ষমতা কম প্রভাবিত করে সে সম্পর্কে কথা বলব।

1. ফাইল ডেটা ওভাররাইট করা একটি ফাইলে ডেটা যুক্ত করার চেয়ে দ্রুততর (কর্মক্ষমতা সুবিধা 2-100% হতে পারে)। একটি ফাইলে ডেটা যুক্ত করার জন্য ফাইলের মেটাডেটাতে অতিরিক্ত পরিবর্তন প্রয়োজন, এমনকি একটি সিস্টেম কলের পরেও fallocate(), কিন্তু এই প্রভাবের মাত্রা পরিবর্তিত হতে পারে। আমি সুপারিশ, সেরা পারফরম্যান্সের জন্য, কল করার জন্য fallocate() প্রয়োজনীয় স্থান প্রাক-বরাদ্দ করতে। তারপর এই স্থানটি অবশ্যই শূন্য দিয়ে পূর্ণ করতে হবে এবং কল করতে হবে fsync(). এটি নিশ্চিত করবে যে ফাইল সিস্টেমের সংশ্লিষ্ট ব্লকগুলি "অবরাদ্দকৃত" এর পরিবর্তে "বরাদ্দ" হিসাবে চিহ্নিত করা হয়েছে। এটি একটি ছোট (প্রায় 2%) কর্মক্ষমতা উন্নতি দেয়। অতিরিক্তভাবে, কিছু ডিস্কে অন্যদের তুলনায় একটি ব্লকে প্রথমে ধীরগতির অ্যাক্সেস থাকতে পারে। এর মানে হল যে শূন্য দিয়ে শূন্যস্থান পূরণ করলে কর্মক্ষমতায় উল্লেখযোগ্য (প্রায় 100%) উন্নতি হতে পারে। বিশেষ করে, এটি ডিস্কের সাথে ঘটতে পারে AWS EBS (এটি বেসরকারী তথ্য, আমি এটি নিশ্চিত করতে পারিনি)। একই স্টোরেজ জন্য যায় জিসিপি স্থায়ী ডিস্ক (এবং এটি ইতিমধ্যেই অফিসিয়াল তথ্য, পরীক্ষা দ্বারা নিশ্চিত)। অন্য বিশেষজ্ঞরাও একই কাজ করেছেন পর্যবেক্ষণ, বিভিন্ন ডিস্কের সাথে সম্পর্কিত।
2. কম সিস্টেম কল, কর্মক্ষমতা উচ্চতর (লাভ প্রায় 5% হতে পারে)। একটা চ্যালেঞ্জ মনে হচ্ছে open() পতাকা সহ O_DSYNC অথবা কল করুন pwritev2() পতাকা সহ RWF_SYNC কলের চেয়ে দ্রুত fdatasync(). আমি সন্দেহ করি যে এখানে পয়েন্টটি হল যে এই পদ্ধতিটি একটি ভূমিকা পালন করে যে একই সমস্যা সমাধানের জন্য কম সিস্টেম কল করতে হবে (দুটির পরিবর্তে একটি কল)। কিন্তু পারফরম্যান্সের পার্থক্য খুব ছোট, তাই আপনি এটিকে সম্পূর্ণরূপে উপেক্ষা করতে পারেন এবং অ্যাপ্লিকেশনটিতে এমন কিছু ব্যবহার করতে পারেন যা এর যুক্তিকে জটিল করবে না।

আপনি যদি টেকসই ডেটা স্টোরেজ বিষয়ে আগ্রহী হন তবে এখানে কিছু দরকারী উপকরণ রয়েছে:

• I/O অ্যাক্সেস পদ্ধতি — ইনপুট/আউটপুট মেকানিজমের মৌলিক বিষয়গুলির ওভারভিউ।
• ডেটা ডিস্কে পৌঁছানো নিশ্চিত করা — অ্যাপ্লিকেশন থেকে ডিস্কে যাওয়ার পথে ডেটার কী ঘটে সে সম্পর্কে একটি গল্প।
• যখন আপনি ধারণকারী ডিরেক্টরি fsync করা উচিত - কখন ব্যবহার করবেন প্রশ্নের উত্তর fsync() ডিরেক্টরির জন্য। এটিকে সংক্ষেপে বলতে গেলে, দেখা যাচ্ছে যে একটি নতুন ফাইল তৈরি করার সময় আপনাকে এটি করতে হবে এবং এই সুপারিশের কারণ হল যে লিনাক্সে একই ফাইলের অনেকগুলি উল্লেখ থাকতে পারে।
• লিনাক্সে SQL সার্ভার: FUA অভ্যন্তরীণ — লিনাক্স প্ল্যাটফর্মে SQL সার্ভারে কীভাবে স্থায়ী ডেটা স্টোরেজ প্রয়োগ করা হয় তার একটি বর্ণনা এখানে রয়েছে। এখানে উইন্ডোজ এবং লিনাক্স সিস্টেম কলের মধ্যে কিছু আকর্ষণীয় তুলনা রয়েছে। আমি প্রায় নিশ্চিত যে এই উপাদানটির জন্য ধন্যবাদ যে আমি XFS-এর FUA অপ্টিমাইজেশন সম্পর্কে শিখেছি।

আপনি কি এমন ডেটা হারিয়েছেন যা আপনি ভেবেছিলেন একটি ডিস্কে নিরাপদে সংরক্ষণ করা হয়েছে?

উত্স: www.habr.com