OmniOS / ZFS / Windows 7 : CIFS / SMB를 초과하는 모든 파일 크기에 대해 응용 프로그램 내에서 “다른 이름으로 저장”이 5 초 지연됨 정보를 제거하는 동안 사용했으며

상태:

SMB를 통해 Windows 및 OS X 게스트에 파일을 제공하는 OmniOS r151018 (95eaa7e)을 실행하는 단일 파일 서버에서 다음과 같은 이상한 문제가 발생했습니다.

SMB 공유에서 “다른 이름으로 저장 …”대화 상자 창을 통해 특정 파일 (.docx, .xlsx, 일부 이미지)을 저장하면 약 3 ~ 5 초의 지연이 발생하며, 이후 응용 프로그램이 전혀 응답하지 않습니다. 파일이 정상적으로 저장됩니다.

이 문제는 서버에 아무 작업도하지 않고 “야간”발생했지만, 사용자 불만이 처음 발생한 후 일정 시간이 지나서 정확한 날짜를 정확히 찾아내는 것은 어렵습니다. 서버를 재부팅 한 후 미러 된 루트 풀의 하나의 vdev를 사용할 수 없지만 자세히 검사하면 장치에서 결함을 발견하지 못하여 풀에 다시 연결되었습니다. 문제는 여전히 지속됩니다.

일부 관찰 :

  • 모든 Windows 7 클라이언트에서 발생합니다
  • 모든 파일 크기에서 발생합니다
  • 권한에 관계없이이 시스템의 모든 공유에서 발생합니다.
  • 다른 서버에서 iSCSI를 통해 호스트로 가져온 스토리지를 더 빠르게 처리합니다.
  • 일반 복사 속도는 GBit 이더넷에서 110MB / 초입니다.
  • 데이터와 루트 풀이 정상인 것 같습니다
  • 다른 파일 서버에서는 발생하지 않습니다
  • 파일을 로컬에 저장 한 다음 탐색기를 통해 복사하면 발생하지 않습니다.
  • OS X에서는 발생하지 않습니다 (OpenOffice에서만 테스트 할 수 있음)
  • dmesgNOTICE: bge0: interrupt: flags 0x0 - not updated?다양한 값 을 가진 몇 개의 카운트를 보여 주지만 , 이것은 또한 이전의 경우였으며 해를 끼치 지 않았습니다.

추가 아이디어 / 계획 :

명확한 오류 메시지가 없으므로 원인을 찾기 위해 시행 착오를 수행해야 할 수도 있습니다. 내가 고려해야 할 것들 ( 결과는 이탤릭체로 표시됨 ) :

  • Broadcom 네트워크 카드를 인텔 카드로 교체 => 변경하지 않았습니다
  • 루트 풀을 SATA SSD로 교체하십시오 (현재 3 년 동안 잘 작동 한 SLC 메모리 USB 스틱) => 차이가 없었습니다.
  • 사이에 네트워크를 확인하십시오 (하드웨어, 서버에 직접 연결하여)
  • WireShark을 통한 트래픽 캡처 : 정확히 무엇을 찾고 있는지 모를 경우 어려움
  • 소프트웨어 충돌을 배제하기 위해 이전 OmniOS 부트 환경 / 버전으로 되돌리기 => 차이가 없었습니다
  • 버그를 배제하기 위해 Windows / Office 업데이트 롤백

  • 와 파일을 제거 :ewwhite에 의해 생성 된 레딧 스레드에서 txgsync에 의해 스냅 샷, 제안에서 파일 이름에 (콜론) 차이를하지 않았다> =

    Windows “이전 버전”기능이 “:”문자를 포함하는 자동 스냅 샷으로 활성화 된 경우 이와 비슷한 것을 보았습니다. 이것만으로 바람을 쏘지 만 Windows 파일 이름에는 “:”문자가 허용되지 않으므로 살펴볼 가치가 있습니다.

  • 파일 액세스 모니터링 : shodanshok이 제안한대로이 스크립트 를 사용 DTrace하여 파일 액세스를 모니터링했습니다. 이미 열려있는 파일을 저장하고 관련없는 출력과 개인 정보를 제거하는 동안 사용했으며 결과는 세 파일 주위에 있습니다.

    CPU ID       FUNCTION:NAME
