kernel: lỗi cam kết I / O

9

Tôi gặp một số vấn đề với máy chủ Dell 1950. Tôi đang cài đặt RHEL 4.6 cùng với Oracle và một số phần mềm khác tại đây.

Tôi ngẫu nhiên nhận được thông báo lỗi có nội dung "kernel: Nhật ký cam kết lỗi I / O" trên phiên ssh của tôi và trên màn hình tôi đã nối với máy chủ Tôi thấy một lỗi cuộn qua đó có lỗi "EXT3-fs (thiết bị sda5) trong start_transaction: Tạp chí đã bị hủy bỏ. "

Nó đã xảy ra nhiều lần nhưng không bao giờ tại cùng một điểm trong quá trình cài đặt. Trên thực tế, lần cuối cùng hệ thống này hoạt động và tôi chỉ đang cố gắng nhập một cơ sở dữ liệu vào orory.

Điều này đã xảy ra trên một số ổ đĩa cứng, vì vậy tôi khá chắc chắn rằng đó không phải là vấn đề. Điều này khiến tôi nghĩ rằng bộ điều khiển đột kích đang trở nên tồi tệ.

các bạn nghĩ sao?

** CẬP NHẬT **

Khá chắc chắn rằng đó là một ổ cứng xấu. Tôi đã ném một ổ đĩa khác trong máy chủ và nó đã chạy được khoảng 48 giờ với các sự cố.

linux raid ext3

— jasondewitt
nguồn

9

Tôi đã thấy những lỗi đó trước đây, nhưng không phải trong quá trình cài đặt.

Điều đó có nghĩa là ổ đĩa đã có đủ lỗi mà HĐH đưa nó sang chế độ chỉ đọc. Nếu bạn có thể tìm thấy nhật ký đầy đủ, có thể có một số lỗi I / O đã thử lại và hoạt động trước các lỗi thất bại đầy đủ mà bạn thấy. Một cái gì đó với các khối thực tế được đề cập.

Đó là một lỗi hệ thống lưu trữ. Đó chắc chắn là thẻ RAID, các ổ đĩa trong mảng RAID, dây cáp từ thẻ đến ổ đĩa, bảng nối đa năng mà các ổ đĩa kết nối với, khe cắm thẻ đột kích được cắm vào, nguồn điện cho ổ đĩa cứng hoặc thứ gì khác trong giữa CPU và các khối lưu trữ thực tế.

— tự do
nguồn

2

Ba khả năng xuất hiện trong tâm trí:

Có vấn đề về bộ nhớ (chúng thường gây ra sự cố "ngẫu nhiên"). Nếu bạn có ram ECC trong đó, thì rõ ràng nó sẽ ít xảy ra hơn.
Có một số vấn đề với xe buýt. Tôi đã gặp vấn đề tương tự với bộ điều khiển APIC bị hỏng trên bo mạch chủ Opteron kép Tyan vài năm trước. Có các mục nhật ký khác gợi ý về nó, nhưng phần lớn các triệu chứng là tham nhũng ngẫu nhiên trên các ổ đĩa với các bản ghi lại chỉ đọc tự động. Trong trường hợp của tôi, tôi biết nó không liên quan đến đĩa vì nó là hộp RAID FC bên ngoài và nó vẫn ổn.
Bộ điều khiển RAID là bunk.

Đây là thứ tự tôi sẽ xem xét các vấn đề.

— Alexandre Carmel-Veilleux
nguồn

Có lẽ không phải là vấn đề bộ nhớ; những thứ đó sẽ có nhiều khả năng gây ra lỗi phân tách và nhiều lỗi ngẫu nhiên hơn, không bị hạn chế chỉ lưu trữ.

— freiheit

Thật. Nhưng trong tình huống cài đặt hoặc khởi động sớm, việc sử dụng bộ nhớ lớn là bộ đệm-bộ đệm để các vấn đề có xu hướng xuất hiện ở đó trước tiên. Khi máy đã chạy một số tải trong một thời gian, quá trình người dùng sẽ chiếm ưu thế I / O của bộ nhớ và do đó mức độ phổ biến của segfault. Điều đó đang được nói, một PE1950 nên có bộ xử lý Xeon và ram ECC để RAM có thể phát hiện và báo cáo với Linux.

— Alexandre Carmel-Veilleux

2

Nó có thể là bộ điều khiển RAID bị hỏng như bạn đã nói (hãy thử một cái dự phòng nếu bạn có.) Nó có thể là trình điều khiển cho bộ điều khiển (kiểm tra các trình điều khiển thay thế nếu có, ngay cả khi hiệu suất kém hơn, thật tốt khi có điểm tham chiếu .) Nó có thể là hạt nhân (ít có khả năng mặc dù trong RHEL, nó đã được kiểm tra khá tốt.) Nó có thể là RAM xấu làm hỏng bộ đệm khối.

Tuy nhiên, một vấn đề phần cứng là nguyên nhân rất có thể, dựa trên hành vi lỗi dường như ngẫu nhiên.

— Mihai Limbăşan
nguồn

2

Kiểm tra xem đĩa không đầy đủ - đặc biệt là phân vùng gốc. Sử dụng df để xem việc sử dụng đĩa hệ thống tập tin:

df -h

Tìm các phân vùng gần hoặc bằng 100% sử dụng

— Peter H
nguồn

-5

thử:

tắt máy -rF ngay