আই / ও ত্রুটিগুলি লিনাক্সে হারিয়ে যাওয়া লেখাগুলির কারণে লড়াই করতে প্রোগ্রামগুলি লেখার জন্য

Question

টিএল; ডিআর: লিনাক্স কার্নেল যদি একটি বাফারযুক্ত আই / ও লেখাকে হারিয়ে ফেলে , তবে অ্যাপ্লিকেশনটির কোনও উপায় খুঁজে পাওয়ার কি কোনও উপায় আছে?

আমি জানি fsync()স্থায়িত্বের জন্য আপনার কাছে ফাইল (এবং এর মূল ডিরেক্টরি) রয়েছে । প্রশ্নটি হ'ল যদি কার্নেল I / O ত্রুটির কারণে লেখার জন্য মুলতুবি থাকা মলিন বাফারগুলি হারায় , অ্যাপ্লিকেশনটি কীভাবে এটি সনাক্ত করতে পারে এবং পুনরুদ্ধার বা গর্ভপাত বন্ধ করতে পারে?

ডাটাবেস অ্যাপ্লিকেশন ইত্যাদির কথা ভাবেন, যেখানে লেখার এবং লেখার স্থায়িত্বের ক্রমটি গুরুত্বপূর্ণ।

হারিয়েছেন? কিভাবে?

লিনাক্স কার্নেলের ব্লক স্তরটি কিছু পরিস্থিতিতে ত্রুটিযুক্ত , ইত্যাদি দ্বারা সফলভাবে জমা দেওয়া বাফার I / O অনুরোধগুলি হারাতে পারে:write()pwrite()

Buffer I/O error on device dm-0, logical block 12345
lost page write due to I/O error on dm-0

(দেখুন end_buffer_write_sync(...)এবং end_buffer_async_write(...)ইনfs/buffer.c )

নতুন কার্নেলগুলিতে ত্রুটিটির পরিবর্তে "হারিয়ে যাওয়া অ্যাসিঙ্ক পৃষ্ঠা লেখা" থাকবে , যেমন:

Buffer I/O error on dev dm-0, logical block 12345, lost async page write

যেহেতু অ্যাপ্লিকেশনটির write()ইচ্ছামত ত্রুটি ছাড়াই ইতিমধ্যে ফিরে এসেছে, তাই মনে হয় অ্যাপ্লিকেশনটিতে কোনও ত্রুটি জানানোর কোনও উপায় নেই।

তাদের সনাক্ত করা হচ্ছে?

আমি কার্নেল উত্সগুলির সাথে তেমন পরিচিত নই, তবে আমি মনে করি যে এটি AS_EIOবাফারের উপর সেট করে যা কোনও অ্যাসিঙ্ক লেখার জন্য লিখিতভাবে ব্যর্থ হয়:

    set_bit(AS_EIO, &page->mapping->flags);
    set_buffer_write_io_error(bh);
    clear_buffer_uptodate(bh);
    SetPageError(page);

তবে এটি আমার কাছে স্পষ্ট নয় যে পরে fsync()বা ফাইলটি ডিস্কে রয়েছে কিনা তা নিশ্চিত করার জন্য অ্যাপ্লিকেশনটি এটি সম্পর্কে জানতে পারে।

এটা দেখে মনে হচ্ছে wait_on_page_writeback_range(...)এmm/filemap.c দ্বারা শক্তি do_sync_mapping_range(...)মধ্যেfs/sync.c যা ডাকা পালা sys_sync_file_range(...)। -EIOএক বা একাধিক বাফার লেখা না পারলে এটি ফিরে আসে ।

যদি, আমি অনুমান হিসাবে, এটি fsync()ফলাফলের প্রচার করে , তবে যদি অ্যাপ্লিকেশন আতঙ্কিত হয় এবং যদি এটি থেকে কোনও আই / ও ত্রুটি হয় fsync()এবং যদি পুনরায় আরম্ভ করার সাথে সাথে এর কাজটি পুনরায় কীভাবে করা যায় তবে কী যথেষ্ট সুরক্ষার ব্যবস্থা হওয়া উচিত?

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

তখন কি অন্য কোনও, নিরীহ, পরিস্থিতি যেখানে fsync()ফিরে আসতে পারে -EIOসেখানে জামিন দেওয়া এবং কাজটি খুব জটিল হওয়া হবে?

কেন?

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

কার্নেল যদি মনে করে যে কার্নেল আতঙ্কের সাথে মারা না গিয়ে লেখাগুলি হারানো ঠিক আছে, অ্যাপ্লিকেশনগুলিকে মোকাবেলার জন্য কোনও উপায় খুঁজে বের করতে হবে।

