요약

  • 제안된 NFSv4.2 속성은 파일 데이터 캐싱을 제한하려는 서버 측 선호를 표현한다. 이는 특정 클라이언트가 캐시를 비웠거나 이미 열려 있는 파일의 동작을 변경했다는 것을 보증하지 않는다.
  • 방어 가능한 운영 주장을 세우려면 관찰 시점, 오픈 에포크, 읽기 재검증, 위임(delegate) 맥락, 안정 쓰기, COMMIT, 검증자(verifier) 연속성을 담은 두 번째 클라이언트 측 영수증이 필요하다.
  • 이 구분이 중요한 이유는 해당 속성이 선택 사항이고, 자문적(advisory)이며, 파일시스템별이고, 명시적으로 보안 경계가 아니기 때문이다.

정책 비트가 상태를 갖는 클라이언트를 만났을 때

fattr4_uncacheable_file_data의 매력은 즉각적이다. 어떤 파일들은 네트워크 파일시스템이 보통 맺는 성능상 타협, 즉 데이터를 애플리케이션 가까이 두고 프로토콜 규칙으로 재사용이 안전한 시점을 판단하는 방식에 부적합한 후보다. 서버나 관리자는 해당 워크로드가 평소의 캐싱 이득보다 예측 가능한 가시성을 더 중시한다는 것을 안다. 파일별 불리언 값은 이 판단에 프로토콜적 주소를 부여한다.

유혹은 이 불리언을 결과로 읽는 것이다. “참(true)”이 쉽게 “클라이언트들이 이 파일을 캐싱하지 않고 있다”의 축약어가 되기 쉽다. 현재 드래프트는 그 도약을 지지하지 않는다. 이 값은 서버에 존재한다. 클라이언트는 속성을 지원하고, 관련 파일시스템과 파일에 대해 그 값을 얻고, 현재 값을 관찰하고, 그 권고를 자신의 읽기·쓰기 동작으로 변환해야 한다. 이 사건들은 같은 순간에 일어나지 않는다.

이 간극은 이미 사용 중인 파일에서 가장 크다. 드래프트는 파일을 연 상태의 클라이언트가 서버 측 값이 변경된 후에도 기존 캐시 처리를 계속할 수 있도록 허용한다. 클라이언트는 평소의 속성 확인 절차를 통해 새 값을 발견하고 이후 작업에 새 동작을 적용할 수 있다. 이는 합리적인 호환성 선택이다. 그러나 동시에, 서버 속성의 스냅샷은 사고 이후 사람들이 실제로 묻는 운영 질문, 즉 “작업 O가 완료되는 시점에 클라이언트 C는 무엇을 믿고 있었는가?”에 답할 수 없다는 뜻이다.

지원 여부는 익스포트된 파일시스템의 속성이다

속성 87은 읽기·쓰기 가능하며 NFS 속성 표에서 RECOMMENDED로 기술된다. 이 맥락에서 그 표기는 속성을 분류하는 것이며, 모든 NFSv4.2 구현체가 이를 제공하도록 강제하지 않는다. 지원 여부는 같은 머신이 서비스하는 익스포트 파일시스템마다 다를 수 있다. 따라서 클라이언트는 사용 중인 파일시스템의 지원 속성 정보를 직접 확인해야 하며, 서버 제품명이나 다른 익스포트에 대한 성공적 테스트로부터 역량을 추론해서는 안 된다.

이 값의 대상 범위도 의도적으로 좁다. 일반 파일과 이름 있는 속성(named attribute)에만 의미가 있다. 다른 객체 유형에 대한 읽기는 false를 반환하고, 부적절한 유형에 값을 설정하려는 시도는 실패한다. 이 false 값은 파일시스템이 이 메커니즘을 지원하며 정책이 일반 캐싱을 선택했다는 긍정적 진술과 동등하지 않다. 유형, 지원, 값은 근거에서 서로 다른 필드로 유지되어야 한다.

