কোনও এসএসডি ড্রাইভের এক্সট3 পার্টিশনে হঠাৎ-পাওয়ার-ক্ষতি ফাইল-সিস্টেমের দুর্নীতি কি "প্রত্যাশিত আচরণ"?


13

আমার সংস্থা একটি এম্বেডড ডেবিয়ান লিনাক্স ডিভাইস তৈরি করে যা কোনও অভ্যন্তরীণ এসএসডি ড্রাইভে একটি এক্সট্রি পার্টিশন থেকে বুট হয়। ডিভাইসটি একটি এম্বেড করা "ব্ল্যাক বক্স" হওয়ায় এটি বাহ্যিক সুইচের মাধ্যমে কেবলমাত্র ডিভাইসটির শক্তি কেটে, অভদ্রভাবে সাধারণত বন্ধ করে দেওয়া হয়।

এটি সাধারণত ঠিক আছে, যেহেতু ext3 এর জার্নালিং জিনিসগুলিকে সুশৃঙ্খল করে রাখে, তাই লগ ফাইলের মাঝে মাঝে ক্ষতি হওয়া ব্যতীত, জিনিসগুলি জরিমানা বজায় রাখে।

যাইহোক, আমরা সম্প্রতি বেশ কয়েকটি ইউনিট দেখেছি যেখানে প্রচুর শক্ত-চক্রের পরে ext3 পার্টিশনটি কাঠামোগত সমস্যাগুলি বিকাশ শুরু করে - বিশেষত, আমরা ext3 পার্টিশনে e2fsck চালাই এবং এটি এর মত অনেকগুলি সমস্যা আবিষ্কার করে where এই প্রশ্নের নীচে আউটপুট তালিকাতে দেখানো হয়েছে। এটি রিপোর্টিং ত্রুটিগুলি থামিয়ে দেওয়া (বা পার্টিশনের পুনরায় ফর্ম্যাট করা) সমস্যাগুলি সাফ করার আগে পর্যন্ত ই 2fsck চালানো Run

আমার প্রশ্ন হ'ল ... প্রচুর আকস্মিক / অপ্রত্যাশিত শাটডাউনের শিকার হওয়া একটি এক্সট্রি / এসএসডি সিস্টেমে এই জাতীয় সমস্যাগুলি দেখার কী কী প্রভাব পড়বে?

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

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

আমাদের মধ্যে কোনটি সঠিক?

Embedded-PC-failsafe:~# ls
Embedded-PC-failsafe:~# umount /mnt/unionfs
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Invalid inode number for '.' in directory inode 46948.
Fix<y>? yes

Directory inode 46948, block 0, offset 12: directory corrupted
Salvage<y>? yes

Entry 'status_2012-11-26_14h13m41.csv' in /var/log/status_logs (46956) has deleted/unused inode 47075.  Clear<y>? yes
Entry 'status_2012-11-26_10h42m58.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47076.  Clear<y>? yes
Entry 'status_2012-11-26_11h29m41.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47080.  Clear<y>? yes
Entry 'status_2012-11-26_11h42m13.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47081.  Clear<y>? yes
Entry 'status_2012-11-26_12h07m17.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47083.  Clear<y>? yes
Entry 'status_2012-11-26_12h14m53.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47085.  Clear<y>? yes
Entry 'status_2012-11-26_15h06m49.csv' in /var/log/status_logs (46956) has deleted/unused inode 47088.  Clear<y>? yes
Entry 'status_2012-11-20_14h50m09.csv' in /var/log/status_logs (46956) has deleted/unused inode 47073.  Clear<y>? yes
Entry 'status_2012-11-20_14h55m32.csv' in /var/log/status_logs (46956) has deleted/unused inode 47074.  Clear<y>? yes
Entry 'status_2012-11-26_11h04m36.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47078.  Clear<y>? yes
Entry 'status_2012-11-26_11h54m45.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47082.  Clear<y>? yes
Entry 'status_2012-11-26_12h12m20.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47084.  Clear<y>? yes
Entry 'status_2012-11-26_12h33m52.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47086.  Clear<y>? yes
Entry 'status_2012-11-26_10h51m59.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47077.  Clear<y>? yes
Entry 'status_2012-11-26_11h17m09.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47079.  Clear<y>? yes
Entry 'status_2012-11-26_12h54m11.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47087.  Clear<y>? yes

