Là sự cố hệ thống tập tin mất điện đột ngột trên phân vùng ext3 của ổ SSD.

Công ty của tôi tạo ra một thiết bị Debian Linux nhúng khởi động từ phân vùng ext3 trên ổ SSD bên trong. Bởi vì thiết bị là một "hộp đen" nhúng, nên nó thường tắt theo cách thô lỗ, chỉ bằng cách cắt nguồn cho thiết bị thông qua một công tắc bên ngoài.

Điều này thường ổn, vì nhật ký của ext3 giữ mọi thứ theo thứ tự, do đó, ngoài việc thỉnh thoảng mất một phần của tệp nhật ký, mọi thứ vẫn ổn.

Tuy nhiên, gần đây chúng tôi đã thấy một số đơn vị sau khi một số chu kỳ cấp điện cứng, phân vùng ext3 bắt đầu phát triển các vấn đề về cấu trúc - đặc biệt, chúng tôi chạy e2fsck trên phân vùng ext3 và nó tìm thấy một số vấn đề như thế hiển thị trong danh sách đầu ra ở cuối Câu hỏi này. Chạy e2fsck cho đến khi nó dừng báo cáo lỗi (hoặc định dạng lại phân vùng) sẽ xóa các vấn đề.

Câu hỏi của tôi là ... những tác động của việc nhìn thấy các vấn đề như thế này trên hệ thống ext3 / SSD đã bị tắt máy đột ngột / bất ngờ là gì?

Cảm giác của tôi là đây có thể là dấu hiệu của sự cố phần mềm hoặc phần cứng trong hệ thống của chúng tôi, vì tôi hiểu là (chặn lỗi hoặc sự cố phần cứng) tính năng ghi nhật ký của ext3 được cho là để ngăn các loại lỗi toàn vẹn hệ thống tệp này. (Lưu ý: Tôi hiểu rằng dữ liệu người dùng không bị xóa và do đó, các tệp người dùng bị cắt / thiếu / bị cắt có thể xảy ra; Tôi đặc biệt nói ở đây về các lỗi siêu dữ liệu của hệ thống tệp như những lỗi được hiển thị bên dưới)

Đồng nghiệp của tôi, mặt khác, nói rằng đây là hành vi đã biết / dự kiến ​​vì bộ điều khiển SSD đôi khi đặt hàng lại các lệnh ghi và điều đó có thể khiến tạp chí ext3 bị nhầm lẫn. Đặc biệt, ông tin rằng ngay cả khi được cung cấp phần cứng và phần mềm không có lỗi hoạt động bình thường, tạp chí ext3 chỉ làm cho hệ thống tập tin ít bị hỏng, không phải là không thể, vì vậy thỉnh thoảng chúng ta không nên ngạc nhiên khi thấy những vấn đề như thế này.

Ai trong chúng ta đúng?

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

Cả hai bạn đều sai (có thể?) ... ext3 đang đối phó tốt nhất có thể với việc lưu trữ bên dưới của nó bị xóa quá đột ngột.

SSD của bạn có thể có một số loại bộ nhớ cache trên bo mạch. Bạn không đề cập đến kiểu sản xuất / kiểu SSD đang sử dụng, nhưng âm thanh này giống như SSD cấp độ người tiêu dùng so với mô hình cấp doanh nghiệp hoặc cấp công nghiệp .

Dù bằng cách nào, bộ đệm được sử dụng để giúp ghi lại và kéo dài tuổi thọ của ổ đĩa. Nếu có văn bản quá cảnh, việc mất điện đột ngột chắc chắn là nguồn gốc của tham nhũng của bạn. Các ổ SSD công nghiệp và doanh nghiệp thực thụ có các siêu tụ điện duy trì nguồn điện đủ lâu để di chuyển dữ liệu từ bộ nhớ cache sang bộ lưu trữ không biến đổi, giống như cách mà bộ điều khiển RAID hỗ trợ pin và flash hỗ trợ .

Nếu ổ đĩa của bạn không có siêu xe, các giao dịch trên chuyến bay sẽ bị mất, do đó hệ thống tập tin bị hỏng. ext3 có thể được thông báo rằng mọi thứ đều được lưu trữ ổn định, nhưng đó chỉ là một chức năng của bộ đệm.

Bạn đúng và đồng nghiệp của bạn sai. Việc chặn một cái gì đó không đúng trong tạp chí đảm bảo bạn không bao giờ có siêu dữ liệu fs không nhất quán. Bạn có thể kiểm tra hdparmxem liệu bộ đệm ghi của ổ đĩa có được bật hay không. Nếu đúng như vậy và bạn chưa kích hoạt các rào cản IO (tắt theo mặc định trên ext3, theo mặc định trong ext4), thì đó sẽ là nguyên nhân của vấn đề.

Các rào cản là cần thiết để buộc bộ đệm ghi bộ đệm ghi vào đúng thời điểm để duy trì tính nhất quán, nhưng một số ổ đĩa hoạt động kém và báo cáo rằng bộ đệm ghi của chúng bị vô hiệu hóa khi không, hoặc âm thầm bỏ qua các lệnh tuôn ra. Điều này ngăn tạp chí thực hiện công việc của nó.