1   18753    fop_open:entry Open: Workbook
0   18181 fop_create:return Create: temp_1
0   18753    fop_open:entry Open: temp_1
0   18753    fop_open:entry Open: Workbook
0   18753    fop_open:entry Open: Workbook
0   18753    fop_open:entry Open: temp_1
0   18888  fop_rename:entry Rename: Workbook -> temp_2
0   18888  fop_rename:entry Rename: temp_1 -> Workbook
0   18753    fop_open:entry Open: Workbook
0   18753    fop_open:entry Open: temp_2
0   18892  fop_remove:entry Remove: temp_2
0   18753    fop_open:entry Open: Workbook
0   18753    fop_open:entry Open: Workbook

    문제가 발생하지 않는 다른 서버에서 동일한 절차를 수행하면 비슷한 결과가 나타납니다.

    CPU ID       FUNCTION:NAME
1   25182 fop_create:return Create: temp_1
1   25750    fop_open:entry Open: temp_1
1   25750    fop_open:entry Open: Workbook
1   25750    fop_open:entry Open: temp_1
1   25750    fop_open:entry Open: Workbook
1   25750    fop_open:entry Open: temp_1
1   25889  fop_rename:entry Rename: Workbook -> temp_2
1   25889  fop_rename:entry Rename: temp_1 -> Workbook
1   25750    fop_open:entry Open: Workbook
1   25750    fop_open:entry Open: temp_2
1   25893  fop_remove:entry Remove: temp_2
1   25750    fop_open:entry Open: Workbook
1   25750    fop_open:entry Open: Workbook
1   25750    fop_open:entry Open: Workbook

    또한 walltimestamp스크립트 에 타임 스탬프 ( )를 추가 했지만 두 경우 모두 모든 파일 작업이 동일한 초에 이루어집니다. => 차이를 만들지 않았다

  • 풀 조각이나 디스크에 결함이있는 경우 다른 호스트에 가져 오기 디스크 확인 = 차이를하지 않았다>
  • 케이블과 메인 보드 등을 배제하기 위해 데이터와 루트 풀을 동일한 머신으로 옮깁니다. => 문제가 지속되므로 루트 풀 (소프트웨어) 또는 소프트웨어와 호환되지 않는 (또는 갑자기 호환되지 않는) 특정 하드웨어 여야합니다. ..)

이 동작의 원인이되는 다른 사항을 제안 해 주시겠습니까? 아니면 비슷한 경험을 했습니까? 온라인에서 유용한 정보를 찾을 수 없기 때문에 하드웨어 문제 (하나의 컴퓨터로 제한되어 있기 때문에) 또는 Windows / Office에 문제가있는 것 같습니다.

답변

해결책:

이 문제는 이전 버전이 아닌 OmniOS r151018에만 영향을줍니다. omnios-discuss 메일 링리스트에있는 이 글 은 내 문제에 관한 것이 었습니다.

Nexenta 포럼과 비슷한 스레드를 보았습니다. opslock에 문제가있는 것 같습니다. 나는 opslock을 비활성화했고 우리는 지금 잘합니다.

svccfg -s network/smb/server setprop smbd/oplock_enable=false

왜 이것이 더 많은 사람들을 물지 않는지 잘 모르겠습니다.

그래서 biteCount++;나는 추측한다. 수정 사항을 적용하고 빠른 재부팅을 수행하여 문제점을 해결했습니다.

미래를위한 교훈 : 문제 해결을 시도하기 전에 공식 메일 링리스트에서 고급 검색을 사용하십시오. 문제는 다른 사람의 컴퓨터에서 이미 발생했을 가능성이 높습니다. 또한 하드웨어 오류를 찾기 전에 빠른 VM을 가동시켜 소프트웨어, 업데이트 또는 구성 오류를 배제하십시오.

내가 도착한 방법 :

업데이트 된 질문에서 볼 수 있듯이 몇 가지 다른 테스트를 마친 후 특정 하드웨어의 소프트웨어 문제 또는 하드웨어 / 드라이버 충돌로 범위를 좁혔습니다. 두 번째를 배제하기 위해 다른 호스트에 두 개의 새로운 OmniOS 가상 머신 r151018 및 r151016을 설치하고 각각의 기본 SMB 공유를 직접 구성했습니다.

r151018에 문제가 발생하여 r151016이 제대로 작동합니다. r151018의 일부 업데이트 만 롤백했지만 이전 릴리스로 돌아 가지 않았기 때문에 첫 번째 테스트에서이를 알지 못했다고 생각합니다. 나는 생각했던 것보다 문제가 더 오래 존재했다고 생각한다.

패키지를 하나씩 만 업데이트하는 방법을 찾을 때 메일 링리스트를보고 smb지난 6 개월 동안 검색 했는데 5 월부터 정확한 해결책 / 같은 문제가 발생했습니다.

답변