关于 RAM DISk 方式启动 IMG/VHD 的延时加载优化（混合mem map）

Yonsm

我想象中理想的 RAM OS 启动方式应该是, mem 和 img 混合的模式：

1. map --mem --top 一个 IMG，但增加一个参数，--delayRead，即不要立即把所有的文件装载到内存中；但分配好内存空间。

2. 分配好一个专有的标识区域，大小为（mem_drive_sector_size /8 个字节），标识区域清零。
  （1G的内存盘，共0x200000个扇区，即需要0x200000个位来保存读取状态，换成换字节为0x40000，即1G的内存盘，只有256K内存就能报保存这些是否读取的标志了）

3. 增加一个内存磁盘读取的 hook，在读取内存磁盘的时候，如果在专有的标识区域中发现某个sector没有装载过，则先从 img 中读取相应的数据。
（这里只hook mem drive read，write不hook，完全按照传统的memdrive即可）

4. boot 的时候从memdrive启动，基于2+3的功能，IMG文件不会全部装载，而是按需读取并缓存到了RAM DISK中。这时候需要读取的文件实际上是一部分的，不会读取整个 IMG 的所有内容，所以相对于完整装载img会快很多。

chenlall 和 不点 能否八一八这个方案有没有可行性？或者有没有现成的能达到目的的、类似的方案（RAM OS+按需装载）？

[ 本帖最后由 Yonsm 于 2011-9-29 20:42 编辑 ]

Yonsm

提前到一楼了啊哈a

[ 本帖最后由 Yonsm 于 2011-9-29 20:42 编辑 ]

chenall

首先关于FIND命令
这是正常的,第一个是当前的分区.

2.从(hd0)+1的内容可以看得出来,你的RAM.IMG只是一个分区镜像.因为没有分区表,所以映射到(hd0)之后你无法使用(hd0,0)来访问里面的文件,但是可以使用ls (hd0)来访问.

你可以把RAM.IMG制作成带分区表的镜像,这样就不会有这个问题了,

使用--mem参数时,如果没有分区表会自动添加,所以map --mem是没有问题的.

Yonsm

原帖由 chenall 于 2011-9-28 14:21 发表
首先关于FIND命令
这是正常的,第一个是当前的分区.

