今天打算拿iPod把公司服务器上垂涎已久的众多电影拷回来,结果无比郁闷的发现iPod是FAT32的文件系统,现在的蓝光或者小蓝光电影,1080p的,动辄4,5G,十几二十几G也是家常便饭。可恨哪!正好这几天看《Linux System Programming》,就来简要想想操作系统对文件的支持好了。
一个系统对大文件(>2GB)的支持,我觉得因该从三个层次来看:
1. 文件系统对大文件的支持
2. 操作系统对大文件的支持
对于应用程序开发,还有
3. 系统程序库(主要是C语言库)和编译器(C/C++)对大文件的支持。
这里只讨论桌面应用从32-bit到64-bit过渡的一些时间点。对于Linux来说,1993年1月发布的EXT2文件系统对于大于4GB的文件早就支持了[1],而Linux Kernel自身从2.4.0版本开始支持LFS,这已经是到了2001年初了[2]。几乎同时发布的glibc 2.1.3开始支持LFS,到glibc 2.2.X有了对LFS的完整支持,而glibc 2.0不支持大文件,具体可见[3]。同时,GCC等编译工具链也在逐步完善对大文件的支持[4]。
可以看出,到2002年,整个Linux从底层到应用程序开始完整支持大文件。不过我还没具体看到在32-bit机器上如何实现64-bit的文件offset_t之类的属性,有时间一定要去看看在32-bit机器上怎么实现大文件的支持,估计是要编译器多加一些代码的。
这一整个过程恰好也是桌面版本的64-bit机器开始做宣传的时候。什么叫生态链,这就是一个例子。还记得当时我个人从运算的角度来说,认为64-bit的机器纯属噱头,现在想来太主观也太幼稚了。不过那时候这样想也情有可原,Windows还远远没有准备好,Linux又太Geek了,^^。
对于现在的十几个G几十个G的蓝光视频文件,64-bit的机器是必需的。别的行业总在为满足别人的消费需求工作,而消费电子行业的目标是开发消费者的需求。经济的推手,作用是无穷的。
参考:
[1] Wiki Page: EXT2 File Systems
[2] Wiki Page: Linux Kernel Wiki
[3] Large File Support in Linux
[4] large file support in libstdc++-v3