Pass 3: Checking directory connectivity
'..' in /etc/network/run (46948) is <The NULL inode> (0), should be /etc/network (46953).
Fix<y>? yes

Couldn't fix parent of inode 46948: Couldn't find parent directory entry

Pass 4: Checking reference counts
Unattached inode 46945
Connect to /lost+found<y>? yes

Inode 46945 ref count is 2, should be 1.  Fix<y>? yes
Inode 46953 ref count is 5, should be 4.  Fix<y>? yes

Pass 5: Checking group summary information
Block bitmap differences:  -(208264--208266) -(210062--210068) -(211343--211491) -(213241--213250) -(213344--213393) -213397 -(213457--213463) -(213516--213521) -(213628--213655) -(213683--213688) -(213709--213728) -(215265--215300) -(215346--215365) -(221541--221551) -(221696--221704) -227517
Fix<y>? yes

Free blocks count wrong for group #6 (17247, counted=17611).
Fix<y>? yes

Free blocks count wrong (161691, counted=162055).
Fix<y>? yes

Inode bitmap differences:  +(47089--47090) +47093 +47095 +(47097--47099) +(47101--47104) -(47219--47220) -47222 -47224 -47228 -47231 -(47347--47348) -47350 -47352 -47356 -47359 -(47457--47488) -47985 -47996 -(47999--48000) -48017 -(48027--48028) -(48030--48032) -48049 -(48059--48060) -(48062--48064) -48081 -(48091--48092) -(48094--48096)
Fix<y>? yes

Free inodes count wrong for group #6 (7608, counted=7624).
Fix<y>? yes

Free inodes count wrong (61919, counted=61935).
Fix<y>? yes


embeddedrootwrite: ***** FILE SYSTEM WAS MODIFIED *****

embeddedrootwrite: ********** WARNING: Filesystem still has errors **********

embeddedrootwrite: 657/62592 files (24.4% non-contiguous), 87882/249937 blocks

Embedded-PC-failsafe:~# 
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory entry for '.' in ... (46948) is big.
Split<y>? yes

Missing '..' in directory inode 46948.
Fix<y>? yes

Setting filetype for entry '..' in ... (46948) to 2.
Pass 3: Checking directory connectivity
'..' in /etc/network/run (46948) is <The NULL inode> (0), should be /etc/network (46953).
Fix<y>? yes

Pass 4: Checking reference counts
Inode 2 ref count is 12, should be 13.  Fix<y>? yes

Pass 5: Checking group summary information

embeddedrootwrite: ***** FILE SYSTEM WAS MODIFIED *****
embeddedrootwrite: 657/62592 files (24.4% non-contiguous), 87882/249937 blocks
Embedded-PC-failsafe:~# 
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite: clean, 657/62592 files, 87882/249937 blocks

আপনারা সবাই কী এক্সট 4 বা জেডএফএসে পরিবর্তন করার কথা ভাবেন?
এমডিপিসি

আমি ext4 এ পরিবর্তন করার বিষয়ে ভেবেছি, কমপক্ষে ... এটি কি এই সমস্যার সমাধান করতে সহায়তা করবে? জেডএফএস কি আরও ভাল হতে পারে?
জেরেমি ফ্রাইজনার

1
কোনও বিকল্পই এটি ঠিক করবে না। আমরা এখনও জেডএফএসে সুপার ক্যাপাসিটারগুলির সাথে ডিভাইসগুলি ব্যবহার করি এবং সার্ভার অ্যাপ্লিকেশনগুলিতে এক্সটোর জন্য ব্যাটারি বা ফ্ল্যাশ-সুরক্ষিত ক্যাশে বাঞ্ছনীয়।
ইয়েওয়াইট

