저는 Proxmox를 하이퍼바이저로 실행하고 있으며 6TB 디스크를 ZFS 풀로 설정했습니다. 그런 다음 가상 디스크를 생성하여 Ubuntu Server 20.04를 실행하는 가상 머신에 연결했는데, 여기서 이 디스크는 QEMU 하드 드라이브로 표시되었습니다. 문제가 VM 내에 있고 호스트나 사용된 스토리지 유형과 관련이 없기 때문에 이 모든 정보는 그다지 관련성이 없다고 생각합니다. 물론 제가 틀렸을 수도 있습니다.
그래서 VM 내부에 일단 ext4 파티션을 생성하고 정상적으로 설치했습니다. 가상디스크 확장과 파티션 확대가 용이할 것 같아서 2~3TB정도 할당했습니다. 글쎄, 이것은 한동안 계속되어 왔지만 갑자기 /dev/sdc1 장치를 엉망으로 만들고 해당 파일 시스템이 사라졌을 것입니다. 그래도 드라이브를 마운트할 수 있으며 모든 파일이 거기에 있습니다.
이는 "fdisk -l", "parted" 및 "partprobe"를 실행한 후 얻는 출력입니다. 디스크에 루프 파티션이 있고 장치가 없는 것으로 나타납니다(/dev/sdcX)
➜ ~ fdisk -l
...
Disk /dev/sda: 50 GiB, 53687091200 bytes, 104857600 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 368BBA10-0FA4-4ED3-898D-30F65B772EC7
Device Start End Sectors Size Type
/dev/sda1 2048 4095 2048 1M BIOS boot
/dev/sda2 4096 104857566 104853471 50G Linux filesystem
Disk /dev/sdb: 931.52 GiB, 1000203091968 bytes, 1953521664 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xdbcabab3
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 1953521663 1953519616 931.5G 83 Linux
Disk /dev/sdc: 3.93 TiB, 4294967296000 bytes, 8388608000 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop8: 73.18 MiB, 76734464 bytes, 149872 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
➜ ~ parted /dev/sdc
GNU Parted 3.3
Using /dev/sdc
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: QEMU QEMU HARDDISK (scsi)
Disk /dev/sdc: 4295GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:
Number Start End Size File system Flags
1 0.00B 4295GB 4295GB ext4
➜ ~ partprobe -s /dev/sdc
/dev/sdc: loop partitions 1
보시다시피, 931.51 GiB 디스크 /dev/sdb에는 "디스크 레이블 유형" 및 "디스크 식별자"가 있을 뿐만 아니라 파일 시스템이 "Linux"(ext4)인 /dev/sdb1 레이블이 붙은 파티션도 있습니다. 3.93TiB 디스크 /dev/sdc의 경우에는 그렇지 않습니다. Disk Label Type", "Disk Identifier"가 누락되어 있고 fdisk에 파티션이 표시되지 않습니다. 하지만 Parted에는 "Loop" 유형의 파티션 테이블과 ext4 파티션이 표시됩니다.
이것은 오랫동안 실행되어 왔으며 내가 알아차린 유일한 것은 성능이 좋지 않다는 것입니다. 순차 쓰기의 경우에도 속도는 최대 20MB/초에 도달할 수 있으며, Plex 또는 Torrent를 통해 파일을 제공하는 경우 드라이브는 최소 140MB/초의 속도에 도달할 수 있습니다. 나는 이 성능이 파일 시스템 "부족" 때문이거나 파티션 테이블에서 일어나는 일 때문일 수 있다고 추측합니다.
어쨌든, 모든 파일을 저장할 만큼 큰 여유 하드 드라이브가 없기 때문에 전체 파일을 다시 포맷하지 않고 이 문제를 해결할 수 있는 방법이 있는지 궁금합니다. "수리"란 파일 시스템으로 파티션을 생성하는 것을 의미합니다. 또는 현재 파티션 테이블을 "Loop"에서 GPT 또는 MRB/DOS로 변경한 다음 파티션과 파일 시스템을 만듭니다.
이것이 가능하지 않은 경우 알려주시면 필요한 파일을 백업하고 나머지는 저장할 장소를 찾아보도록 하겠습니다.
답변1
의견에서 다음 출력을 보여주었습니다 file -s /dev/sdc.
/dev/sdc: Linux rev 1.0 ext4 filesystem data, UUID=3cd41499-e6d0-470f-88c1-e828beb07f42 (needs journal recovery) (extents) (64bit) (large files) (huge files)
이는 디스크가 실제로 파티션 테이블 없이 설정되었음을 나타냅니다. 가상 머신의 데이터 디스크의 경우 이는 실제로 장점입니다. 즉, 파티션 테이블을 수정하지 않고도 가상 디스크를 확장한 후 즉시 파일 시스템을 확장할 수 있습니다.
호스트 시스템에 가상 디스크를 확장하라고 지시한 다음, echo 1 > /sys/block/sdc/device/rescan가상화 플랫폼이 가상 머신에 디스크 확장에 대해 자동으로 알리지 않은 경우 가상 머신에서 파일 시스템을 확장하여 (확장된) 가상 디스크를 채울 수 있습니다. resize2fs /dev/sdc.
성능 저하의 원인은 파티션 테이블이 없기 때문이 아닐 수도 있습니다. 실제로 파티션을 생략하면 디스크 액세스가 약간 더 단순해집니다.
가상화 환경이 가상 머신에 어떤 유형의 드라이버를 허용하는지 알아내야 합니다. 환경에서 반가상화( virtio) 드라이버를 사용할 수 있는 경우 이러한 드라이버의 성능은 가상화 호스트가 VM의 물리적 스토리지 컨트롤러를 에뮬레이트하는 특정 모델보다 훨씬 더 나을 수 있습니다.