☰

mkfs.ext4는 19.1TB 논리 볼륨에서 작동하지 않습니다.

tag-icon • tag-icon lvm ext4
mkfs.ext4는 19.1TB 논리 볼륨에서 작동하지 않습니다.

왜 이 논리 볼륨에 파일 시스템을 넣을 수 없는지 이해할 수 없습니다. 이에 대한 솔루션이나 문제 해결 방법이 있는 사람이 있습니까?

root@Home-Pi:~# vgs
  VG                #PV #LV #SN Attr   VSize  VFree
  VG_Remote_Storage   2   1   0 wz--n- 18.19t    0 


root@Home-Pi:~# lvs
  LV                VG                Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  LV_Remote_Storage VG_Remote_Storage -wi-a----- 18.19t                  


root@Home-Pi:~# wipefs -a /dev/mapper/VG_Remote_Storage-LV_Remote_Storage


root@Home-Pi:~# mkfs.ext4 /dev/mapper/VG_Remote_Storage-LV_Remote_Storage 
mke2fs 1.44.5 (15-Dec-2018)
Creating filesystem with 4883200000 4k blocks and 305201152 inodes
Filesystem UUID: bbe76c30-9d69-4528-8c20-711801aca7de
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
        102400000, 214990848, 512000000, 550731776, 644972544, 1934917632, 
        2560000000, 3855122432

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (262144 blocks): mkfs.ext4: Attempt to read block from filesystem resulted in short read 
        while trying to create journal


root@Home-Pi:~# fsck.ext4 -F /dev/VG_Remote_Storage/LV_Remote_Storage
e2fsck 1.44.5 (15-Dec-2018)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/VG_Remote_Storage/LV_Remote_Storage

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

root@Home-Pi:~#

답변1

Raspberry Pi는 32비트 버전의 Linux를 실행하므로 mkfs.ext4는 2^32 블록을 사용하여 파일 시스템을 포맷합니다. 이 블록 크기는 4k로 최대 파일 시스템 크기를 16TiB로 제한합니다. 32비트 Linux의 XFS도 마찬가지입니다.제한된16TiB까지.

재미있게,라즈베리 파이 4 모델 BBroadcom BCM2711이 있습니다.예64비트 ARM v8 쿼드 코어 CPU. 모든 Raspberry Pi 모델의 기본 운영 체제는 32비트이고, IIRC도 Raspbian도 32비트입니다. 어쩌면 32비트와 64비트 버전이 아닌 한 가지 버전만 유지하면 될 수도 있습니다. 64비트 배포예rpi에 사용할 수 있지만 추천할 만큼 잘 알지 못합니다. Google은 당신의 친구입니다. 아니면 한번 사용해 보세요.https://raspberrypi.stackexchange.com/

32비트에서 유일한 실제 옵션은 파티션 크기를 16TiB로 줄이는 것입니다. 나머지는 약 3TiB의 두 번째 파티션으로 사용할 수 있습니다.

내가 제안한 의견에서ZFS- 불행하게도 zfsonlinux에는 64비트 Linux 커널이 필요합니다.32비트에서는 불안정함. 나는 또한 btrfs를 추천하고 싶지만한정32비트에서는 권장되지 않습니다.

나의 마지막 제안은 amd64 CPU가 장착된 PC를 구입하여 이를 사용하여 파일 서버를 구축하는 것입니다.

저렴하게 또는 무료로 구입할 수 있으며, 10년 이상 된 컴퓨터라도 Raspberry Pi보다 더 나은 파일 서버를 만들 수 있습니다. SATA3 포트가 여러 개 있습니다(하나는 부팅 + OS 드라이브용 SSD로 사용하거나 두 개는 사용). mdadm RAID-1 및 2개 이상의 19TiB 스토리지 포트), 최소 4GB RAM(및 확장 공간 - 파일 서버의 메모리가 많을수록 성능이 향상됨), 64비트 Linux를 실행할 수 있으므로 문제 없이 64비트 ext4 또는 XFS를 포맷하거나 ZFS 또는 btrfs를 사용할 수 있습니다.

드라이브는 SATA 포트에 있고 네트워크 인터페이스는 PCI-e에 있습니다. 두 가지 모두 이러한 목적으로 USB보다 더 빠르고 우수하며 더 안정적입니다.

(그런데 SSD의 파티션을 사용하여 하드 드라이브를 캐시할 수 있습니다. ZFS는 다른 파일 시스템의 경우 이를 레이어 2 ARC 또는 L2ARC라고 부릅니다.은닉처커널의 일부입니다)

유일한 단점은 PC가 Raspberry Pi보다 더 많은 공간을 차지하고 더 많은 전력을 소비한다는 것입니다.

관련 정보