7.7. 파일 시스템 및 스토리지
백업을 복원하는 동안 xfsrestore 명령이 올바르게 작동합니다.
이전 버전에서는 xfsdump 명령을 사용하여 생성된 백업을 복원하는 동안 xfsrestore 에서 고립 디렉토리를 생성했습니다. 그 결과 다음과 같은 메시지가 있는 생성된 고립 디렉터리로 몇 개의 파일이 이동되었습니다.
# xfsdump -L test -M test -f /scratch.dmp /mnt/test ... xfsdump: NOTE: root ino 128 differs from mount dir ino 1024, bind mount? ... xfsdump: Dump Status: SUCCESS # xfsrestore -f /scratch.dmp /mnt/restore/ ... xfsrestore: restoring non-directory files xfsrestore: NOTE: ino 128 salvaging file, placing in orphanage/1024.0/dir17/file60 xfsrestore: NOTE: ino 129 salvaging file, placing in orphanage/1024.0/dir17/file61 xfsrestore: NOTE: ino 130 salvaging file, placing in orphanage/1024.0/dir17/file62 xfsrestore: NOTE: ino 131 salvaging file, placing in orphanage/1024.0/dir17/file63 xfsrestore: NOTE: ino 132 salvaging file, placing in orphanage/1024.0/dir17/file64 xfsrestore: NOTE: ino 133 salvaging file, placing in orphanage/1024.0/dir17/file65 xfsrestore: NOTE: ino 134 salvaging file, placing in orphanage/1024.0/dir17/file66 ...
이번 업데이트를 통해 문제가 수정되었으며 xfsrestore 가 올바르게 작동합니다.
(BZ#2020494)
multipathd.socket 유닛 파일은 너무 많은 시작 시도 후 multipathd 를 비활성화하지 않습니다.
이전 버전에서는 multipath.service 유닛 파일의 다중 경로 시작 조건이 의 트리거 조건과 달랐습니다. 결과적으로 단위 파일은 multipathd.socket다중 경로 파일을 반복적으로 시작하려고 시도하여 실패했습니다. 이로 인해 너무 많은 시도에 실패한 후 multipathd 가 비활성화됩니다. 이번 수정으로 multipathd.socket 및 multipathd.service 의 시작 조건이 동일한 값으로 설정되었습니다. 결과적으로 multipathd.socket 유닛 파일은 더 이상 의 시작 조건이 충족되지 않는 multipathd를 시작하지 않습니다.
multipathd.service
보호 uevents가 더 이상 다중 경로 장치의 다시 로드 실패를 유발하지 않음
이전에는 읽기 전용 경로 장치를 다시 스캔할 때 커널은 두 개의 쓰기 보호 uevents를 전송했습니다. 하나는 읽기/쓰기 로 설정된 장치와 함께 다음과 같이 읽기 전용으로 설정된 장치입니다. 결과적으로 경로 장치에서 읽기/쓰기 uevent를 탐지하면 multipathd 가 다중 경로 장치를 다시 로드하려고 시도하여 다시 로드 오류 메시지가 발생했습니다. 이번 업데이트를 통해 이제 장치 읽기/쓰기를 다시 로드하기 전에 multipathd 가 모든 경로가 읽기/쓰기 로 설정되어 있는지 확인합니다. 결과적으로 multipathd 는 읽기 전용 장치를 다시 검사할 때마다 읽기/쓰기 를 다시 로드하지 않습니다.
(BZ#2009624)
