동기(Unix)

sync (Unix)

sync는 UNIX 운영 체제의 표준 시스템 호출로 커널 파일 시스템의 모든 데이터를 비휘발성 스토리지 버퍼(즉, 낮은 수준의 I/O 시스템 호출을 통해 쓰도록 예약된 데이터)에 커밋합니다.stdio와 같은 상위 수준의 I/O 계층은 자체 버퍼를 별도로 유지할 수 있습니다.

C의 함수로서sync()콜은 보통 다음과 같이 선언됩니다.void sync(void)에<unistd.h>시스템 콜은 sync라고도 불리는 명령줄 유틸리티 및 Perl이나 Node.js(fs 모듈 내) 등의 다른 언어로 된 유사한 이름의 함수를 통해서도 사용할 수 있습니다.

관련 시스템 호출fsync()는 지정된 파일 [1]기술자와 관련된 버퍼링된 데이터만 커밋합니다. fdatasync()또한 파일 내의 [2]데이터에 대한 변경사항만 쓸 수 있으며 파일의 관련 메타데이터는 쓸 수 없습니다.

일부 Unix 시스템은 정기적으로 동기 함수를 호출하는 일종의 플러시 또는 업데이트 데몬을 실행합니다.일부 시스템에서는 cron 데몬이 이를 수행하고 Linux에서는 pdflush 데몬에 의해 처리되며 새로운 구현으로 대체되어 [3]2012년에 Linux 커널에서 최종적으로 삭제되었습니다.파일 시스템이 마운트 해제되거나 읽기 [4]전용으로 재마운트된 경우에도 버퍼가 플러시됩니다(예: 시스템 종료 전).

데이터베이스 사용

적절한 내구성을 실현하기 위해 데이터베이스는 기록된 정보가 단순히 메모리 기반 쓰기 캐시에 저장되는 것이 아니라 비휘발성 스토리지에 저장되었는지 확인하기 위해 어떤 형태의 동기화를 사용해야 합니다.포스트그레예를 들어 SQL에서는 다음과 같은 다양한 동기 호출을 사용할 수 있습니다.fsync()그리고.fdatasync()커밋의 [6]내구성을 유지하기 위해서입니다.[5]불행히도 일련의 레코드를 쓰는 단일 클라이언트의 경우 회전하는 하드 드라이브는 회전당 한 번만 커밋할 수 있으며, 이는 [7]초당 수백 개의 커밋을 가능하게 합니다.따라서 fsync 요건을 끄면 커밋 퍼포먼스가 대폭 향상되지만 크래시 후 데이터베이스 파손이 발생할 가능성이 있습니다.

데이터베이스는 또한 최근의 변경에 대한 정보가 포함된 트랜잭션 로그 파일(일반적으로 메인 데이터 파일보다 훨씬 작음)을 사용하여 충돌 시 변경 내용을 안정적으로 다시 작성할 수 있습니다. 그러면 메인 데이터 파일의 동기화 빈도가 줄어듭니다.

오류 보고 및 확인

데이터 손실을 방지하려면fsync()라이브러리 또는 커널에 의해 버퍼링된 I/O 작업을 수행할 때 에러가 보고되지 않을 수 있으므로 확인해야 합니다.write()시스템 콜 또는fflush()비휘발성 스토리지에는 쓸 수 없고 메모리 페이지 캐시에만 쓸 수 있기 때문에 콜을 실행합니다.대신 쓰기 오류는 시스템 호출 중에 보고되는 경우가 많습니다.fsync(),msync()또는close().[8] 2018년 이전 Linux의fsync()특정 상황에서 [9][10]오류 상태를 보고하지 못한 경우 변경 동작이 [11]2018년 4월 23일에 제안되었습니다.

퍼포먼스에 관한 문제

하드 디스크는 기본적으로 쓰기 버퍼에 휘발성 쓰기 캐시를 사용하기 때문에 성능이 크게 향상되고 [12]쓰기 손실이 발생할 수 있습니다.hdparm -F와 같은 도구는 HDD 컨트롤러에 온드라이브 쓰기 캐시 버퍼를 플러시하도록 지시합니다.캐시를 끄면 성능에 미치는 영향이 너무 커서 일반적으로 보수적인 FreeB도 마찬가지입니다.SD 커뮤니티는 FreeBSD 4.[13]3에서 쓰기 캐시를 디폴트로 무효로 하는 것을 거부했습니다.

