☰

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ビット版ではなく、1つのバージョンを維持するだけです。 64ビット展開はいrpiに使用できますが、推奨するほどよくわかりません。 Googleはあなたの友達です。または一度試してみてください。https://raspberrypi.stackexchange.com/

32ビットで唯一の実際のオプションは、パーティションのサイズを16TiBに減らすことです。残りは約3TiBの2番目のパーティションとして使用できます。

私が提案したコメントからZFS- 残念ながら、zfsonlinuxには64ビットLinuxカーネルが必要です。32ビットでは不安定。私もbtrfsをお勧めしますが、限定32ビットでは推奨されません。

私の最後の提案は、amd64 CPUを搭載したPCを購入し、それを使用してファイルサーバーを構築することです。

手頃な価格または無料で購入でき、10年以上のコンピュータでもRaspberry Piよりも優れたファイルサーバーを作成できます。 SATA3ポートは複数あります（1つはブート+ OSドライブ用のSSDとして使用するか、2つは使用）。 mdadm RAID-1と2つ以上の19TiBストレージポート）、少なくとも4 GBのRAM（および拡張スペース - ファイルサーバーのメモリが多いほどパフォーマンスが向上します）、64ビットLinuxを実行できるため、問題なく64ビットext4またはXFSをフォーマットまたはZFSあるいは、btrfsを使用することもできます。

ドライブはSATAポートにあり、ネットワークインターフェイスはPCI-eにあります。どちらもこの目的のためにUSBより速く、優れており、より安定しています。

（しかし、SSDのパーティションを使用してハードドライブをキャッシュできます。ZFSは、他のファイルシステムの場合はレイヤ2 ARCまたはL2ARCと呼びます。隠れ家カーネルの一部です）

唯一の欠点は、PCがRaspberry Piよりも多くのスペースを占有し、より多くの電力を消費することです。

おすすめ記事