2.从(hd0)+1的内容可以看得出来,你的RAM.IMG只是一个分区镜像.因为没有分区表,所以映射到(hd0)之后你无法使用(hd0,0)来访问里面的文件,但是可以使用ls (h ...

明白了，多谢从密密麻麻的文字丛中回答问题：）

VDM似乎不能创建带分区表的映像文件，郁闷的这个。VHD似乎就带有分区表，我试试看VHD如何。

我再问一下二楼中文过的问题，直接从 IMG、VHD读取，是不是所有修改都被保存啦？（因为此时完全没有用到内存盘）。

chenall

修改是直接修改磁盘上的文件,所以会被提交,

有没有支持WIN7我没有测试过,不过理论上是可以的.

后面的我不懂,等不点来答案,看起来是挺不错的方案...

chenall

是的.

可以试试IMDISK,,我比较习惯用IMDISK,用IMDISK创建的磁盘保存时可以选择带分区表的.

当然了也可以直接使用固定大小的VHD,这样这个VHD就可以多用了.

不点

逻辑过于复杂，实现起来并不简单。

keep is simple stupid。

Yonsm

原帖由 <i>不点</i> 于 2011-9-28 19:06 发表 <a href="http://bbs.wuyou.net/redirect.php?goto=findpost&pid=2311502&ptid=200597" target="_blank"><img src="http://bbs.wuyou.net/images/common/back.gif" border="0" onload="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onmouseover="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.style.cursor='hand'; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onclick="if(!this.resized) {return true;} else {window.open(this.src);}" onmousewheel="return imgzoom(this);" alt="" /></a><br />
逻辑过于复杂，实现起来并不简单。<br />
<br />
keep is simple stupid。

<br />

但是获益非常大。这才是最完美的RAMOS方案——虽然我理解G4D并非专门为RAMOS而作。

Yonsm

如果确认方案可行，希望能考虑这个功能，或者指点一二，我去看看。

zxw

实现按需加载，想法很好，如实现了当然完美。但是实现起来，并不是那么容易。我们要考虑到，开发者仅有这么几个人，不点的身体已经够糟了，呵，就不要太苛刻了！

pseudo

Yonsm是PECMD前身XCMD的作者，功力深厚。无忧的PE现在都离不开PECMD这个工具（PE桌面一般有PECMD图标）。
Y大愿意出手增强g4d，我等g4d用户幸甚。

zxw

失敬失敬，Yonsm这个名字是看着挺熟的，原来是XCMD的作者。呵，Yonsm大如愿意加入开发，幸甚幸甚！

thttht

以这种非RAM DISk方式启动 IMG的映像文件必须要求带分区表的映像文件，这个是以这种方式启动的必须条件之一！还有就是必须用Firadisk驱动的最新版本（0.0.1.30）

thttht

原帖由 Yonsm 于 2011-9-28 14:00 发表
我想象中理想的 RAM OS 启动方式应该是, mem 和 img 混合的模式：

1. map --mem --top 一个 IMG，但增加一个参数，--delayRead，即不要立即把所有的文件装载到内存中；但分配好内存空间。

2. 分配好一个专 ...

这个方案很诱人啊！不过既然是在内存中预留镜像的全部空间，但并不完全载入这样启动时加载镜像的时间会很快！这对象Win7这样的大系统会很明显，但这样也同样带来一定的问题，就是第一：系统启动后这个镜像文件不能编辑和移动了，会一直占用！（目前map --mem方式的系统启动后这个镜像文件可以编辑、移动和删除）第二：目前map --mem方式的RAM OS系统就是要摆脱硬盘速度慢的系统瓶颈，使系统反应速度变快！如果不全载入内存，用到时在读取硬盘，这样是不是RAM OS系统就只相当于还原卡的效果了啊！

我觉得如果是在内存中预留镜像的全部空间，不如更灵活一点，在加载镜像启动RAM OS系统时能否像map方式那样一边加载镜像文件到内存（先加载系统启动要用的文件），一边启动系统，不等这个镜像完全加载完就引导这个系统！并且在引导系统的同时继续加载镜像直到完全加载到内存中（优先加载系统启动时读到用到的文件）！这样系统启动后镜像还会继续加载直到完全加载完成！不过我想要实现这些就不光要 GRUB4DO 做出改进了，firadisk/winvblk 这些驱动也要做很大偶的改进共同配合才行吧！

这样就相当于 map方式和map --mem方式的结合体一样！也具备这两种方式的优点！想法有的疯狂！不知道能否有希望实现！如果可以的话这应该是RAM OS的终极方式了吧！

[ 本帖最后由 thttht 于 2011-9-29 09:28 编辑 ]

Yonsm

原帖由 thttht 于 2011-9-29 09:22 发表


这个方案很诱人啊！不过既然是在内存中预留镜像的全部空间，但并不完全载入这样启动时加载镜像的时间会很快！这对象Win7这样的大系统会很明显，但这样也同样带来一定的问题，就是第一：系统启动后这个镜像文 ...

我说的方法是“按需加载”，你说的方法是“延时加载“，其实不需要驱动支持的，很简单：

-delayLoad后面加一个参数=xxxx，表示xxxx秒钟过后，自动读取所有没有读取过的sector。

（但不知道GRUB在系统启动后是不是还有代码活着？定时器可否实现）。

功能可以这样设计，但我觉得我作为G4D用户，不会这样用，因为用不到的东西实在没有必要Preload到内存，用到的时候再加载不是更好（虽然第一次用到相对会慢一些）。


纸上谈兵了，呵呵……

pseudo

第3点，“write不hook，完全按照传统的memdrive即可”
write是向内存写还是向img写？
如果是向内存写，那么写后好像也要修改标志为已读，以便下次读出的是新写的内容，避免丢失修改。
这意味着write也得hook了。

xianglang

启动系统后再按需加载，我想衬布难度实在是太大了。一是在诸如XP系统启动接管控制之后，还得将G4D保留着，以便XP需要时再该上G4D加载——天啊，其繁杂程序和兼容性、稳定性等等问题，真是让人不敢想象……而且这样的混合内存系统，倒不如直接启动RAMOS之后，再按需在硬盘是复制或者解压需要的软件到内存盘再使用，实现起来来得简单。

thttht

（但不知道GRUB在系统启动后是不是还有代码活着？定时器可否实现）。

正是因为这样，所以我猜应该是和firadisk/winvblk 这些驱动配合才行吧！这样GRUB在系统启动后失去控制了好由firadisk/winvblk驱动继续完成这些操作！我时这样想得！不知道逻辑对不对！

==========================================================================================
还有这里我说的是启动阶段也是“按需加载”文件到内存并同时启动系统，之后也进行“延时加载“文件的步骤完成全部镜像的加载，（我觉得这样更好吧！）毕竟已经预分配了完整大小的内存了！这样就既不用等待大镜像文件的加载过程也避免了你说的“（虽然第一次用到相对会慢一些）”情况了！不是很完美吗？

如果只“延时加载“的话是不是存在“延时”前后文件内存指向不同的问题啊？因为启动系统是是map启动后 map --mem  不太清楚这样是不是会造成文件内存指向不同的问题啊？带来问题啊？

“我说的方法是“按需加载”，你说的方法是“延时加载“，其实不需要驱动支持的，很简单：
-delayLoad后面加一个参数=xxxx，表示xxxx秒钟过后，自动读取所有没有读取过的sector。”

======================================================================================
不过这些是不是难度和工作量太大了啊！对编程不懂，这个想法实际真的有可能实现吗？

[ 本帖最后由 thttht 于 2011-9-29 11:40 编辑 ]

不点

Yonsm 的想法，太过于超前了。具体实现时，你就知道难度有多大了。

举个例子就可以说明问题。很多人希望 grub4dos 的仿真支持 “不连续” 的映像。我拒绝这么做。理由也向大家说清楚了。

后来，karyonix 决定做这个工作。但是，至今没有听到有什么进展。

这问题不像初看起来那么简单。

不要把 “理想” 与 “现实” 划等号。

Yonsm

原帖由 <i>pseudo</i> 于 2011-9-29 10:34 发表 <a href="http://bbs.wuyou.net/redirect.php?goto=findpost&pid=2311827&ptid=200597" target="_blank"><img src="http://bbs.wuyou.net/images/common/back.gif" border="0" onload="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onmouseover="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.style.cursor='hand'; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onclick="if(!this.resized) {return true;} else {window.open(this.src);}" onmousewheel="return imgzoom(this);" alt="" /></a><br />
第3点，“write不hook，完全按照传统的memdrive即可”<br />
write是向内存写还是向img写？<br />
如果是向内存写，那么写后好像也要修改标志为已读，以便下次读出的是新写的内容，避免丢失修改。<br />
这意味着write也得hook了。

<br />

嗯，这个说的是。

Yonsm

原帖由 <i>不点</i> 于 2011-9-29 13:50 发表 <a href="http://bbs.wuyou.net/redirect.php?goto=findpost&pid=2311917&ptid=200597" target="_blank"><img src="http://bbs.wuyou.net/images/common/back.gif" border="0" onload="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onmouseover="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.style.cursor='hand'; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onclick="if(!this.resized) {return true;} else {window.open(this.src);}" onmousewheel="return imgzoom(this);" alt="" /></a><br />
Yonsm 的想法，太过于超前了。具体实现时，你就知道难度有多大了。<br />
<br />
举个例子就可以说明问题。很多人希望 grub4dos 的仿真支持 “不连续” 的映像。我拒绝这么做。理由也向大家说清楚了。<br />
<br />
后来，karyonix  ...

<br />


我只是理一下想法，具体的难度好像就在hook。

我想问一下现有的 map hook是有g4d代码模拟实现的？还是说只是修改了某个数据（比如某个什么系统的表什么的），由bios自动实现map的？
如果是前者，则我说的方案并没有太多可见的难度，只是普通的工程量吧？如果是后者，那和现有的map完全不是一个实现方案了。

不点

在没有 hook 之前，int13 的仿真代码没有挂到中断向量表上。

在 hook 以后，int13 仿真代码就挂在中断向量表上了。

你自已看看源代码吧。

nk0769

确实超前,能把要读的文件列表直接写出来(甚至可以修改)更好了

jianliulin

举个例子就可以说明问题。很多人希望 grub4dos 的仿真支持 “不连续” 的映像。我拒绝这么做。理由也向大家说清楚了。

后来，karyonix  ...

burg 很早以前就实现了直接map 不连续的文件

dark_enigma

很有意思的方案，不过是否基于文件hook会比基于扇区hook要好些呢，毕竟有可能还没来得及全部扇区hook完毕，就发生改写事件，会不会出错呢。

不过这样实现起来会更加的麻烦