SSD 드라이브의 ext3 파티션에서 갑작스런 전원 손실 파일 시스템 손상이 "예상 동작"입니까?

우리 회사는 내장 SSD 드라이브의 ext3 파티션에서 부팅하는 내장 Debian Linux 장치를 만듭니다. 장치는 내장 된 "블랙 박스"이므로 일반적으로 외부 스위치를 통해 장치의 전원을 차단하여 무례한 방식으로 종료됩니다.

일반적으로 ext3의 저널링은 일을 순서대로 유지하므로 로그 파일의 일부가 손실되는 경우를 제외하고는 일이 잘 진행됩니다.

그러나 최근 우리는 여러 하드 사이클 후 ext3 파티션이 구조적 문제를 일으키기 시작하는 여러 단위를 보았습니다. 특히 ext3 파티션에서 e2fsck를 실행하면 이와 같은 여러 가지 문제가 발견됩니다. 이 질문의 맨 아래에있는 출력 목록에 표시됩니다. 오류보고가 중지되거나 파티션을 다시 포맷 할 때까지 e2fsck를 실행하면 문제가 해결됩니다.

내 질문은 ... 갑작 스럽거나 예기치 않은 종료가 많이 발생한 ext3 / SSD 시스템에서 이와 같은 문제를 발견하면 어떤 영향을 미칩니 까?

내 생각은 (버그 또는 하드웨어 문제를 제외하고) ext3의 저널링 기능이 이러한 종류의 파일 시스템 무결성 오류를 방지한다고 가정하기 때문에 시스템에서 소프트웨어 또는 하드웨어 문제의 징후 일 수 있습니다. (참고 : 사용자 데이터가 저널링되지 않았기 때문에 munged / missing / truncated user-file이 발생할 수 있음을 이해합니다. 특히 아래에 표시된 것과 같은 파일 시스템 메타 데이터 오류에 대해 이야기하고 있습니다)

반면, 저의 동료는 SSD 컨트롤러가 때때로 쓰기 명령의 순서를 바꾸고 ext3 저널이 혼동 될 수 있기 때문에 이것이 알려진 / 예상 된 동작이라고 말합니다. 특히, ext3 저널은 정상적으로 작동하는 하드웨어 및 버그가없는 소프트웨어라고하더라도 파일 시스템이 손상 될 가능성이 적고 불가능하지 않다고 믿기 때문에 때때로 이와 같은 문제를보고 놀랄 필요는 없습니다.

우리 중 어느 것이 옳습니까?

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

둘 다 잘못되었을 수도 있습니다 (아마?) ... ext3은 기본 저장소를 갑자기 제거하여 최대한 최선을 다하고 있습니다.

SSD에는 아마도 온보드 캐시가 있습니다. 사용중인 SSD의 제조업체 / 모델에 대해서는 언급하지 않았지만 이는 소비자 수준 SSD와 엔터프라이즈 또는 산업 등급 모델 과 비슷합니다 .

어느 쪽이든, 캐시는 드라이브의 쓰기를 통합하고 수명을 연장시키는 데 사용됩니다. 전송 중에 쓰기가있는 경우 갑작스런 전원 손실이 분명히 손상의 원인입니다. 진정한 엔터프라이즈 및 산업용 SSD에는 배터리 지원 및 플래시 지원 RAID 컨트롤러 캐시 작동 방식과 매우 유사한 방식으로 데이터를 캐시에서 비 휘발성 스토리지로 이동하기에 충분한 전력을 유지하는 슈퍼 커패시터 가 있습니다 .

드라이브에 수퍼캡이 없으면 기내 트랜잭션이 손실되어 파일 시스템이 손상됩니다. ext3은 모든 것이 안정적인 스토리지에 있다고 말하고 있지만 이는 캐시의 기능 일뿐입니다.

당신이 옳고 동료가 틀 렸습니다. 저널에 문제가 발생하지 않으면 fs 메타 데이터가 일치하지 않습니다. hdparm드라이브의 쓰기 캐시가 활성화되어 있는지 확인할 수 있습니다 . 켜져 있고 IO 장벽을 활성화하지 않은 경우 (ext3에서는 기본적으로 꺼져 있고 ext4에서는 기본적으로 켜져 있음) 이것이 문제의 원인 일 수 있습니다.

일관성을 유지하기 위해 올바른 시간에 드라이브 쓰기 캐시를 강제로 플러시하기 위해서는 장애가 필요하지만 일부 드라이브는 제대로 작동하지 않으며 쓰기 캐시가 비활성화 된 경우 쓰기 캐시가 비활성화되었다고보고하거나 flush 명령을 자동으로 무시합니다. 이는 저널이 작업을 수행하지 못하게합니다.