서버 정책도 결과를 한정한다. 구현체는 변경을 허용하거나, 거부하거나, 새로 생성되는 파일에 대한 마운트 옵션 같은 관리 규칙으로 값을 도출할 수 있다. 일반적인 인가 절차가 적용된다. 참 또는 거짓만 저장하는 감사 기록은 누가 결정할 권한이 있었는지, 어떤 정책이 그 값을 만들었는지, 거부된 변경이 이전 값을 그대로 유지했는지를 잃어버린다.

라이트 비하인드(write-behind)는 성공의 의미를 바꾼다

쓰기 경로에서 캐시 제한은 단순히 메모리 사용을 줄이라는 요청이 아니다. 이 속성을 존중하는 클라이언트는 WRITE 작업을 결합하거나 효율을 높이기 위해 지연시켜서는 안 된다. 더 중요하게는, 애플리케이션 쓰기가 성공을 반환할 때 그 데이터는 서버에서 내구성 있게 저장되어 있어야 한다.

그 결과에 도달하는 유효한 경로는 하나가 아니다. 클라이언트는 안정(stable) 쓰기를 요청할 수 있다. 또한 비안정 쓰기를 보낸 뒤 애플리케이션에 성공을 반환하기 전에 COMMIT을 발행할 수도 있다. 서버의 쓰기 검증자가 변경되면 클라이언트는 여전히 보유하고 있는 버퍼에서 해당 데이터를 재전송해야 한다. 드래프트는 진행 중인 쓰기를 완료하는 데 필요한 임시 보관을 금지된 캐싱으로 분류하지 않는다.

이 순서 때문에 “캐시 비움”은 잘못된 감사 목표다. 클라이언트는 내구성을 확립하는 동안 바이트를 정당하게 보유할 수 있다. 운영자에게 필요한 것은 인과적 기록이다. 요청되고 반환된 안정 모드, COMMIT 결과, 이전과 이후의 검증자, 재전송 여부, 애플리케이션 호출이 성공을 허용받은 시점이 그것이다. 이 순서 없이는 서버 속성은 특정 확인된 쓰기가 조사 중인 장애 모드를 통과했는지에 대해 아무것도 말하지 못한다.

신선한 읽기에는 재검증 근거가 필요하다

읽기 경로에서 드래프트는 모든 접근마다 상징적인 퍼지(purge)를 요구하지 않는다. 클라이언트에게 캐시된 파일 데이터를 재검증 없이 재사용하지 말라고 지시할 뿐이다. 최소한 NFS 변경(change) 속성과 파일 크기를 확인하면 그 기대를 충족한다. 클라이언트는 더 많이 확인할 수도 있다.

이 규칙은 확립된 NFSv4.1 모델의 중요한 아이디어를 물려받는다. 캐시 유효성은 벽시계 직관만으로 결정되지 않는다. 변경 속성은 프로토콜 근거의 일부이며, 캐싱은 오픈, 공유 예약(share reservation), 잠금, 위임과 조율된다. 위임은 클라이언트에게 일관된 뷰를 제공하여 새 속성이 참인 경우에도 읽기 캐싱이 적절할 수 있게 한다. 따라서 거버넌스 질문은 메모리 페이지가 존재했는지 여부가 아니라, 클라이언트가 해당 작업에 그 페이지를 사용할 유효한 프로토콜적 근거를 가졌는지 여부다.

유용한 읽기 영수증은 이전 및 관찰된 변경 값, 파일 크기, 재검증이 발생한 시점, 대체 일관성 보장을 제공한 위임이나 잠금을 기록해야 한다. 또한 수행된 조치—재사용, 무효화, 재가져오기, 실패—를 기록해야 한다. 이런 세부 사항이 근거를 반증 가능하게 만든다. 일반적인 컴플라이언스 플래그는 그러하지 못하다.

정책 기록 옆의 관찰 영수증

가장 작은 유용한 근거 모델은 연결된 두 부분으로 구성된다. 서버 기록은 서버와 익스포트된 파일시스템을 식별하고, 속성 87에 대한 지원을 확인하고, 파일 식별자와 값을 저장하고, 정책 출처와 승인자를 명시하고, 관찰 시각을 기록한다. 이는 다음에 답한다. 이 서버가 이 시점에 이 파일에 대해 어떤 처리를 광고했는가?

