磁盘交换时ud区的处理问题

sratlf

假如u盘为ud启动  启动后占据hd0  那么在磁盘交换后  比如将hd0交换为hd1后  

ud区文件列表还是缓存的旧的列表  ls命令等正常  真正执行时却找不到文件  是否能避免这个问题

比如磁盘交换时也更新相应的ud区文件列表  或是其他的方法  能手动更新

不点

这个问题应该解决，但一时也不那么容易解决。

如果 hd0 仅仅是交换了，那也容易解决。但如果是一部分 hd0 的扇区序列映射为 hd1 了，那样就麻烦了。

只能设法让 ud 盘完全不受 map 的影响。

今后会留意这个问题。看看 chenall 有什么主意。

hotdll

这个问题不是已经解决了嘛？
交换后 改写0x82b9最后两位的值为对应的值即可。
比如你把ud所在的磁盘改为81,0x82b9的最后两位改为81就可以了。

sratlf

这个还需要自己计算应该改写的值  有没有更简单的方法

如果是固定的将u盘所占的hd0交换为hd1简单  如果类似循环交换磁盘顺序的那就没准是哪个了  还得再想办法计算去

不点

你说的是已经有 workaround 了。谢谢，这我可不知道。

最近我在为解决 bug 费脑筋，而 ud 这方面的事情，无暇顾及。还是等 chenall 处理吧。

这个问题，我也就不再想它了。

chenall

很早就有解决方案了,自动处理的我还没有想到很好的办法.

暂时还是留给用户自己 解决吧,必竟用户比计算机更清楚你现在在做什么.

chenall

抽空尝试着考虑了一个方案..大家可以试试

进行磁盘交换时应该可以自动处理ud区,先上传上来测试一下.

注: 经过磁盘交换之后,如果直接map (hd1) (hd1) 或map --unmap来取消映射.ud区还是会无法访问(这个明天再处理).

不点

假如 ud 是在硬盘 hd0 上，后来用户把某个文件 hd.img 映射为 hd0 了，原来的 hd0 无法访问到了，此时如何处理？

Plantsoot

我也一直有这个疑问，用户把某个文件 hd.img 映射为 hd0 了，原来的 hd0 无法访问到了。
原来的 hd0 是不是在g4d的磁盘列表中消失了，还是变成什么特殊标记了？

不点

这就好比在同一个班级，不能有两个重名的人。如果有，就必须用其他方法区分开来。同一时刻，hd0 只能代表一个意思，它要么代表真实的 BIOS 硬盘，要么代表虚拟的硬盘。不能够说，你想读 hd0 的第一扇区，结果两个 hd0 都同时提供给你，一个是 BIOS 的硬盘扇区，一个是虚拟的硬盘扇区。这不就乱了？究竟你要的是哪个扇区？比如班里有两个学生都叫张三，其中一个是要受到表扬的，另外一个要挨批评。老师叫 “ 张三 ”，结果俩人都来了。总不能说，两个都表扬，或者都打屁股吧？

所以，无论何时，只有一个是 “ 起作用 ” 的，或者通俗地说，是 “ 当前 ” 的。当你没有使用 map 时，BIOS 的真实硬盘就是起作用的，即，当前的。当你使用了 map 创建虚拟硬盘以及 --hook 以后，那么虚拟的 hd0 就是起作用的，即当前的。当虚拟的 hd0 起作用时，真实的硬盘处于 “ 隐居状态 ”。当撤销掉虚拟硬盘之后，真实的硬盘就恢复原样，再次 “ 显露 ” 出来了。

[ 本帖最后由 不点 于 2012-5-18 09:24 编辑 ]

sratlf

如果只map磁盘镜像到hd0  没有将hd0映射到别的地方  那原来的hd0应该是消失了

chenall

这个我没有办法处理 ....

另外想了一个方案,操作比较简单,不知是否可行?

启动时若检测到ud存在就把ud映射到FB_DRIVE设备上.这样就可以一劳永逸的解决问题了.
当然了在BOOT时需要自动取消这个映射.

不点

没仔细考虑过。但初看起来，似乎也是一个不错的方案。

不过，已经发现有如下的两个缺点：

第一，映射占用一个 map 的表项。map 的表项总共也只有 8 个，所以，占用了，不太好。记得 initrd 曾经占用一个 map 项目，但是，initrd 属于 Linux，而 Linux 的使用本来就不频繁，再加上 Linux 本身很少使用太多的 map 项目。因此，initrd 的 map 所带来的问题，性质不同，即，不构成严重问题。

第二，映射到 FB_DRIVE，恐怕冲突了。因为 ud 自己在使用 FB_DRIVE。

其中，第二个问题可以解决，即通过映射到另外一个空闲的 BIOS 磁盘来解决。但第一个问题，占用一个 map 项，总是一个缺点。

因此，我想到了一个（可能是）终极的解决办法：修改 bios.c 中的 biosdisk 函数，让它识别并处理 FB_DRIVE。本来，FB_DRIVE 是不通过 biosdisk 函数的。但我们可以修改 fsys_fb.c 中的函数，让 raw_read 之类的函数都不使用 fb_drive 参数，取而代之，使用 FB_DRIVE 参数。而 FB_DRIVE 本来不是一个真正的 BIOS 磁盘，所以，按照常规，biosdisk 是无法访问它的。因此，我们可以修改 biosdisk 函数，让它把 FB_DRIVE 自动当作 fb_drive 来处理。这样就没问题了。换句话说，这就是自动映射了。

