| 1 |
Randy Andy schrieb: |
| 2 |
> |
| 3 |
> Bei 4096-byte großen Sektoren erhöht sich die Grenze sogar auf 16 TiB, trotz Verwendung von MBR, nur kann eben nicht jedes OS damit umgehen, unter Linux ist das aber kein Problem. |
| 4 |
|
| 5 |
So pauschal kann man das auch nicht sagen. Ich baue gerade ein neues |
| 6 |
Gentoo-System mit einem RAID 6 von 17 TB auf (mit - abgesehen von boot, |
| 7 |
swap etc. - einem einzigen Filesystem auf einer einzigen Partition) |
| 8 |
und habe darauf XFS installiert. Darauf konnte ich die Toolchain (gcc, |
| 9 |
glibc, sandbox...) erst mal aufgrund seltsamer Fehlermeldungen nicht |
| 10 |
compilieren. Des Rätsels Lösung war (nach einem halben Tag googeln), |
| 11 |
dass XFS bei großen Platten anscheinend 64bit-Inodes verwendet und |
| 12 |
irgendwelche Felder dafür nur 32bit groß sind. Ich konnte dann |
| 13 |
weiterarbeiten, indem ich Portage auf einer kleineren Ramdisk |
| 14 |
arbeiten ließ, mit "mount -t tmpfs none /var/tmp/portage". |
| 15 |
|
| 16 |
Nach "emerge -e @system" und "emerge -e @world" und einem neu compi- |
| 17 |
lierten Kernel klappt emerge von weiteren Paketen (postfix, apache2 |
| 18 |
etc.) jetzt allerdings auch ohne Umweg über die Ramdisk. Entweder |
| 19 |
hab ich mir also ein System zusammencompiliert, das auch mit 64bit- |
| 20 |
Inodes zurechtkommt, oder das Problem besteht nur bei einzelnen/ |
| 21 |
wenigen speziellen System-Packages (wie eben gcc o.ä.). |
| 22 |
|
| 23 |
Bin ja mal gespannt, ob und welche "Monsterplatten-Überraschungen" |
| 24 |
mir da vielleicht in Zukunft noch begegnen werden... |
| 25 |
|
| 26 |
Gruß Matthias. |
Archives