4.3. Ceph 파일 시스템

사용자 공간 Ceph 파일 시스템(CephFS)은 업그레이드 후 예상대로 작동합니다.

이전에는 클러스터 업그레이드 중에 사용자 공간 CephFS 클라이언트가 충돌하는 경우가 있었습니다. 이는 사용자 공간 측에 보관된 MDS 측의 오래된 기능 비트로 인해 발생했습니다.

큰 세션 메타데이터에 대한 블록 목록 및 클라이언트 제거

이전에는 MDS의 대규모 클라이언트 메타데이터 빌드로 인해 MDS가 읽기 전용 모드로 전환되는 경우가 있었습니다.

연결 해제 및 재통합 요청 간에 교착 상태가 발생하지 않음

이전 버전에서는 async dirop 버그를 수정할 때 이전 커밋에 의해 회귀 문제가 발생하여 unlink 및 reintegration 요청 간의 교착 상태가 발생했습니다.

클라이언트는 항상 caps revocation acknowledgement를 MDS 데몬에 전송합니다.

이전 버전에서는 MDS 데몬이 CAPs revocation 요청을 클라이언트에 전송하고 이 시간 동안 클라이언트가 inode를 해제하고 inode를 제거한 경우 클라이언트에서 요청을 직접 삭제했지만 MDS 데몬은 클라이언트에서 caps revoking 승인을 기다려야 했습니다. 이로 인해 caps 취소가 필요하지 않은 경우에도 MDS 데몬이 클라이언트의 승인을 계속 대기하여 MDS Daemon 상태에 경고가 발생합니다.

MDS 잠금은 올바른 순서로 가져옵니다.

이전에는 MDS에서 메타데이터 트리 잠금을 잘못된 순서로 취득하여 생성 및 getattr RPC 요청 교착 상태에 도달했습니다.

CephFS MDS에서 split_realms 정보 전송 건너뛰기

이전에는 split_realms 정보가 CephFS MDS에서 잘못 전송되어 kclient 에서 올바르게 디코딩할 수 없었습니다. 이로 인해 클라이언트는 split_realms 에 대해 중요하지 않고 손상된 snaptrace로 처리합니다.

플래그 쓰기를 설정한 후 스냅샷 데이터가 더 이상 손실되지 않음

이전 버전에서는 클라이언트에서 Fb caps를 사용할 때 쓰기 플래그가 '1'로 설정된 경우 더티 용량의 경우 건너뛰고 기존 capsnap을 재사용했습니다. 이로 인해 연속 스냅샷을 덮어쓰고 데이터가 손실됩니다.

스레드 이름 변경이 더 이상 실패하지 않음

이전에는 이름을 바꾸는 동안 몇 가지 드문 경우에서 다른 스레드가 dst dentry를 조회하려고 하면 일관되지 않은 결과를 얻을 수 있었습니다. 여기서 src dentry 및 dst dentry가 동일한 inode에 동시에 연결됩니다. 이로 인해 두 개의 다른 dentries가 동일한 inode에 연결되어 있기 때문에 이름 변경 요청이 실패합니다.

취소 요청이 더 이상 중단되지 않음

이전 버전에서는 취소 요청이 전송되기 전에 'seq'를 늘리기 전에 클라이언트가 해당 제한을 해제하고 이전 seq 를 사용하여 cap update 요청을 보낸 경우 MDS에서 seq (s) 및 cap calculation을 확인하는 것을 누락했습니다. 이로 인해 취소 요청이 무한하게 중단되고 클라이언트에서 응답하지 않는 취소 요청에 대한 경고가 발생합니다.

MDLog::_recovery_thread에서 오류가 정상적으로 처리됨

이전에는 Cryostat 테스트에서 발행하지 못하여 MDS가 이미 차단 목록에 있는 경우 쓰기가 실패했습니다. 예를 들어 Cryostat test_rebuild_moved_file (tasks/data-scan)은 이러한 이유로 실패합니다.

Ceph 클라이언트에서 알람을 보내기 전에 지연 발생 원인을 확인합니다.

이전에는 Ceph에서 지연 OSD에 대한 잘못된 경고 경고를 보내는 경우가 있었습니다. 예를 들어 지연 OSD로 인한 X 클라이언트 지연이 발생합니다. 이러한 경고는 지연이 실제로 OSD로 인해 발생했는지 확인하지 않고 다른 원인으로 인해 발생하지 않았습니다.