George-Cristian Bîrzan wrote:
> On Wednesday 19 July 2006 18:35, Florin Malita wrote:
>
>> Limita 2TB era impusa de catre VFS nu de ext2. i_blocks din struct inode
>> era 'unsigned long' in unitati de 512 bytes (sector size) => pe o
>> platforma 32 biti valoarea maxima reprezentabila era 512*2^32 = 2TB.
>>
>
> Hm, asta m-am gandit si eu, dar pentru XFS nu se aplica:
>
Mda, de aplicat se aplica la toate (VFS e super-set, cod comun) dar nu
le limiteaza asa de drastic cum m-am grabit sa concluzionez...
Tinand cont ca fiecare FS poate avea o reprezentare interna proprie a
inode-utilor, nu le opreste nimeni sa tina nr de blocuri pe 64 biti
intern sau pur si simplu sa foloseasca alta modalitate de gestiune.
Bineinteles, cand aceste reprezentari interne sunt convertite in
structurile standard VFS (struct inode) pot aparea probleme daca VFS nu
are tipul de date potrivit pentru reprezentarea valorilor, afectand
functiile care se bazeaza pe ele. Acest lucru nu va opri insa
functionarea corecta a sistemului de fisiere, doar ca stat, du, etc. vor
raporta balarii (st_blocks aiurea - cineva cu xfs si fisiere mai mari de
2TB pe kernel fara LSF poate sa confirme).
Deci feature-ul introdus in 2.6.17 corecteaza situatia de mai sus: aduce
inode->i_blocks din VFS la un nivel la care poate reprezenta corect
valorile oricarui sistem de fisiere (insa nu rezolva limitarile interne
ale acestora).
Or - asta ar fi raspunsul corect pentru Luci - ext2 (si ext3) au aceeasi
limitare si intern: i_blocks (nr de blocuri de date alocate in unitati
de 512 bytes) e reprezentat pe 32 biti atat in struct ext{2,3}_inode cat
si (mai grav) pe disc:
http://lxr.free-electrons.com/source/include/linux/ext2_fs.h#221
http://ext2read.sourceforge.net/ext2fs.htm
http://www.oreilly.com/catalog/linuxkernel2/chapter/ch17.pdf
De unde limitarea de 2TB amintita mai devreme (512*2^32). Din pacate
aici CONFIG_LSF nu ajuta cu nimic, formatul pe disc e batut in cuie :(
Aparuse un patch care schimba unitatea de alocare (file system
block_size in loc de 512 bytes) la un moment dat dar vad ca nu s-a
lipit, poate in ext4:
http://lwn.net/Articles/176115/
---
fm
_______________________________________________
RLUG mailing list
[email protected]
http://lists.lug.ro/mailman/listinfo/rlug
