无忧启动论坛

 找回密码
 注册
搜索

关于神奇的wimboot技术为什么不会降低性能的一个大神的阐述

查看数: 7345 | 评论数: 20 | 收藏 10
关灯 | 提示:支持键盘翻页<-左 右->
    组图打开中,请稍候......
发布时间: 2020-3-12 21:16

正文摘要:

本帖最后由 sairen139 于 2022-11-17 08:08 编辑 关于神奇的wimboot技术为什么不会降低性能的一个大神的阐述 WIMBOOT是Windows8.1 Update新引进的特性。它让你的系统盘的大部分系统文件都指向一个经过特别处理 ...

回复

12250279 发表于 2020-12-13 00:46:31
求大神来一个,一键WIMBOOT 一键释放指针的 BAT程序
xman00 发表于 2020-12-11 18:06:36
本帖最后由 xman00 于 2020-12-11 18:08 编辑
CodeHz 发表于 2020-12-11 18:04
1. 正常的文件系统都会对文件进行切割和重新排列以提升空间利用效率,所以文件只要超过一定大小就几乎一 ...

那请教楼上你对wimboot对系统性能的影响是如何的看法呢?越细腻越好
CodeHz 发表于 2020-12-11 18:04:30
xman00 发表于 2020-12-11 17:43
请问:
”所以文件的块可以直接顺序排列(这点上甚至优于传统文件系统,但是由于wim文件本身也在别的文 ...

1. 正常的文件系统都会对文件进行切割和重新排列以提升空间利用效率,所以文件只要超过一定大小就几乎一定会被重组(太小的甚至可以直接压到元数据里,不会被切割)
2. 压缩文件内部可以把文件按顺序直接排列,但是作为文件,它本身仍然表现为普通文件,会被文件系统所分块
3. 但是也不是完全没有好处,毕竟如果是多个独立的不同文件,(你看vmware的虚拟磁盘就有这个选项),则更有可能产生更多的分块。
4. 文件分块这一事实不能在一般软件中察觉出(即使是WoF驱动),因为已经在ntfs那一层被包装了
5. 文件分块未必会真的降低性能,考虑到现在磁盘技术的发展,这部分损耗可能没有显著的性能影响——除非剩余可用空间过小,随便放点文件就一堆碎片(

点评

那请教楼上你对wimboot对系统性能的影响是如何的看法呢?  详情 回复 发表于 2020-12-11 18:06
xman00 发表于 2020-12-11 17:43:47
CodeHz 发表于 2020-12-8 20:02
这文章虽然结论对的,但是具体解释我觉得解释歪了
所谓指针文件就是一个ntfs reparse point(NTFS重解析点 ...

请问:
”所以文件的块可以直接顺序排列(这点上甚至优于传统文件系统,但是由于wim文件本身也在别的文件系统里, 所以还是会被分块和重新排列“
应如何理解呢?

点评

1. 正常的文件系统都会对文件进行切割和重新排列以提升空间利用效率,所以文件只要超过一定大小就几乎一定会被重组(太小的甚至可以直接压到元数据里,不会被切割) 2. 压缩文件内部可以把文件按顺序直接排列,但是  详情 回复 发表于 2020-12-11 18:04
CodeHz 发表于 2020-12-8 20:02:20
这文章虽然结论对的,但是具体解释我觉得解释歪了
所谓指针文件就是一个ntfs reparse point(NTFS重解析点),具体知识需要看windows internal
不能说它不是挂载,你可以把它看作一种特殊的文件系统标记,可以给文件系统过滤器驱动提供信息,然后wimboot实际使用的就是WoF.sys(windows overlay filesystem),它的作用类似于linux上的unionfs/overlayfs,就是可以把多个目录结构折叠到一个目录里,wimboot里就是把wim表示的文件作为最底层,然后写入时则会进入另一层,这个过程和ntfs mount point的实现几乎没有区别,ntfs的挂载点也是创建一个reparse point(对整个目录,而不是按文件),然后由过滤器驱动去处理这个目录下的读写请求,区别就是有没有合并多个层。
(在现代windows上重解析点使用很广,one drive的按需下载的文件也是通过reparse point实现的)
再说说解压,解压缩再快还是有区别的,这里看不出的主要原因是相比于ssd的访问延迟和吞吐量来说,LZMS/LZX的解压缩根本不在一个数量级,然后由于不需要考虑后期写入的问题,所以文件的块可以直接顺序排列(这点上甚至优于传统文件系统,但是由于wim文件本身也在别的文件系统里,所以还是会被分块和重新排列,所以优势有限)。
从这个角度来说,wim和普通的压缩没有特别大的区别,几个区别就是它能正确保留ntfs的各种信息,包括权限和额外数据流,以及更为紧凑的数据组织形式,之所以觉得解压普通压缩文件慢(不考虑开高压缩的),主要因素是需要先完整解压完整文件才能开始使用,用户体验上差了很多,理论上可以微软是可以把zip变成WoF这样的实现的,但是估计微软是不打算改了。
这类技术甚至可以在移动设备上使用,某为的EROFS也是基于这个原理对系统分区做压缩,同时不影响读取性能。
vhd(x)之所以影响大,是因为它的格式要允许写入,所以不能直接按顺序排列文件的块,然后文件本身又被上层文件系统再次分块,等于访问一个文件要经过两个不同层次的间接索引,性能自然影响不少,但是好处是可以无缝写入新文件,和修改文件wim要修改基本等于重建,如果是正常系统,更新的时候就会gg,所以现在微软主推compact,虽然压缩率低了点,但是可以方便的修改和替换文件

点评

请问: ”所以文件的块可以直接顺序排列(这点上甚至优于传统文件系统,但是由于wim文件本身也在别的文件系统里,所以还是会被分块和重新排列“ 应如何理解呢?  详情 回复 发表于 2020-12-11 17:43
bfgxp 发表于 2020-12-8 17:59:16
对于想在pe环境看着分区内容简洁的,wimboot+vhd是最优解
至于性能,感觉不明显。
关于性能还有一个特例,同一台计算机,基于vboot1.1驱动的vhdXP的读写性能明显高于常规硬盘安装的XP系统。
qq2348227 发表于 2020-12-8 17:31:21
学习一下~凹力給…
xman00 发表于 2020-12-8 15:32:12
暖贴一把
junyee 发表于 2020-7-25 07:47:21
vhd 确实有性能损失,在HDD上比较明显.

wimboot 一直没敢用,其实也不如vhd方便.
压缩对CPU性能肯定有损失的,
哪怕是硬件解压缩也不如IO直读.

x9tian 发表于 2020-7-24 20:01:13
本帖最后由 x9tian 于 2020-7-24 20:03 编辑

谁告诉你WIMBoot 不卡的,  
你压缩率压到最狠:
   用分离增量: --delta  WIM  (官方WIM) 和 append   dwm (wimlib-imagex 的最大压缩比)

  不同的压缩比, 开机进游戏,随你多好的配置,就没有开始不卡的.  卡一分儿就好了.
  

捕获.PNG (21.39 KB, 下载次数: 77)

捕获.PNG
283598328 发表于 2020-7-23 21:04:26
这不是文字游戏吗?什么程序和构造执行从微观看不是从特征码开始执行的?就是你用眼睛看人也是从微处着手啊。换了了描述方法就云里雾里的高大上了。这位“大神”只是抓住了语言的“精髓”忽悠了一番而已。就像把耳熟能详的事情用不可描述的方式忽悠了三岁小孩。
ls68057121 发表于 2020-3-14 01:02:12
!!!继续呀
xman00 发表于 2020-3-13 22:27:06
能不能不要拿到一半就开跑
teamviewer 发表于 2020-3-13 08:17:31
学习了解一下。原来如此。
lbw2007 发表于 2020-3-13 08:15:00
说句题外话,对以下内容有争议:

最近一个月老在研究微软的wimboot技术,目前已知从各种网友的实验中比起正常系统来,得知vhd会降低性能,而微软神奇的wimboot技术却不会降低性能反而会提升速度。
之前有坛友分享过测试结果:[转贴] 传统、VHD、VHDX性能对比测试(转帖)结论是不同模式基本没有区别。我自己也在用VHD,没发现与传统模式性能上的差距。请问楼主所说的VHD会降低性能这一说法,从何而来?


点评

我也是长期使用vhdx 老实说 一定有降低 但是 sdd上使用中我们无法直观感受出来 和正常系统没有区别  发表于 2020-3-14 01:20
黑中见白 发表于 2020-3-13 00:40:44
本帖最后由 黑中见白 于 2020-3-13 00:41 编辑

问题来了,WimBootCompress.ini
的内容是啥WimBootCompress.ini
不经过改动,
wim包塞ramdisk上是没法启动的
kkkssc 发表于 2020-3-12 22:48:08
primo ramdisk + wimboot  Ramos 无敌
9695 发表于 2020-3-12 21:59:42
学习
邪恶海盗 发表于 2020-3-12 21:30:38
我只知道PE里用的时候有个解压的过程...
liujun2000 发表于 2020-3-12 21:24:50
很好

小黑屋|手机版|Archiver|捐助支持|无忧启动 ( 闽ICP备05002490号-1 )

闽公网安备 35020302032614号

GMT+8, 2024-11-28 04:32

Powered by Discuz! X3.3

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表