장벽이있는 SATA 드라이브의 쓰기 캐시 안전


13

SATA 드라이브에 대한 쓰기 캐싱, NCQ, 펌웨어 버그, 장벽 등에 대해 최근에 읽었으며 정전시 데이터를 안전하게 보호 할 수있는 최상의 설정이 무엇인지 잘 모르겠습니다.

내가 이해 한 바에 따르면 NCQ를 통해 드라이브는 쓰기를 재정렬하여 성능을 최적화하고 커널에 어떤 요청이 실제로 작성되었는지 알려줍니다.

쓰기 캐시는 데이터가 물리적 디스크에 기록 될 때까지 기다리지 않기 때문에 드라이브가 훨씬 더 빠르게 요청을 처리하도록합니다.

NCQ와 쓰기 캐시가 어떻게 혼합되어 있는지 잘 모르겠습니다.

특별히 저널링 된 파일 시스템은 특정 요청이 기록 될 때 확인해야합니다. 또한 사용자 공간 프로세스는 fsync ()를 사용하여 특정 파일을 강제로 플러시합니다. 파일 시스템이 데이터가 디스크에 기록되었음을 확신 할 때까지 fsync ()에 대한 호출은 반환되지 않아야합니다.

SAS 드라이브에서만 볼 수있는 기능 (FUA, Force Unit Access)이 있습니다.이 기능은 드라이브가 캐시를 무시하고 디스크에 직접 쓰도록합니다. 다른 모든 것에는 쓰기 장벽이 있는데, 이는 드라이브에서 캐시 플러시를 트리거 할 수있는 커널에서 제공하는 메커니즘입니다. 이렇게 하면 중요한 데이터뿐만 아니라 모든 캐시가 강제 로 기록되므로 남용 된 경우 fsync ()와 같이 전체 시스템 속도가 느려집니다.

펌웨어 버그가 있거나 데이터가 실제로 쓰여졌을 때 의도적으로 거짓말을하는 드라이브가 있습니다.

드라이브 / 파일 시스템을 설정하는 몇 가지 방법이 있습니다. A) NCQ 및 쓰기 캐시 비활성화 B) NCQ 만 활성화 C) 캐시 쓰기 만 활성화 D) NCQ 및 쓰기 캐시 활성화

장벽이 활성화되어 있다고 가정합니다. BTW, 실제로 활성화되어 있는지 확인하는 방법은 무엇입니까?

정전이 발생하면 디스크에 적극적으로 쓰는 동안 옵션 B (NCQ, 캐시 없음)가 파일 시스템 저널 및 데이터 모두에 안전하다고 생각합니다. 성능이 저하 될 수 있습니다.

배리어 또는 FUA를 사용하는 경우 옵션 D (NCQ + 캐시)는 파일 시스템 저널 및 fsync ()를 사용하는 응용 프로그램에 안전합니다. 캐시에서 대기중인 데이터는 좋지 않으며, 파일 시스템이 데이터를 감지하고 (체크섬) 적어도 파일 시스템은 불안정한 상태가 아닙니다. 성능면에서 더 좋습니다.

그러나 내 질문은 의미가 있습니다 ... 나는 아무것도 놓치고 있습니까? 고려해야 할 다른 변수가 있습니까? 이를 확인할 수있는 도구가 있습니까? 드라이브가 정상적으로 작동합니까?


귀하의 상황에서 응용 프로그램은 무엇입니까? 설정에서 RAID 컨트롤러와 해당 캐시의 영향을 간과하고 있습니다. 어떤 운영 체제에 중점을두고 있습니까? 어떤 파일 시스템을 고려하고 있습니까?
ewwhite

특정 응용 프로그램이 없습니다. 나는 수년간 소프트웨어 raid1을 사용해 왔지만 쓰기 캐시가 나타내는 문제를 결코 파헤 치지 않습니다. 또한 신뢰할 수있는 fsck가없는 btrfs를 살펴본 결과 손상을 방지하기 위해 어떻게 할 수 있는지에 대한 의문이 생깁니다.
julianjm

1
Linux에서 ZFS를 대신 사용하고 특수 제작 된 ZIL 장치와 연결하십시오. ZFS 시스템 용 DDRDrive 를 사용합니다 :)
ewwhite

FUSE와 함께 ZFS를 사용하고 있습니까?
julianjm

2
UPS를 반드시 받으십시오.
Michael Hampton

답변:


11

직접 엔터프라이즈 시스템의 경우 스토리지 어댑터 (거의 항상 RAID 카드) 형태의 추가 계층이 있으며 여기에는 또 다른 계층의 캐시가 있습니다. 요즘 스토리지 스택에는 많은 추상화가 있으며, I / O알고 있는 블로그 시리즈에서 자세히 설명했습니다 .

RAID 카드는 온 디스크 캐시를 우회 할 수 있으며, 일부는 RAID BIOS에서이 기능을 토글 할 수도 있습니다. 이것이 Enterprise 디스크 가 Enterprise 인 이유 중 하나입니다. 펌웨어가 소비자 드라이브 ( 특히 '그린'드라이브)가하지 못하는 것을 허용합니다. 이 기능은 다음과 같은 문제를 직접 해결합니다. 커밋되지 않은 쓰기로 인한 정전. 배터리 또는 플래시로 백업되어야하는 RAID 카드 캐시는 전원이 다시 공급되고 쓰기가 다시 시작될 때까지 보존됩니다.