클라이언트 영수증은 클라이언트 구현체와 버전, 마운트, 파일 핸들, 오픈 에포크를 식별한다. 클라이언트가 그 값을 언제 학습했는지, 파일이 이미 열려 있었는지, 그리고 어떤 후속 작업이 처음으로 새 처리를 사용했는지를 기록한다. 읽기의 경우 변경 값, 크기, 위임 맥락, 캐시 조치를 추가한다. 쓰기의 경우 안정 모드, COMMIT, 검증자 연속성, 재전송, 애플리케이션 반환 시각을 추가한다. 이는 다음에 답한다. 이 클라이언트는 그 권고로 무엇을 했는가?

어느 기록도 다른 기록을 덮어써서는 안 된다. 서버 값이 10시에 바뀌고 이미 파일을 연 클라이언트가 10시 7분에 그것을 관찰했다면, 두 시각 모두 참이다. 이를 하나의 “실효적” 타임스탬프로 합치면 대시보드는 깔끔해지지만, 실제로 중요한 사건이 사라진다.

선택적 채택은 감추어야 할 결함이 아니다

이 제안은 기본 명세를 무효화하지 않고 프로토콜 기능을 추가하기 위해 정의된 메커니즘을 통해 NFSv4.2를 확장한다. 이는 선택 사항이며, 명시된 불변 조건 내에서 클라이언트 동작은 유연하게 유지된다. 이는 정상적인 프로토콜 진화다. 그것은 플릿(fleet) 보고가 최신 의미 체계를 보편적인 것처럼 제시하는 대신 역량 분포를 보여주어야 한다는 뜻이다.

드래프트의 구현 현황 절은 Hammerspace 서버 프로토타입과, 구성된 마운트 지점 아래의 파일에 대해 다이렉트 I/O와 유사한 동작을 사용하는 Linux 클라이언트를 기술한다. 적합한 워크로드에 대해 성능 및 자원 이득을 보고한다. 이는 가치 있는 구현 근거이지만, 모든 클라이언트가 같은 설계를 사용하거나 같은 결과를 얻으리라는 약속은 아니다. “다이렉트 I/O와 유사함”이 조용히 “다이렉트 I/O임”으로 승격되어서는 안 되고, 하나의 프로토타입이 이질적 환경의 기대 기준이 되어서도 안 된다.

따라서 실용적인 도입 보고서는 미지원, 지원되나 미설정, 설정되었으나 아직 관찰되지 않음, 새 작업에 대해 관찰됨, 작업 영수증을 통해 검증됨을 구분해야 한다. 그 분포가 채택의 최전선을 드러낸다. 단일한 초록 퍼센트는 그것을 숨긴다.

이 속성은 보안 주장을 담을 수 없다

드래프트는 이 속성이 새로운 인가 또는 접근 제어 메커니즘을 도입하지 않으며 접근 결정에 사용되어서는 안 된다고 명시한다. 이 값은 다른 클라이언트들의 성능 및 가시성 동작에 영향을 줄 수 있으므로, 이를 설정할 권한 자체는 여전히 중요하다. 그러나 이 값은 무결성 봉인도, 기밀성 통제도, 스테일 데이터가 불가능하다는 증명도 아니다.

이 경계는 제품 문구와 사고 보고에서도 살아남아야 한다. 관리자는 정책이 제한된 캐싱을 요청했다고 정확히 말할 수 있다. 측정된 클라이언트가 읽기를 재검증했거나 반환 전에 쓰기를 내구성 있게 만들었다고도 정확히 말할 수 있다. 그러나 이 두 진술을 결합하여 속성이 보안 경계를 만들었다는 더 큰 주장으로 만들어서는 안 된다.

여기서 달성할 수 있는 유용한 것은 더 소박하고 더 운영적이다. 프로토콜이 서버의 선호를 표준화된 필드에 담을 수 있다는 것이다. 별도의 관찰 영수증을 갖추면 운영자는 그 선호가 어디서 클라이언트 동작이 되었고, 어디서 그렇지 않았으며, 왜 그랬는지를 검증할 수 있다.

출처