ব্যবহারিক প্রভাবটি হ'ল আমি এমন একটি মামলা পেয়েছি যেখানে সান দিয়ে একটি মাল্টিপথ সমস্যা হ'ল লেখাগুলি হারিয়েছে যে ডাটাবেস দুর্নীতি ঘটাচ্ছে কারণ ডিবিএমএস জানত না যে তার লেখাগুলি ব্যর্থ হয়েছে। মজা না.

Comments

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

— তিহাসিক

@ জুপ ধন্যবাদ আমার মনে হয় যা চলছে তার সাথে আমি একটি উত্তর পোস্ট করেছি, মনে মনে একটি বুদ্ধি যাচাই করা আছে যেহেতু আপনি "রাইটিং () এর নিকট () বা ফাইসেনসি ( ) স্থায়িত্বের জন্য "প্রশ্ন না পড়ে?

— ক্রেগ রিঞ্জার

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

— ২৮ শে

আমি একমত, আমি এতটা ন্যায্য ছিলাম না। হায়রে আপনার উত্তর খুব সন্তুষ্টিকর নয়, আমি বোঝাতে চাইছি এর কোনও সহজ সমাধান নেই (অবাক করা?)।

— জিন-ব্যাপটিস্ট ইউনিস

@ জিন-ব্যাপটিস্ট ইউনস সত্য। আমি যে ডিবিএমএসের সাথে কাজ করছি তার জন্য, "ক্র্যাশ করুন এবং পুনরায় প্রবেশ করুন" গ্রহণযোগ্য। বেশিরভাগ অ্যাপ্লিকেশনের জন্য এটি কোনও বিকল্প নয় এবং তাদের হয়ত সিঙ্ক্রোনাস আই / ও এর ভয়াবহ কার্যকারিতা সহ্য করতে হবে বা I / O ত্রুটির উপর দুর্বল সংজ্ঞাযুক্ত আচরণ এবং দুর্নীতি গ্রহণ করতে হবে।

— ক্রেগ রিঞ্জার

Answer 1

fsync()-EIOকার্নেল একটি লেখার ক্ষতি হারিয়ে ফেললে ফিরে আসে

(দ্রষ্টব্য: প্রারম্ভিক অংশটি পুরানো কার্নেলগুলি উল্লেখ করে; আধুনিক কার্নেলগুলি প্রতিবিম্বিত করতে নীচে আপডেট হয়েছে)

দেখে মনে হচ্ছে অ্যাসিঙ্ক বাফার লেখার end_buffer_async_write(...)ব্যর্থতায় -EIOফাইলটির জন্য ব্যর্থ নোংরা বাফার পৃষ্ঠায় একটি পতাকা সেট করেছে :

set_bit(AS_EIO, &page->mapping->flags);
set_buffer_write_io_error(bh);
clear_buffer_uptodate(bh);
SetPageError(page);

যা তখন সি লাইব্রেরি কলটি বাস্তবায়নের জন্য ডেকে ডাকা wait_on_page_writeback_range(...)হিসাবে চিহ্নিত দ্বারা সনাক্ত করা হয় ।do_sync_mapping_range(...)sys_sync_file_range(...)sys_sync_file_range2(...)fsync()

তবে একবারেই!

এই মন্তব্য sys_sync_file_range

168  * SYNC_FILE_RANGE_WAIT_BEFORE and SYNC_FILE_RANGE_WAIT_AFTER will detect any
169  * I/O errors or ENOSPC conditions and will return those to the caller, after
170  * clearing the EIO and ENOSPC flags in the address_space.

প্রস্তাব দেয় যে যখন fsync()রিটার্ন দেয় -EIOবা (ম্যানপেজে অদ্বিতীয়) -ENOSPC, এটি ত্রুটির অবস্থা সাফ করবে যাতে পরবর্তীকালে fsync()পৃষ্ঠাগুলি কখনই লিখিত না পাওয়া সত্ত্বেও সাফল্যের প্রতিবেদন করবে।

নিশ্চিতভাবেই wait_on_page_writeback_range(...) ত্রুটি বিটগুলি যখন এটি পরীক্ষা করে তখন তা সাফ করে দেয় :

301         /* Check for outstanding write errors */
302         if (test_and_clear_bit(AS_ENOSPC, &mapping->flags))
303                 ret = -ENOSPC;
304         if (test_and_clear_bit(AS_EIO, &mapping->flags))
305                 ret = -EIO;

