Loading article…
ラージファイルサポート（LFS ）とは、 32ビットファイルシステム上で2GiBまたは4GiBを超えるファイルを作成できる機能を指す用語です。
従来、多くのオペレーティングシステムとその基盤となるファイルシステムの実装では、ファイルサイズと位置を表すのに32ビット整数が使用されていました。そのため、ファイルサイズは2³² − 1バイト（4 GiB − 1）を超えることはできませんでした。多くの実装では、サイズを符号付き数として扱うことで問題がさらに悪化し、制限は2³¹ − 1バイト（2 GiB − 1）まで低下しました。32ビットオペレーティングシステムでは処理できないほど大きなファイルは、ラージファイルと呼ばれるようになりました。
ハードディスクの容量が小さかった時代には、この制限は十分に許容範囲内だったが、ストレージ容量の全般的な増加に加え、サーバーやデスクトップにおけるファイル使用量の増加、特にデータベースファイルやマルチメディアファイルの増加により、OSベンダーは制限を克服するよう強い圧力を受けるようになった。
1996年、複数のベンダーがこれに対応し、 POSIX上で大きなファイルをサポートするためにLarge File Summitと呼ばれる業界イニシアチブを結成しました（当時、Windows NTはすでにNTFS上で大きなファイルをサポートしていました）。これは明らかに「LFS」の頭文字をとったものです。サミットの任務は、ファイルサイズを表すために64ビットの数値に切り替える標準的な方法を定義することでした。 [ 1 ]
この変更は導入上の問題を引き起こし、設計変更を必要とした。その影響は今もなお見られる。
fseekと は、ftell型 のファイル位置を操作しますが、これは32ビットプラットフォームでは通常32ビット幅であり、後方互換性を犠牲にすることなくこれを大きくすることはできません。（これは、 POSIXで新しい関数とlong intを導入することで解決されました。[ 4 ] Windowsマシンでは、Visual C++の下で関数と が使用されます。）fseekoftello_fseeki64_ftelli6432 ビット プログラムでのラージ ファイル API の使用は、長い間不完全でした。2002 年の分析では、多くのオペレーティングシステムの基本ライブラリが依然としてラージ ファイル サポートなしで出荷されており、それを使用するアプリケーションが制限されていることが明らかになりました。[ 5 ]広く使用されているzlibライブラリが 32 ビット プラットフォームで 64 ビット ラージ ファイルのサポートを開始したのは、2006 年になってからです。[ 6 ]
PC やワークステーションが完全に64 ビット コンピューティングに移行するにつれて、この問題は徐々に解消されました。Microsoft Windows Server 2008 は、32 ビットで出荷された最後のサーバー バージョンです。[ 7 ] Red Hat Enterprise Linux 7は、2014 年に 64 ビット オペレーティングシステムとしてのみ公開されました。[ 8 ] Ubuntu Linux は、2019 年に 32 ビット版の提供を終了しました。[ 9 ] Nvidia は、2018 年に 32 ビット ドライバーの開発を終了し、2019 年 1 月以降はアップデートを提供しなくなりました。 [ 10 ] Apple は、2018 年に 32 ビット Mac OS バージョンの開発を終了し、macOS Mojave を64 ビット オペレーティングシステムとしてのみ提供しました。[ 11 ] Windows 10 のサポート終了日は、デスクトップ版では 2025 年に設定されています。これは、2020 年 1 月に Windows 7 や Windows 8 などの古いシステムから最新のアップグレードが行われたことに関連しており、これらのシステムの一部は i386 アーキテクチャで構築された古いコンピューターで動作していました。[ 12 ]ただし、 Windows 11 は、2021 年の最初のバージョン以来、64 ビット オペレーティングシステムとしてのみ出荷されます。
モバイル分野でも同様の展開が見られます。Google は 2019 年 8 月までにアプリ ストアでアプリケーションの 64 ビット バージョンをサポートすることを義務付けており[ 13 ] 、これにより後々 Androidの 32 ビット サポートを終了できます。[ 14 ] 64 ビットへの移行は 2014 年に始まり、すべての新しいプロセッサが 64 ビット アーキテクチャで設計され、Android 5 (「Lollipop」) がその年に公開され、適切な 64 ビット バージョンのオペレーティングシステムが提供されました。[ 15 ] [ 14 ] Apple は、2013 年までに 64 ビットApple A7 の生産を開始する前年に移行しました。Googleは 2015 年までに Linux の開発環境を 64 ビットのみで提供し始めました。[ 16 ] 2019 年 5 月には、Android バージョン 5 未満の割合が 10 パーセントに減少しました。[ 17 ]アプリ開発者が単一のコンパイルバリアントに集中するにつれて、多くのメーカーが2019年半ばまでにAndroid 5を最小バージョンとして要求し始めました。たとえば、Nianticなどです。[ 18 ]その結果、32ビット版を入手するのが難しくなりました。[ 19 ]
特殊なプログラムを備えた組み込みシステムを除けば、2020年以降、プログラムコードにおいて様々な大容量ファイルへの対応を考慮する必要はなくなる。
2038 年問題は、32 ビット プラットフォームで 32 ビットの「long」が問題を引き起こす別のケースとしてよく知られています。大きなファイルの制限と同様に、システムが 64 ビットのみに移行すると、これは廃止されます。その間、64 ビット タイムスタンプが導入されました。Win32 API では、以前の「32」サフィックスに加えて「64」サフィックスを持つ関数で確認できます。Win32 API に大きなファイル サポートが追加されると、関数に「i64」サフィックスが追加され、場合によっては 4 つの組み合わせ (findfirst32、findfirst64、findfirst32i64、findfirst64i32) になります。[ 20 ]比較すると、UNIX98 API では、「_LARGEFILE64_SOURCE」を使用すると、「64」サフィックスを持つ関数が導入されます。
ラージファイル API に関連して、大容量ストレージメディアのブロック番号に制限があります。データ ブロックあたり 512 バイトの一般的なサイズでは、32 ビットの番号による制限は後になって発生しました。ハードディスク ドライブのサイズが 2 テラバイト (2010 年頃) に達したとき、マスター ブート レコードは、LBA 番号 (論理ブロック アドレス)に 64 ビットを使用するGUID パーティション テーブルに置き換えられる必要がありました。Unixライクなオペレーティングシステムでは、一部の関数 (stat64、setrlimit64) で使用されるinode番号を拡張する必要もありました。Linuxカーネルは2001 年にこれを導入し、バージョン 2.4 がリリースされ、同年 glibc に採用されました。[ 21 ]ラージファイル サポートとラージ ディスク サポートが同時に導入されたため、GNU C ライブラリは、プログラム コードで Unix LFS API がアクティブ化されると同時に、32 ビット アーキテクチャで 64 ビット inode 構造をエクスポートします。[ 22 ]
カーネルが 64 ビット inode に移行したとき、ファイルシステムext3 は2001 年までにドライバ内でそれらを内部的に使用しました。しかし、ストレージ メディア自体の inode フォーマットは 32 ビットの数値に固定されていました。[ 21 ]大容量ストレージ デバイスが4 キロバイト/ブロックのAdvanced Formatに移行すると、そのファイルシステム フォーマットの実際の制限は 8 テラバイトまたは 16 テラバイトになります。 [ 21 ]より大きなディスク パーティションを扱うには、最初から 64 ビット inode で設計され、エクサバイトのファイルとパーティションを可能にするXFSのような別のファイルシステムを使用する必要があります。 [ 23 ] [ 24 ]最初の 16 テラバイトの磁気ディスク ドライブは 2019 年半ばまでに出荷されました。データ センター向けの 32 TiB のソリッドステート ドライブは2016 年には早くも利用可能で、一部のメーカーは 2020 年までに 100 TiB SSD を予測していました。[ 25 ]
-sdk-linux/platform-tools の内容は 23.0.1 では 32 ビット ELF ですが、23.1_rc1 と 23.1.0 では 64 ビット ELF であることが判明しました。[…] ANDROID_EMULATOR_FORCE_32BIT=true に設定しました […] 23.0.1 は最後の 32 ビット Linux ビルドです。
ext4 の機能リストには非常に大きなファイルシステムが含まれていますが、現在の e2fsprogs ではファイルシステムのサイズが 2^32 ブロック (4KiB ブロックのファイルシステムの場合は 16TiB) に制限されています。16T を超えるファイルシステムを許可することは、ext4 で次に完了すべき優先度の高い機能の 1 つです。