更正：这个方法行不通，因为 fb_drive 可以被 map 成别的了。

可行的办法，或许可以修改 fsys_fb.c 中的 raw_read 调用，取而代之，直接访问原始的 ROM int13，这样就不会受到 map 的影响了。


=====================

另外，就着这个帖子，顺便说说我对于 fbinst 的一些设想和看法。fbinst 很成功的地方就在于，它提高了启动成功率。它在这方面有着 80% 以上的成功率，这是很不错的。其他软件都无法与它媲美。

然而，它也有一些缺点。有一些情况适应不了，导致失败、死机。

尤其是，占用 8M，这可能使得原来能够用软盘成功启动的情况变成了失败。因为这 8M 中的开头 1.44M 可以成功访问，而其余的部分不能访问。

因此我在想，fbinst 还可以改进。也许可以设计一个新的启动策略，吸收 fbinst 的长处，而避免其短处。具体来说，就是把 fbinst 和三重 MBR 两者的优点加以结合，这样或许可以催生一个新的启动软件。

[ 本帖最后由 不点 于 2012-5-18 12:34 编辑 ]

hotdll

这样修改后。
winvblock还支持直接map ud中的iso嘛？

Plantsoot

有点明白了，用一个通俗的解释，可以理解为"演员的替身".

谢谢不点。

Plantsoot

嗯，多重MBR确实很有意思。

天涯海角1216  写过几个帖子，我照着做过，挺不错，只不过没有继续研究。


【原创】HDD模式U盘双重MBR系列之—— PloP Boot Manage + FBINST（多版本.11.6更新）

【原创 无忧首发】硬盘版 fbinst +1JF11 等多类型双重mbr系列

[ 本帖最后由 Plantsoot 于 2012-5-18 12:41 编辑 ]

chenall

我觉得可以的,只要GRUB4DOS下能映射到,那就可以了.

现在只要在GRUB4DOS中可以快速直接访问原始ROM int13解决ud映射就比较容易了.

canmao

昨天刚好写了这段代码(将 hd0 循环移至最后)：
【前提是已将处理了u盘被认成为(fd0)或(fd0,0)的情况】

1. debug 1
   
2. if "%@root:~,4%"=="(hd0" && command | call :move_hd0=
   
3. if "%@root%"=="(ud)" && command | call :move_hd0=
   
4. .
   
5. .
   
6. .
   
7. exit
   
8. 
   
9. :move_hd0
   
10. debug 0
    
11. set /a hdn=*0x475&0xff+0x7f
    
12. map (hd0) (%hdn%)
    
13. calc *0x82b8 && calc *0x82b9=*0x82b9&0xffffff00|%hdn%
    
14. if "%@root%"=="(ud)" goto :movenext
    
15. set /a currd=%hdn%-0x080
    
16. set currd=(hd%currd%
    
17. if "%@root%"=="(hd0,0)" set currd=%currd%,0
    
18. command --set-path=%currd%)%~p4
    
19. rootnoverify %currd%)
    
20. :movenext
    
21. set /a hdn_1=%hdn%-1
    
22. map (%hdn%) (%hdn_1%)
    
23. set /a hdn=%hdn%-1
    
24. if %hdn%>=129 goto :movenext
    
25. map --hook
    
26. exit

复制代码

参考 hotdll 的代码写的

[ 本帖最后由 canmao 于 2012-5-18 16:41 编辑 ]

sratlf

这种写法都是一次有效  你多交换几次就会发现ud区又不能正常访问了

不点

在研究 fsys_fb.c 的代码时，发现 fb_init 调用了 malloc 函数。

这隐藏着内存冲突的可能性。

像这类问题，都应该解决掉，然后才能放心地发布正式版。

-----------

又看了一下，有关 fb 的问题还有很多。比如，biosdisk 函数一开始就先判断 fb 的情况，

这就意味着，私自改变 fb_drive 的值，会导致与此处的判断割裂开来，造成 max_sec 不能正确赋值。

-----------

我个人初步的意见是，保持现状，不要动它。也不要对 ud 所在的盘进行 map 操作。

就是说，一旦 map 之后，就永远不要再访问 ud 了。

-----------

将来可以在 0.4.6 中发展一种新的技术，来取代 fb，正如前面提到的。

[ 本帖最后由 不点 于 2012-5-18 19:17 编辑 ]

chenall

目前还有许多地方用到malloc函数,像PXE的文件列表,批处理脚本的缓冲区.

因为不知哪一些空间是安全的.

FB的修改比较容易,因为支持直接(hd0)/的访问方式,为了避免反复读取(ud)的文件列表,所以这个方式使用了额外的内存空间.

当然可以改动使用同一块内存,但是如果有用(hd0)访问了之后再访问(ud)时可能需要重新读取文件列表.

[ 本帖最后由 chenall 于 2012-5-18 19:16 编辑 ]

不点

我个人寄希望于，将来可以在 0.4.6 中发展一种新的技术，来取代 fb，正如前面提到的。

我的观点是，现在的一切保持不动。

fb 的另一个可能的问题，是它给出每次读取的最大扇区数目。实际上，探测这个最大数目的探测过程，就可能造成死机，尤其是当恶意商家故意制造死机的时候。很难说以前 fb 所遇到的死机是否与此有关（即，有可能与此有关）。

sratlf

这样的话就保留现状吧  差不多可以结贴了  #1的问题我已经在脚本里解决了  循环交换时会更新0x82b9值  也算是解决了

ltzltz

看了半天没弄清.