EXT4 파일 시스템이 relatime과lazytime을 동시에 마운트하는 이유는 무엇입니까?

EXT4 파일 시스템이 relatime과lazytime을 동시에 마운트하는 이유는 무엇입니까?

저는 Debian/Testing, 커널 4.4를 실행하고 있습니다:

# uname -a
Linux shaula 4.4.0-1-amd64 #1 SMP Debian 4.4.6-1 (2016-03-17) x86_64 GNU/Linux

그래서 마운트 옵션을 사용하고 싶었 lazytime기 때문에 다음을 내 옵션에 넣었습니다 /etc/fstab.

# grep vg_crypt-root /etc/fstab 
/dev/mapper/vg_crypt-root   /   ext4   lazytime,errors=remount-ro   0   1

그러나 이제 파일 시스템은 다음을 사용하는 것 같습니다.둘 다 relatime그리고 lazytime:

# grep vg_crypt-root /etc/mtab 
/dev/mapper/vg_crypt-root / ext4 rw,lazytime,relatime,errors=remount-ro,data=ordered 0 0

어떻게 그래?

답변1

좋은 소식: 이는 예상된 일입니다.

Lazytime 플래그는 strictatime/relatime/noatime과 독립적입니다. 기본값은 상대 시간입니다. 따라서 noatime을lazytime으로 바꿀 때 relatime 마운트 옵션이 설정되는 것은 놀라운 일이 아닙니다.

--테드 조

불행히도 이것은 그것이 무엇을 의미하는지 설명하지 않습니다.

맨페이지를 그대로 읽어보면 상대성 억제가 있음을 알 수 있습니다.둘 다메모리 업데이트 및 디스크 쓰기. Lazytime은 디스크 쓰기만 억제합니다(그리고 mtime 및 atime과 함께 작동합니다). 지연 시간 구현으로 이어진 논의를 고려할 때 이는 나에게 의미가 있습니다. IOW, 관계 테스트 작성은 매우 쉬울 것입니다. 하지만 게으른 시간의 효과는 다음과 같습니다.오직디스크 쓰기를 보거나 비정상 종료로 인해 어떤 일이 발생하는지 테스트하면 이를 확인할 수 있습니다.


개인적으로, mtime에 대한 지연 시간의 효과는 약간 이상하게 들립니다. 아마도 이것은 가동 시간이 높은 시스템에 대한 좋은 최적화일 수도 있지만 일반 데스크탑에서는 어떤지 모르겠습니다...그리고 이제 이것은 실제로 랩탑이므로 전원 공급 장치에 대해 걱정할 필요가 없습니다. 또는 너무 열정적으로 결함이 있을 때 부분적으로 정의된 이상한 행동. btrfs와 같은 쓰기 중 복사 파일 시스템을 고려하면 파일 크기가 커져도 "inode"가 업데이트될 수 있다는 점을 고려하면 상황은 더욱 특별해집니다.아니요변화. 비교하면 relatime사랑스럽고 확실합니다 .

그리고 mtime 최적화는 파일을 많이 쓰고 파일 크기가 변하지 않는 경우에만 유용한 것 같습니다. 공통 벤치마크가 있는지 잘 모르겠습니다. 나는 이것이 매우 중요한 데이터베이스 작업 부하라고 생각합니다.

정말이지, 테드, 우리는 왜 그걸 못 알아냈지 lazyatime?

관련 정보