cryptsetup과 ext4는 얼마나 많은 스토리지 오버헤드를 가져오나요?

cryptsetup과 ext4는 얼마나 많은 스토리지 오버헤드를 가져오나요?

ext4 파일 시스템이 있는 컨테이너의 디렉터리 내용을 암호화하기 위해 cryptsetup을 사용하고 싶습니다. 컨테이너의 크기는 가능한 한 작고, 한 번만 쓰고 백업할 것이므로 필요한 만큼 커야 합니다.

첫 번째 시도: 컨테이너 크기를 콘텐츠 크기에 맞게 설정합니다.

dirsize=$(du -s -B512 "$dir" | cut -f 1)
dd if=/dev/zero of=$container count=$dirsize
losetup /dev/loop0 $container
fdisk /dev/loop0 # 1 Partition with max possible size
cryptsetup luksFormat --key-file $keyFile /dev/loop0
cryptsetup luksOpen --key-file $keyFile /dev/loop0 container
mkfs.ext4 -j /dev/mapper/container
mkdir /mnt/container
mount /dev/mapper/container /mnt/container
rsync -r "$dir" /mnt/container

Rsync가 데이터를 보관할 만큼 충분한 공간을 반환하지 않습니다. 암호화 및 파일 시스템에 약간의 오버헤드가 있어야 하므로 합리적으로 보입니다.

상대 오프셋을 사용해 보았습니다.

dirsize=$(($dirsize + ($dirsize + 8)/9))

이렇게 하면 100MB보다 큰 디렉터리의 문제가 해결되지만 50MB보다 작은 디렉터리의 문제는 해결되지 않습니다.

컨테이너가 디렉터리보다 커야 하는 해당 바이트 수를 결정하는 방법은 무엇입니까?

답변1

LUKS는 기본적으로 데이터 정렬을 위해 헤더에 2MiB를 사용합니다. cryptsetup luksDump( Payload offset:섹터에서) 을 사용하여 확인할 수 있습니다 . 정렬에 관심이 없다면 이 --align-payload=1옵션을 사용할 수 있습니다.

그것에 관해서는 ext4복잡합니다. 오버헤드는 파일 시스템 크기, inode 크기, 로그 크기 등에 따라 달라집니다. 저널이 필요하지 않다면 선호할 수도 있습니다 ext2. 다른 파일 시스템은 오버헤드가 적 ext*으므로 시도해 볼 가치가 있습니다. 또한, 해당 항목에 추가하려는 파일 유형에 따라 일부 mkfs플래그(유사 하거나 유사한)가 도움이 될 수 있습니다. -T largefile예를 들어, 12개의 파일만 저장하려는 경우 백만 개의 inode가 있는 파일 시스템을 만들 필요가 없습니다.

컨테이너를 가장 작은 크기로 만들려면 더 큰 컨테이너로 시작한 다음 resize2fs -M가장 작은 크기로 줄이세요. 그런 다음 truncate해당 크기와 LUKS의 컨테이너를 사용할 수 있습니다 .Payload offset:

이는 거의 작을 것입니다. 더 작은 크기가 필요한 경우 tar.xz대신 파일 시스템을 사용하는 것이 좋습니다. 수백 GB의 데이터(단일 파일에 액세스하려면 모든 것을 추출해야 함)에는 좋지 않지만 tar언급한 크기에는 적합하고 대부분의 파일 시스템보다 작아야 합니다.

답변2

"LUKS에는 LUKS 헤더를 저장하기 위한 1032개 섹터(1 섹터는 512바이트) 오버헤드가 있습니다. 헤더 이후 암호화된 데이터는 복호화된 데이터만큼만 선형적으로 공간을 차지합니다."

바라보다:http://glandium.org/blog/?p=139

답변3

파일 시스템에는 파일 자체 이상의 내용이 포함되어 있으므로 파일 시스템의 정확한 크기를 예측하기가 어렵습니다. 바라보다디스크 사용량을 측정하는 방법이 왜 그렇게 다양합니까?디스크 사용량과 관련하여 몇 가지 미묘함이 있습니다. 특히:

  • 모든 파일은 불완전한 청크로 끝납니다. 실행 시 du이를 고려하지만 해당 -B인수를 생략해야 하며, 실행 중인 파일 시스템이 파일을 복사하려는 파일 시스템과 동일한 블록 크기를 갖는 경우에만 적용됩니다.
  • 파일 시스템에는 inode 및 기타 데이터 구조(수퍼블록, 로그...)도 포함되어야 합니다.

파일 수와 생성된 inode 수를 추적하고, 블록 크기와 inode 크기를 추가하면 파일 시스템의 크기를 대략적으로 파악할 수 있습니다. 하지만 매우 엄격하게 적용하려면 시행착오가 필요합니다.

가장 작은 ext2 이미지 크기를 찾는 가장 쉬운 방법은 충분히 큰 ext4 이미지를 만든 다음 resize2fs축소하는 것입니다.

Linux에서 다시 읽을 수 있는 읽기 전용 파일 시스템을 만드는 경우호박 파일 시스템ext4보다 더 나은 선택이 될 것입니다.

Dm-crypt 자체에도 오버헤드가 있습니다. 이것은자주하는 질문. 기본적으로 cryptsetup2MB는 메타데이터용으로 볼륨 시작 부분에 예약되어 있습니다(FAQ 2.18). 오버헤드는 볼륨 크기와 관계가 없습니다. FAQ 6.12 및 6.13에서는 오버헤드를 줄이는 방법을 설명합니다. 128비트 키 크기(보안 목적으로 그 정도만 필요)를 선택하려면 고정 크기 헤더(544B) 외에 512kB 키 슬롯이 필요합니다. 가능한 가장 작은 정렬을 선택하거나 이에 가까운 것을 선택하십시오. 블록 크기가 4kB인 파일 시스템의 경우 4kB보다 작은 정렬을 사용하면 성능 저하가 줄어들 것이며 4kB는 무시할 수 있습니다. , 따라서 총 오버헤드를 얻기 위해 4kB 정렬을 사용하는 것이 좋습니다.516kB. 볼륨 생성 시 옵션은 다음과 같습니다.

cryptsetup luksFormat -s 128 --align-payload=8 --key-file $keyFile /dev/loop0

관련 정보