- 积分
- 1721
- 最后登录
- 2024-3-9
- 精华
- 0
- 阅读权限
- 50
- 主题
- 40
- UID
- 262174
- 帖子
- 3147
- PB币
- 260
- 威望
- 77
- 贡献
- 0
- 技术
- 197
- 活跃
- 1896
- UID
- 262174
- 帖子
- 3147
- PB币
- 260
- 贡献
- 0
- 技术
- 197
- 活跃
- 1896
|
发表于 2016-6-19 19:18:13
IP属地重庆
|显示全部楼层
本帖最后由 bizongyi 于 2016-6-19 19:20 编辑
口袋妖怪heart 发表于 2016-6-19 17:27
嗯 之前有试过 存储文件的话倒还ok 貌似有说2017年正式release
i.e. 10.12正式版了它也不会正式版。。
希望这次苹果能得到一个优秀的文件系统吧,苹果的文件系统一直都很落后。
HFS+,还是苹果的粉组和蓝组开发Mac OS 8时代的产物。原本Mac OS 8时,苹果准备开发一套全新的系统,结果开发失败被彻底放弃,不过HPS+被保留了下来。后来又修修补补加入了很多功能,比如core serivce、FileVault,但HFS+比起其它文件系统还是相当落后。
苹果也数次想换掉HFS+,比如10.3、10.4支持UFS(UNIX文件系统),10.6时支持solaris的ZFS,最终都失败了。希望这次苹果能成功~
延伸阅读:
HFS+有大多的历史包袱,为考虑兼容性,这些陈旧的设计并不能被推翻重来。
HFS+基于B-树实现,当查找B-树中未使用的节点时,HFS+只能每次处理16位,原因是老Mac使用的Motorola的68K芯片原生支持16位的数据操作。但不管是PowerPC还是Intel,寄存器都支持256位宽的寄存器。
HFS+的元数据(metadata)都以大字节序保存,原因是Motorola的68k和后来Mac使用的PowerPC都使用大字节序。但经过Intel迁移后,当今的Mac都使用Intel芯片,而Intel芯片是使用小字节序的。因此每当数据读取或存入时,还要经过小字节序和大字节序的转换。远古时期磁盘很慢,计算机处理器的速度也很低,因此进行一次磁盘操作会占用较多的时间,HFS+的时间分辨率为一秒,但当今的磁盘、处理器处理一次文件系统操作的时间远小于一秒,因此所有主流磁盘文件系统的时间分辨率都是一至数百纳秒级别的。
HFS+的元数据有全局锁,同一时间只有一个进程可以访问更新文件系统。在单核处理器连手机平板都较少见到的当今,这种设计显得很幼稚。
HFS+亦没有稀疏文件的支持。例如我们在SQL中建立了一个数据库,SQL分配了10GB的文件给这个数据库,并且在文件头和文件尾写上一些字节的数据。而由于我们还没有给这个数据库添加新的数据,所以这10GB的文件除了头尾外其他字节都为0。现代的文件系统基本都支持稀疏文件,也就是说,当处理这个数据库操作时,事实上往磁盘写入的数据只有那文件头和文件尾的若干字节。而HFS+则需要把那些0也写上,因此会完整写入10GB的数据,耗费长得多的时间。
此外,HFS+不具备元数据校验功能、快照功能、写入时复制功能、就地执行功能、逻辑卷管理功能等很多现代磁盘系统所具备的功能,也不能动态调整文件块大小。这些功能的加入并不容易。
其中最要命的是,HFS+不像一些先进的文件系统,支持写入时复制事务模型,也没有快照和克隆。这使得用户数据时时处于风险之中。例如由于因为断电、内核崩溃等原因,文件系统上写到一半的数据,小则导致个别文件损坏,大则导致整个文件系统崩溃。在生产领域,这样不可靠的文件系统,很有可能带来致命的灾难。
正是由于上述这些原因,连我们介绍过的短视的Linus Torvalds都认为HFS+是个垃圾文件系统。苹果自然受不了这种侮辱,因此,干掉HFS+势在必行。 |
|