সুতরাং যদি অ্যাপ্লিকেশনটি আশা করে fsync()যে এটি সফল না হওয়া এবং ডেটা অন ডিস্কে থাকা বিশ্বাস না করা পর্যন্ত এটি পুনরায় চেষ্টা করতে পারে তবে এটি মারাত্মক ভুল।

আমি দৃ sure়ভাবে নিশ্চিত যে এটি ডেবিএমএস-এ পাওয়া ডেটা দুর্নীতির উত্স। এটি চেষ্টা করে fsync()এবং মনে করে যে এটি সফল হলে সমস্ত কিছু ঠিক হয়ে যাবে।

এটি কি অনুমোদিত?

উপর POSIX / বুনো ডক্সfsync() সত্যিই এই উভয় ক্ষেত্রেই উল্লেখ না:

যদি fsync () ফাংশন ব্যর্থ হয় তবে অসামান্য I / O ক্রিয়াকলাপগুলি সম্পন্ন হওয়ার গ্যারান্টি নেই।

লিনাক্সের ম্যান-পেজfsync() ব্যর্থতায় কী ঘটে সে সম্পর্কে কিছুই বলে না।

সুতরাং মনে হচ্ছে fsync()ত্রুটির অর্থ হ'ল "আপনার লেখাগুলিতে কী ঘটেছিল, কাজ করেছেন বা না করেছেন, নিশ্চিত হওয়ার জন্য আরও ভাল চেষ্টা করুন"।

আরও নতুন কার্নেল

পৃষ্ঠায় 4.9 end_buffer_async_writeসেটগুলিতে -EIO, কেবলমাত্র mapping_set_error।

    buffer_io_error(bh, ", lost async page write");
    mapping_set_error(page->mapping, -EIO);
    set_buffer_write_io_error(bh);
    clear_buffer_uptodate(bh);
    SetPageError(page);

সিঙ্কের দিক থেকে আমি মনে করি এটি অনুরূপ, যদিও কাঠামোটি এখন অনুসরণ করা বেশ জটিল। filemap_check_errorsমধ্যে mm/filemap.cএখন আছে:

    if (test_bit(AS_EIO, &mapping->flags) &&
        test_and_clear_bit(AS_EIO, &mapping->flags))
            ret = -EIO;

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

    if (test_bit(AS_EIO, &mapping->flags) &&
        test_and_clear_bit(AS_EIO, &mapping->flags))
            ret = -EIO;
    return ret;

আমি btrfsআমার ল্যাপটপে ব্যবহার করছি , কিন্তু যখন আমি ext4পরীক্ষার জন্য লুপব্যাক তৈরি করি /mnt/tmpএবং এটিতে পারফেক্ট প্রোব সেট আপ করি:

sudo dd if=/dev/zero of=/tmp/ext bs=1M count=100
sudo mke2fs -j -T ext4 /tmp/ext
sudo mount -o loop /tmp/ext /mnt/tmp

sudo perf probe filemap_check_errors

sudo perf record -g -e probe:end_buffer_async_write -e probe:filemap_check_errors dd if=/dev/zero of=/mnt/tmp/test bs=4k count=1 conv=fsync

আমি নিম্নলিখিত কল স্ট্যাকের মধ্যে খুঁজে পাই perf report -T:

        ---__GI___libc_fsync
           entry_SYSCALL_64_fastpath
           sys_fsync
           do_fsync
           vfs_fsync_range
           ext4_sync_file
           filemap_write_and_wait_range
           filemap_check_errors

একটি পঠন মাধ্যমে পরামর্শ দেয় যে হ্যাঁ, আধুনিক কার্নেলগুলি একই আচরণ করে।

এর অর্থ এই বলে মনে হয় যে যদি fsync()(বা সম্ভবত write()বা close()) ফিরে আসে -EIO, ফাইলটি আপনি যখন সাফল্যের সাথে শেষবার fsync()ডি বা close()ডি এবং এর সর্বশেষ write()দশ দশকের মধ্যে রেখেছিলেন তখন কিছু অপরিজ্ঞাত অবস্থায় রয়েছে ।

পরীক্ষা

আমি এই আচরণটি প্রদর্শনের জন্য একটি পরীক্ষার কেস প্রয়োগ করেছি ।

প্রভাব

একটি ডিবিএমএস ক্র্যাশ পুনরুদ্ধারে প্রবেশ করে এটি মোকাবেলা করতে পারে। পৃথিবীতে একটি সাধারণ ব্যবহারকারী অ্যাপ্লিকেশন কীভাবে এটি মোকাবেলা করার কথা? fsync()Man পৃষ্ঠা কোনো সতর্কতা এটি অভাবমুক্ত করে দেন "fsync-যদি-আপনি-অনুভূতি মত-এটি" এবং আমি একটি আশা অনেক অ্যাপস এই আচরণ সঙ্গে ভাল মানিয়ে করা হবে না।

