정기적으로 삭제하는 작은 파일이 많이 포함된 파일 시스템이 있습니다. 이러한 파일은 쉽게 다시 생성할 수 있는 캐시입니다. 단순히 새 파일 시스템을 생성하는 것이 모든 파일을 실행 rm -rf하거나 삭제하는 것보다 훨씬 빠릅니다 (예:rsync수천 개의 파일이 포함된 대규모 디렉터리를 효율적으로 삭제합니다.).
새 파일 시스템을 생성하여 파일 시스템을 지울 때의 유일한 문제는 UUID가 변경되어 다음 /etc/fstab과 같은 문제가 발생한다는 것입니다.
ext4 파일 시스템에서 디렉토리를 단순히 "링크 해제"하거나 해당 inode 목록을 완전히 지울 수 있는 방법이 있습니까?
답변1
를 사용하고 있으므로 ext4파일 시스템을 포맷한 다음 UUID를 알려진 값으로 설정할 수 있습니다.
man tune2fs썼다,
-U UUID파일 시스템의 UUID(Universally Unique Identifier)를 UUID로 설정합니다. UUID의 형식은 아래와 같이 하이픈으로 구분된 일련의 16진수 숫자입니다c1b9d5a2-f162-11cf-9ece-0020afc76f16.
마찬가지로 다음과 같이 man mkfs.ext4쓴다.
-U UUID파일 시스템의 UUID(Universally Unique Identifier)를 UUID로 설정합니다.[…위와 같이…]
개인적으로 나는 레이블을 통해 파일 시스템을 참조하는 것을 선호합니다. 예를 들어 /etc/fstab내 시스템 중 하나에 다음과 같은 항목이 있습니다.
# <file system> <mount point> <type> <options> <dump> <pass>
LABEL=root / ext4 errors=remount-ro 0 1
LABEL=backup /backup ext4 defaults 0 2
이러한 태그는 및 -L플래그를 사용하여 추가할 수 있습니다. 그들은 문제를 피한다tune2efsmkfs.ext4아이노드 체크섬다시 포맷된 파일 시스템이 재발견되거나 손상될 수 있으며 시각적으로 더 쉽게 식별할 수 있습니다. (그러나 여러 시스템에서 고유할 가능성은 없으므로 디스크를 교체할 때는 주의하세요.)
답변2
-Uwith를 사용하여 고유한 UUID를 지정할 수 mkfs.ext4있으므로 파일 시스템을 다시 만들 때 이전 UUID를 간단히 재사용할 수 있습니다.
답변3
ext3/ext4의 새 파일 시스템에 UUID를 재사용하는 것은 좋지 않습니다.
UUID는 fsck가 현재 파일 시스템에 속한 inode와 이전 파일 시스템의 inode를 구별할 수 있도록 inode 체크섬 계산에 사용됩니다.
동일한 UUID를 사용하여 기존 확장 파일 시스템을 다시 포맷하는 경우 파일 시스템 검사에서 이전 데이터를 찾아서 복구하려고 시도할 가능성이 높습니다. 일반적으로 이는 대화형 프로세스이므로 시작 시 비대화형 자동 파일 시스템 검사가 실패하고 복구 쉘에 들어가게 됩니다.
파티션 테이블이 GPT인 경우 fstab에서 파티션 UUID를 사용할 수 있고, LVM을 사용하는 경우 이를 통해 영구 이름을 얻을 수도 있습니다.
답변4
방금 파일 시스템을 넣었습니다.LVM 씬 풀, 생성 후 컴팩트 스냅샷을 만듭니다. 그런 다음 파일 시스템을 다시 생성하는 대신 해당 스냅샷으로 롤백합니다. 이는 스토리지 측면에서 오버헤드가 거의 없습니다.
생성 직후 파일 시스템의 이미지를 찍어 나중에 dd복원하기 위해 저장할 수도 있습니다. 이는 기본 스토리지가 SSD인 경우 특히 매력적입니다. 삭제를 사용하여 블록을 0/사용되지 않음으로 표시하므로 이미지는 생성 속도가 빠르고, 이미지 파일이 대부분 드물기 때문에 효과적인 저장 요구 사항 측면에서 중요하지 않으며, 복원도 놀라울 정도로 빠릅니다.
파일 크기에 따라 실제로 상당한 영향이 있습니다.파일 시스템 간의 속도 차이(페이지 하단의 벤치마크를 참조하세요). 중간 크기 파일의 경우 XFS가능한더 빠르게!
mkfs하지만 주문형 사용에 익숙하다면 더 간단한 해결책이 있습니다. mkfs.ext4 -U ${your_uuid_here}파일 시스템의 UUID를 설정해 보세요. :)