SSD 드라이브의 ext3 파티션에서 갑작스런 전원 손실 파일 시스템 손상이 “예상 동작”입니까? 특히, 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 명령을 자동으로 무시합니다. 이는 저널이 작업을 수행하지 못하게합니다.


답변