বাগ রিপোর্ট

• https://bugzilla.kernel.org/show_bug.cgi?id=194755
• https://bugzilla.kernel.org/show_bug.cgi?id=194757

আরও পড়া

lwn.net "উন্নত ব্লক-স্তর ত্রুটি হ্যান্ডলিং" নিবন্ধে এটি স্পর্শ করেছে ।

postgresql.org মেলিং তালিকার থ্রেড ।

Comments

lxr.free-electrons.com/source/fs/buffer.c?v=2.6.26#L598 একটি সম্ভাব্য জাতি, কারণ এটি {মুলতুবি ও তফসিলযুক্ত I / O for এর জন্য অপেক্ষা করছে, এখনও নির্ধারিত I / O scheduled এর জন্য নয়} এটি সম্ভবত ডিভাইসে অতিরিক্ত রাউন্ড ট্রিপগুলি এড়ানোর জন্য। (আমি অনুমান করি যে ব্যবহারকারী লিখেছেন ()

— এমএমএপ

একই ডিস্কে অন্য কোনও ফাইলের জন্য ফাইএনসিচ করার জন্য অন্য কোনও প্রক্রিয়াটির কলটি ত্রুটি ফিরে পেয়েছে?

— র্যান্ডম 832

@ র্যান্ডম 832 পোস্টগ্র্রেএসকিউএল এর মতো একটি মাল্টি-প্রসেসিং ডিবির জন্য খুব প্রাসঙ্গিক, তাই ভাল প্রশ্ন। দেখে মনে হচ্ছে সম্ভবত, তবে আমি কার্নেল কোডটি বুঝতে পারি না। আপনার প্রকল্পগুলি যদি উভয়ই একই ফাইল খোলা থাকে তবে তাদের পক্ষে আরও ভালভাবে সহযোগিতা করা উচিত।

— ক্রেগ রিঞ্জার

@ ডেভিডফোরস্টার: সাইকোলগুলি নেতিবাচক ত্রুটিযুক্ত কোডগুলি ব্যবহার করে ব্যর্থতা ফিরিয়ে দেয়; errnoসম্পূর্ণরূপে ইউজারস্পেস সি লাইব্রেরির একটি নির্মাণ। এটা তোলে (যেমন ক্রেইগ রিঙ্গার, না উপরে), যেহেতু ত্রুটি ফেরত মান নির্ভরযোগ্যভাবে শনাক্ত যা এক (প্রাপ্ত syscall বা C লাইব্রেরি ফাংশন) উল্লেখ করা হচ্ছে syscalls এবং এই মত C লাইব্রেরি মধ্যে ফেরত মান পার্থক্য উপেক্ষা করা খুবই সাধারণ: " -1সঙ্গে errno==EIO"একটি সি লাইব্রেরির ক্রিয়াকলাপ -EIOবোঝায় , যেখানে" "সিস্কেলকে বোঝায়। অবশেষে, লিনাক্স ম্যান পৃষ্ঠাগুলি লিনাক্স ম্যান পৃষ্ঠাগুলি সর্বাধিক আপ টু ডেট রেফারেন্স।

— নামমাত্র প্রাণী 18

@ ক্রেইগ্রিঞ্জার: আপনার চূড়ান্ত প্রশ্নের উত্তর দিতে: "নিম্ন-স্তরের I / O ব্যবহার করে এবং fsync()/ fdatasync()যখন লেনদেনের আকারটি একটি সম্পূর্ণ ফাইল হয়; যখন mmap()/ msync()লেনদেনের আকারটি পৃষ্ঠা-সারিবদ্ধ রেকর্ড হয় তখন / ব্যবহার করে এবং নিম্ন স্তরের আই ব্যবহার করে; / O, fdatasync()এবং একাধিক একযোগে ফাইল বর্ণনাকারী (লেনদেনের প্রতি এক বর্ণনাকারী এবং একটি থ্রেড) অন্যথায় " । লিনাক্স-নির্দিষ্ট ওপেন ফাইল বর্ণন লকগুলি ( fcntl(), F_OFD_) শেষের সাথে খুব কার্যকর।

— নামমাত্র প্রাণী 18

Answer 2

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

