Lvm

mkfs.ext4 不適用於 19.1TB 邏輯卷

  • August 19, 2019

我不知道為什麼它不允許我在這個邏輯卷上放置一個文件系統,有沒有人對此有解決方案或故障排除?

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:~#

您的樹莓派正在執行 32 位版本的 linux,因此 mkfs.ext4 正在使用 2^32 塊格式化文件系統,這(塊大小為 4k)將文件系統的最大大小限制為 16 TiB。32 位 Linux 上的 XFS 也限制為 16 TiB。

有趣的是,Raspberry Pi 4 Model B有一個 Broadcom BCM2711,它一個 64 位 ARM v8 四核 CPU。所有型號的樹莓派的預設作業系統都是 32 位的,IIRC 甚至 raspbian 都是 32 位的。可能他們只需要維護一個版本,而不是 32 位和 64 位版本。64 位發行版用於 rpi - 但我對它們的了解不足以推荐一個。Google是你的朋友,或者試試https://raspberrypi.stackexchange.com/

在 32 位上,您唯一真正的選擇是將分區大小減小到 16 TiB。剩餘部分可用作約 3 TiB 的第二分區。

在評論中,我建議使用ZFS - 不幸的是,zfsonlinux 需要 64 位 linux 核心,因為它在 32 位上不穩定。我也建議使用 btrfs,但它對32 位也有限制,不推薦使用。


我最後的建議是購買一台帶有 amd64 CPU 的 PC,並用它來建構您的文件伺服器。

這些可以很便宜,甚至是免費的,即使是 10 年以上的機器也能製造出比樹莓派更好的文件伺服器——它將有多個 SATA3 埠(使用一個用於引導 + 作業系統驅動器的 SSD,或兩個在 mdadm RAID-1 中;以及 2 個或更多埠用於 19TiB 儲存),至少 4GB RAM(和擴展空間 - 文件伺服器擁有的記憶體越多,性能越好),它可以執行 64- bit Linux 因此可以格式化 64bit ext4 或 XFS,或者使用 ZFS 或 btrfs 沒有問題。

您的驅動器將在 SATA 埠上,而您的網路介面將在 PCI-e 上 - 這兩者都比 USB 更快、更優越(並且更可靠)。

(順便說一句,您可以使用 SSD 上的分區來記憶體硬碟。ZFS 將此稱為第 2 層 ARC 或 L2ARC,而對於其他文件系統,bcache是核心的一部分)

唯一的缺點是 PC 會佔用更多空間,並且比樹莓派更耗電。

引用自:https://unix.stackexchange.com/questions/536097