উত্তর:


11

আপনি উভয়ই ভুল (সম্ভবত?) ... এক্সট্রাকশন হ'ল আকস্মিকভাবে তার অন্তর্নিহিত স্টোরেজটি সরিয়ে দেওয়ার মাধ্যমে এটি সর্বোত্তমভাবে মোকাবিলা করছে।

আপনার এসএসডি সম্ভবত কিছু ধরণের অনবোর্ড ক্যাশে রয়েছে। আপনি ব্যবহারে এসএসডি এর মেক / মডেলটি উল্লেখ করবেন না তবে এটি ভোক্তা-স্তরের এসএসডি বনাম একটি উদ্যোগ বা শিল্প-গ্রেডের মডেলের মতো মনে হচ্ছে

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

যদি আপনার ড্রাইভের একটি সুপার ক্যাপ না থাকে তবে ফ্লাইটের লেনদেনগুলি হারাতে চলেছে, সুতরাং ফাইল সিস্টেমের দুর্নীতি। ext3 সম্ভবত বলা হচ্ছে যে সবকিছু স্থিতিশীল স্টোরেজে রয়েছে তবে এটি কেবল ক্যাশের একটি ফাংশন।


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

@psusi এসএসডি ব্যবহারে সম্ভবত ওএস_ লেভেল সেটিংস নির্বিশেষে স্পষ্টরূপে ক্যাশে সক্ষম করেছে বা কোনও অভ্যন্তরীণ বাফারের উপর নির্ভর করে। সেই ক্যাশে থাকা ডেটা হ'ল একটি সুপার ক্যাপাসিটার-সক্ষম এসএসডি সুরক্ষিত করবে।
ew white

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

2
@ পুসি ওল্ড এখন, তবে আপনি এটি উল্লেখ করেছেন: as long as the drive correctly reports whether it has a write cache and obeys commands to flush it, the journal guarantees that the metadata will not be inconsistent.এটি জিনিস: স্টোরেজ কন্ট্রোলারগুলির ক্ষেত্রে যেগুলি পুরানো ডিস্কগুলি অনুমান করে, এসএসডিগুলি মাঝে মাঝে ডেটা ফ্লাশ করা হয় কিনা তা সম্পর্কে মিথ্যা বলবে। আপনার সেই সুপার ক্যাপ লাগবে না।
জোয়েল কোয়েল

2

আপনি ঠিক বলেছেন এবং আপনার সহকর্মী ভুল। জার্নালে কিছু ভুল হওয়ার বিষয়টি বাদ দিয়ে তা নিশ্চিত করে যে আপনার কাছে কখনই অসামঞ্জস্যপূর্ণ fs মেটাডেটা নেই। hdparmড্রাইভের রাইট ক্যাশে সক্ষম হয়েছে কিনা তা দেখতে আপনি চেক করতে পারেন। যদি এটি হয় এবং আপনি আইও বাধাগুলি সক্ষম না করে (ext3 এ ডিফল্টরূপে, ext4 এ ডিফল্টরূপে), তবে এটি সমস্যার কারণ হতে পারে।

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


-1 পঠন-বোধগম্যতার জন্য ...
ew white

@ হোয়াইট, সম্ভবত আপনার এই পড়াশোনার অপমানের পরিবর্তে একটি দরকারী প্রতিক্রিয়া লেখার চেষ্টা করা উচিত।
psusi

+1 এই উত্তর সম্ভবত কোনও QA- এ অন্য উত্তর হিসাবে উন্নত করা যেতে পারে। তবে কমপক্ষে কিছু আলো এবং ইঙ্গিত সরবরাহ করে। @ ডাউনভোটার্স: নিজের উত্তরটি উন্নত করুন, বা সম্ভাব্য প্রবাহ সম্পর্কে মন্তব্য করুন, তবে যথাযথ সমর্থন ছাড়াই এই উত্তরটিকে হ্রাস করা কেবল জঘন্য বিষয়!
আলবার্তো
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.