আমি একমত না. writeলেখার সহজভাবে সারি করা থাকলে ত্রুটি ছাড়াই ফিরে আসতে পারে, তবে ত্রুটিটি পরবর্তী ক্রিয়াকলাপে রিপোর্ট করা হবে যার জন্য ডিস্কে প্রকৃত লেখার প্রয়োজন হবে, এর অর্থ পরবর্তীটি fsyncসম্ভবত সিস্টেমটি ক্যাশে ফ্লাশ করার সিদ্ধান্ত নেয় এবং সম্ভবত অন্তত শেষ ফাইল বন্ধ।

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

আপনি কি সত্যিই প্রক্রিয়াকরণের আপনি যে সবকিছু যে অন্তিম সফল যেহেতু লেখা হয়েছিল অনুমান করা আবশ্যক চালাক ত্রুটি করতে সক্ষম হতে হবে যদি fsync পারে ব্যর্থ হয়েছে এবং সব অন্তত কিছু ব্যর্থ হয়েছে যে।

Comments

হ্যাঁ, আমি মনে করি এটি নখ করে। নিশ্চয় যে সুপারিশ আবেদন করা উচিত তার সকল কাজ শেষ নিশ্চিত-সফল যেহেতু পুনরায় করতে হবে fsync()বা close()ফাইলের যদি এটি একটি পায় -EIOথেকে write(), fsync()বা close()। ঠিক আছে, মজা।

— ক্রেগ রিঞ্জার

Answer 3

write(২) আপনার প্রত্যাশার চেয়ে কম সরবরাহ করে। ম্যান পেজটি একটি সফল write()কলটির অর্থসূচক সম্পর্কে খুব উন্মুক্ত :

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

আমরা উপসংহারে পৌঁছাতে পারি যে একটি সফল write()অর্থ হ'ল ডেটা কার্নেলের বাফারিং সুবিধাগুলিতে পৌঁছেছে। যদি বাফারটি অব্যাহত রাখে তবে পরবর্তীকালে ফাইল বর্ণনাকারীর অ্যাক্সেস ত্রুটি কোডটি ফিরিয়ে দেবে। সর্বশেষ উপায় হিসাবে হতে পারে close()। close(2) সিস্টেম কলের ম্যান পৃষ্ঠাতে নিম্নলিখিত বাক্যটি রয়েছে:

এটি বেশ সম্ভব যে কোনও পূর্ববর্তী write(2) ক্রিয়াকলাপে ত্রুটিগুলি ফাইনালের close() এ প্রথম প্রকাশিত হয় ।

যদি আপনার অ্যাপ্লিকেশনটির ডেটা অবিরত রাখতে হয় তবে এটি নিয়মিত fsync/ ব্যবহার করতে fsyncdataহয়:

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

Comments

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

— ক্রেগ রিঞ্জার

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

— fzgregor

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

— ক্রেগ রিঞ্জার

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

— fzgregor

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

— ক্রেগ রিঞ্জার

Answer 4

আপনি যখন ফাইলটি খুলবেন তখন O_SYNC পতাকা ব্যবহার করুন। এটি নিশ্চিত করে যে ডেটা ডিস্কে লেখা আছে।

যদি এটি আপনাকে সন্তুষ্ট না করে তবে কিছুই থাকবে না।

Comments

O_SYNCঅভিনয়ের জন্য দুঃস্বপ্ন a এর অর্থ হ'ল ডিস্ক I / O হওয়ার সময় অ্যাপ্লিকেশন অন্য কিছু করতে পারে না যদি না এটি আই / ও থ্রেডগুলি বন্ধ করে দেয়। আপনি পাশাপাশি বলতে পারেন যে বাফার্ড আই / ও ইন্টারফেসটি অনিরাপদ এবং প্রত্যেকেরই এআইও ব্যবহার করা উচিত। নিশ্চয় নীরবে-হারিয়ে যাওয়া লেখাগুলি বার্ড আই / ও-তে গ্রহণযোগ্য হতে পারে না?

— ক্রেগ রিঞ্জার

( O_DATASYNCসে ক্ষেত্রে কেবল কিছুটা ভাল)

— ক্রেগ

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

— ডেমি

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

— ক্রেগ রিঞ্জার

Answer 5

নিকটবর্তী ফেরতের মানটি পরীক্ষা করুন। কাছাকাছি ব্যর্থ হতে পারে whilst বাফার লেখাগুলি সাফল্য উপস্থিত হয়।

Comments

ঠিক আছে, আমরা খুব কমই প্রতি কয়েক সেকেন্ডের মধ্যে ফাইলটি open()আইএনপি এবং close()আইএনএন করাতে চাই । সে কারণেই আমাদের fsync()...

— ক্রেগ