SCSI 및 네이티브 Command Queuing을 사용하는 SATA(일반 ATA에서는 TCQ를 사용하는 경우에도 아님)에서 호스트는 데이터가 디스크의 플래터에 도달했을 때 완료 알림을 받을지 또는 디스크의 버퍼에 도달했을 때(온보드 캐시)를 지정할 수 있습니다.하드웨어가 올바르게 실장되어 있는 경우, 이 기능을 통해 디스크 온보드 캐시를 사용할 수 있습니다.또, 다음과 같은 시스템 콜의 정확한 의미도 보증됩니다.fsync이 하드웨어 기능은 Force Unit Access(FUA; 강제 유닛 액세스)라고 불리며 ATA([15]또는 SATA 비NCQ) 디스크에서처럼 캐시 전체를 플러시하는 것보다 적은 오버헤드로 일관성을 유지할 수 있습니다.[14]Linux는 2007년경 NCQ를 지원했지만 초기 드라이브의 [16][17]지원 부족을 이유로 2012년까지 SATA/NCQ FUA를 지원하지 않았습니다.

2008년에 출시된 Firefox 3.0은fsync 퍼포먼스를 저하시키는 것으로 판명된 시스템콜.콜은 임베디드 SQLite 데이터베이스의 [18]무결성을 보증하기 위해 도입되었습니다.Linux Foundation 최고기술책임자Theodore Tso는 fsync를 두려워할 필요가 없으며 Firefox 3의 속도 저하의 진짜 원인은 과도한 사용이라고 주장한다.fsync그는 또한 (마이크 셰이버의 말을 인용) 인정한다.[19]

특히 "data=ordered" 모드에서 ext3 파일 시스템을 사용하는 일부 Linux 구성에서는 fsync를 호출하면 호출된 파일의 데이터뿐만 아니라 해당 파일 [20]시스템의 버퍼링된 모든 데이터에서도 fsync를 호출할 수 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ fsync 사양
  2. ^ fdatasync 사양
  3. ^ "R.I.P. Pdflush [LWN.net]".
  4. ^ "mount - Does umount calls sync to complete any pending writes". Unix & Linux Stack Exchange. Retrieved 2021-05-02.
  5. ^ Vondra, Tomas (2 February 2019). "PostgreSQL vs. fsync". Osuosl Org. Archived from the original (mp4) on 10 February 2019. Retrieved 10 February 2019.
  6. ^ PostgreSQL의 신뢰성과 미리 쓰기 로그
  7. ^ 포스트그리의 조정SQL WAL 동기화가 Wayback Machine에서 2009-11-25년에 아카이브됨
  8. ^ "Ensuring data reaches disk [LWN.net]".
  9. ^ "PostgreSQL's fsync() surprise [LWN.net]".
  10. ^ "Improved block-layer error handling [LWN.net]".
  11. ^ "Archived copy". Archived from the original on 2018-05-04. Retrieved 2018-05-03.{{cite web}}: CS1 maint: 제목으로 아카이브된 복사(링크)
  12. ^ 쓰기 캐시가 유효합니까?
  13. ^ FreeBSD 핸드북 - 디스크 튜닝
  14. ^ Marshall Kirk McKusick. "Disks from the Perspective of a File System - ACM Queue". Queue.acm.org. Retrieved 2014-01-11.
  15. ^ Gregory Smith (2010). PostgreSQL 9.0: High Performance. Packt Publishing Ltd. p. 78. ISBN 978-1-84951-031-8.
  16. ^ "Enabling FUA for SATA drives (Was Re: [RFC][PATCH] libata: Enable SATA disk fua detection on default) (Linux SCSI)".
  17. ^ "Linux-Kernel Archive: [PATCH RFC] libata: FUA updates".
  18. ^ "Shaver » fsyncers and curveballs".
  19. ^ "Don't fear the fsync!".
  20. ^ "Delayed allocation and the zero-length file problem".

외부 링크