Ihre Einschränkung ergibt sich tatsächlich nicht aus dem Dateisystem; oder von Paketversionen glaube ich .
Ihr 2-GB-Limit kommt von Ihnen, wenn Sie eine 32-Bit-Version Ihres Betriebssystems verwenden.
Die Option, die Datei zu vergrößern, wäre die Installation einer 64-Bit-Version wenn die Hardware dies unterstützt .
Siehe Unterstützung für große Dateien
Traditionell verwendeten viele Betriebssysteme und ihre zugrunde liegenden Dateisystemimplementierungen 32-Bit-Ganzzahlen, um Dateigrößen und -positionen darzustellen. Folglich darf keine Datei größer als 2 − 1 Bytes (4 GB − 1) sein. In vielen Implementierungen wurde das Problem dadurch verschärft, dass die Größen als vorzeichenbehaftete Zahlen behandelt wurden, wodurch die Grenze weiter auf 2 − 1 Bytes (2 GB − 1) gesenkt wurde.
Versuchen Sie, den von convert verwendeten Pixel-Cache einzuschränken zu z.B. 1 GiB:
convert 0001.miff ... 2000.miff -limit memory 1GiB -limit map 1GiB -compress jpeg -quality 80 out.pdf
Hoffentlich zwingt dies ImageMagic dazu, regelmäßig bereits verarbeitete Daten auf die Festplatte zu kopieren, anstatt zu versuchen, mehr als 2 GiB in RAM-Puffer zu stecken.
Übrigens, die Menge an virtuellem Speicher, die einem einzelnen Prozess unter 32-Bit-Linux zur Verfügung steht, wird durch VMSPLIT definiert Kernel-Konfigurationseinstellung. Dies kann entweder 2G/2G (2GB für Kernel + 2GB für Userland) oder 1G/3G (1 GB für Kernel + 3 GB für Userland) sein. Auf einem laufenden System finden Sie die Einstellung über
zcat /proc/config.gz | grep VMSPLIT
Auf manchen Systemen ist die Kernel-Konfiguration in /boot/config-$(uname -r) gespeichert stattdessen.