C大，GRUB4DOS的map功能能不能添加缓存？

wannaknow

map (0)/a.iso (0xff)
map --mem (0xff)/b.iso (0xfa)
中间是不是还要有map --hook啊，你是不是省略了？

wannaknow

我突然想起来，很久以前，在老爷机上，用word打开软盘上的文件，能卡10分钟。
但是要是先拷贝，再打开就快多了。

map --mem (0)/a.iso (0xff)
map --mem  (0xff)/b.iso (0xfa)
第二步很快是因为做了优化，直接原地重新map。但第一步应该比较慢


map (0)/a.iso (0xff)
map --mem (0xff)/b.iso (0xfa)
第二步成了蜗牛了。。。比从(0)读a.iso要慢

是不是因为第一步的map导致的对齐的问题？

[ 本帖最后由 wannaknow 于 2011-11-17 12:59 编辑 ]

wannaknow

唉，根源还是当初规定，一次int 13h调用(CHS)不能要求读写跨磁道的连续扇区，一切以简化bios编写为目标。

结果最后所有人都嫌麻烦，才提出LBA的概念。

wannaknow

问题不仅如此，即使改进int 13h钩子，也会有性能损失。
对于虚拟的(0xff)来说，它是支持lba的大扇区光盘，不存在任何“对齐”的问题，每次读取都是以2048k为单位的。
可是，事实上，它可能是由1024/255/63的盘虚拟的。
只要bios不支持lba，再怎么改进，一次真实读取也不能跨过63这个“沟”
因此，会有大约3/63次读被“砍”成要读两次。

最糟的情况是18sectors per track，然后a.iso还是从奇数扇区开始的（又想了想，不对，a.iso的位置影响不大）。

[ 本帖最后由 wannaknow 于 2011-11-17 15:15 编辑 ]