특정 엔터프라이즈 SSD에는 전원을 완전히 끄기 전에 온보드 캐시를 커밋 할 수있는 충분한 용량을 갖춘 온보드 커패시터가 포함되어 있습니다.

디스크가 마더 보드에 직접 연결된 시스템으로 작업하는 경우 보장이 줄어 듭니다. 디스크 자체가 쓰기 캐시를 커밋 할 수 없다면, 전원 장애는 실제로 손실을 일으킬 것입니다. 때문에 그냥이 고장 모드를 살아 남기 위해 그것의 무능력에 신뢰성에 대한 명성을 얻었 파일 시스템; 스토리지의 존속성을 위해 완전한 엔터프라이즈 시스템에서 실행되도록 설계되었습니다.

그러나 시간이 지남에 따라 XFS는이를 극복하도록 설계되었습니다. 다른 주요 Linux 파일 시스템 ( Windows의 )은 이미이 실패 모드를 견뎌 낼 수있는 엔지니어링 기능을 갖추고 있었습니다 . 제대로 작동하지 않는 방법은 손실 된 쓰기가 FS 저널에 표시되지 않고 기록되지 않았다는 것을 알게되므로 부패가 안전하게 감지되고 해결됩니다.

여기서 한 가지 문제, 즉 디스크 펌웨어가 있습니다. 이 경우 FS 저널은 현실과 비교하여 잘못된 가정을했을 것이며 한동안 부패가 감지되지 않을 수 있습니다. 패리티 RAID 및 미러 RAID는 다른 커밋 된 사본을 가져와야하므로이 문제를 해결할 수 있습니다. 그러나 단일 디스크 설정에는 교차 검사가 없으므로 실제로 오류가 발생합니다.

훨씬 더 많은 검증을 받고 (예상 작업 부하 패턴과 비교하여 테스트 된) 엔터프라이즈 급 드라이브를 사용하고 그러한 불확실한 상황에서도 생존 할 수 있도록 스토리지 시스템을 설계함으로써 펌웨어 위험을 극복 할 수 있습니다.


하드웨어 RAID 하에서 캐싱 (배터리로 백업)을 수행하는 것은 컨트롤러의 책임이며 실제 디스크 캐시를 비활성화하는 것이 좋습니다. 내 경우에는 (내가 언급하지 않았 음) 소프트웨어 공격대를 사용하고 있습니다. 쓰기 캐시는 데이터 손실을 유발하므로 권장하지 않는 것 같습니다. 어쩌면 재앙이 아닌 (파일 시스템 손상) 데이터 어쨌든 손실 될 수 있습니다. 나는 당분간 내 softraid1 + ext4를 btrfs + raid1로 마이그레이션하는 것을 삼가겠다. :)
julianjm

RAID는 데이터를 두 드라이브 쓰기 캐시에 하나의 드라이브처럼 쉽게 저장할 수 있기 때문에이를 지원하지 않습니다.
psusi

@psusi 100 % 완화는 아니지만 추가 보호 기능을 제공 합니다. 타이밍 문제입니다. 개별 RAID 구현은 다릅니다.
sysadmin1138

전혀 완화가 아닙니다. 충돌이 발생하면 기본 드라이브가 복구하기 위해 보조 드라이브에 다시 복사되므로 보조 드라이브는 전혀 중요하지 않습니다. 따라서 쓰기가 (첫 번째) 드라이브에 기록되었는지 여부로 돌아갑니다.
psusi

3

파일 시스템 저널은 원래 드라이브 쓰기 캐시가 없다고 가정하고 메타 데이터에 대한 쓰기를 발행하기 전에 저널에 대한 쓰기가 완료되기를 기다렸습니다. 드라이브 쓰기 캐싱을 사용하면이 가정이 깨지고 데이터가 손실 될 수 있습니다. 따라서 장벽이 만들어졌습니다. 장벽을 사용하면 디스크에서 쓰기 캐싱을 사용하는 경우에도 저널은 메타 데이터에 쓰기 전에 저널 쓰기가 완료되도록 할 수 있습니다. 드라이브가 쓰기 캐시가 있고 활성화 된 것으로보고하면 디스크 드라이버 계층에서 배리어는 후속 IO가 전송되기 전에 디스크 캐시 플러시를 강제합니다. 그렇지 않으면, 이것이 필요하지 않으므로 장벽은 이전 IO가 완료 될 때까지 후속 IO가 드라이브에 발행되는 것을 방지합니다. NCQ는 하나 이상의 보류중인 요청이 완료 될 때까지 기다려야 더 많은 것을 발행 할 수 있음을 의미합니다.


장벽이 저널 손상으로부터 파일을 보호한다고 생각하지만 (파일 시스템이 요청하는 경우) 파일의 실제 데이터에 대해 잘 모르겠습니다. 모든 쓰기 후에 캐시 플러시를 실행하면 쓰기 캐시가 쓸모 없게됩니다. ?
julianjm

@julianjm, 물론 ... NCQ 또는 드라이브 쓰기 캐시 유무에 관계없이 충돌시 캐시 된 파일 데이터는 항상 손실됩니다.
psusi
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.