支持含有碎片的文件仿真

mdyblog

发现个奇怪的问题：map 很花时间，本地硬盘 竟然12秒。 感觉不正常。
请问怎么才能 加快 到 1秒以内。
如图：

mdyblog

chenall 发表于 2014-12-19 20:22
U盘的吗???
geometry (0x80)看一下.

是本地ATA硬盘。 （USB2.0的U盘效果也一样， 12~17秒）
本地ATA硬盘，重新截图，如图：

这次是14s

tst.sh:

1. !BAT
   
2. echo geometry (0x80)
   
3. geometry (0x80)
   
4. echo  [map  (hd0)0x34F38+0x7D0000 (0)] ... %@time%
   
5. map  (hd0)0x34F38+0x7D0000 (0) > nul
   
6. echo [map  (hd0)0x34F38+0x7D0000 (0)] end %@time%

复制代码

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
好像 时间 随 分区大小 变大而变大！！！！！！！！！！！！！---妈呀！！

10G的win7分区，测试要39s，（还是前面那个ATA硬盘）：




--------------------------------------------------------
测试方法如下,你也可以这样测试体会下。
--------------------------------------------------------
测试方发如下：
用任意一款分区软件看看本机的分区， 找个大点的分区， 我这里用10G的WIN7分区测试（我用的MBROSTool自带的，能自动转换为扇区单位）。如图：

  
记住其起始28571648K和大小10498432K，（扇区单位则为：  起始57143296扇区， 大小20996864扇区）
对应的G4D的写法就是 (hd0)57143296+20996864
对应测试代码tst7.sh:

1. !BAT
   
2. echo geometry (0x80)
   
3. geometry (0x80)
   
4. echo [map  (hd0)57143296+20996864 (0)] ... %@time%
   
5. map  (hd0)57143296+20996864 (0) > nul
   
6. echo [map  (hd0)57143296+20996864 (0)] end %@time%

复制代码

mdyblog

请问 #564楼  map 慢的问题 能解决吗？

mdyblog

不点 发表于 2014-12-20 13:11
BIOS 读盘慢，有啥可解决的？给主板 BIOS 制造商提建议，要求他们将 BIOS 的读盘速度提高。估计你也没兴 ...

》》BIOS 读盘慢，有啥可解决的？给主板 BIOS 制造商提建议，要求他们将 BIOS 的读盘速度提高。估计你也没兴趣去提意见，即使提了，人家也不一定采纳。

map  要39秒， 这和  "BIOS 读盘慢"没啥 必然关系吧！
map 不是 必然需要 读取 整个分区。
只是 建一个 仿真硬盘， 又不是 那种  要读到内存 里去的 内存盘！
应该 是毫秒级。
还是上面那个10G win7分区
map    --in-place     (hd0,1)    (hd1,0)
map    --rehook
就是瞬间完成。这里同样建立了个仿真硬盘。

mdyblog

不点 发表于 2014-12-21 08:46
抱歉，我眼睛花了，以为是 --mem 呢。

莫非是 0.4.6 的 bug？请确认一下，0.4.5 有这样的问题吗？

谢谢回复！
最新0.45C测试了2此， 1此11秒，1次12秒。都是前面测试的ATA的10G的Win7分区。 比0.46快多了，但还是很慢。   
如图。

mdyblog

不点 发表于 2014-12-21 08:46
抱歉，我眼睛花了，以为是 --mem 呢。

莫非是 0.4.6 的 bug？请确认一下，0.4.5 有这样的问题吗？

基本可以确定是新版本的BUG。
我用珍藏的 旧版 0.45B20110714， 2秒就成功完成了。虽然不是毫秒级。但真的快多了。如图：

mdyblog

不点 发表于 2014-12-21 08:46
抱歉，我眼睛花了，以为是 --mem 呢。

莫非是 0.4.6 的 bug？请确认一下，0.4.5 有这样的问题吗？

再测其他版本，找到最近的版本。

0.46a20121231： 12秒和 0.45C一样。看来 2012.1231此时已经有问题了。

mdyblog

不点 发表于 2014-12-21 08:46
抱歉，我眼睛花了，以为是 --mem 呢。

莫非是 0.4.6 的 bug？请确认一下，0.4.5 有这样的问题吗？

0.46a20120101:  3秒

mdyblog

不点 发表于 2014-12-21 08:46
抱歉，我眼睛花了，以为是 --mem 呢。

莫非是 0.4.6 的 bug？请确认一下，0.4.5 有这样的问题吗？

找到0.46a变慢的相邻2个版本了。
0227: 测3次，依次： 2秒  2秒  3秒

0324: 14秒



0.45C也是这个日期对应的2版本。

mdyblog

不点 发表于 2014-12-21 16:54
相关的改动都看了，没有发现问题。看来问题很隐蔽。也许 chenall 能弄清楚。

你可用 debug on 打开调试 ...

debug on 如图： 好像没有什么东西。

mdyblog

不点 发表于 2014-12-21 18:02
那你自己在 map_func 里面插入输出语句，判定哪个地方最耗时。

前面不是找出来了吗？还用找吗？
当然各人的思想方法不同。
我是用的"中华思想文化"，而不是西方“菲罗教”(philosophy),是 “实干家”。
已经定位到0.45C120227（0.46a）正确，
                   0.45C120322（0.46a-0324）不正确，
问题和那几行改变的代码有关。
对 “实干家”， 代码写对了，就好了，至于背后的一堆“真理/原理”，毫不在意。“为什么会慢，也毫不在意——只要消除了即可。”
从那几行“改变的代码”出发，就可以了。

如果没有上面我提供的精确信息，可以依据原理，尝试从 map_func 出发，大海捞针。
现在有了上面我提供的精确信息，完全可以直接从 那几行“改变的代码”出发， “精确制导”。

对我中华“实干家”，来说，现在问题已经定位，就剩C大付诸实行了。


说话不周，请海涵！

mdyblog

不点 发表于 2014-12-22 08:32
你大概没注意，我说过，我看不出那几天的改动哪里有错。因此，才需要你来找。

那你再等待 chenall 等 ...

》》你大概没注意，我说过，我看不出那几天的改动哪里有错。因此，才需要你来找。
没找出来也无所谓。
只要代码对了就可以。 程序中很多问题都是，不知道为什么，就已经消除了，尤其是这种和硬件打交道的情况——不纠缠了。

大不了， 将 20120322的更改撤销掉。

mdyblog

chenall 发表于 2014-12-22 12:33
嗯,编译器自动优化确实是个问题,我也碰到过多次,代码没有问题,编译出来的有问题.

只好在代码里面换一 ...

不要用O2
-O就可以了。
有些gcc的O2有问题。

mdyblog

chenall 发表于 2014-12-22 11:51
我也是试了没有找到原因,而且我这里测试速度没有多大变化呀.

你可以测试一下这三个重新编译的(对应那一 ...

grldr0.4.5c-cd5e107： 3秒
能不能在0.46a上改啊？

mdyblog

chenall 发表于 2014-12-22 11:51
我也是试了没有找到原因,而且我这里测试速度没有多大变化呀.

你可以测试一下这三个重新编译的(对应那一 ...

grldr0.4.5c-a6bfd1a： 11秒----慢

mdyblog

chenall 发表于 2014-12-22 11:51
我也是试了没有找到原因,而且我这里测试速度没有多大变化呀.

你可以测试一下这三个重新编译的(对应那一 ...

grldr0.4.5c-a1cbe95： 11秒--慢

mdyblog

chenall 发表于 2014-12-22 11:51
我也是试了没有找到原因,而且我这里测试速度没有多大变化呀.

你可以测试一下这三个重新编译的(对应那一 ...

》》而且我这里测试速度没有多大变化呀.
需要测试的分区足够大，才能体现这种速度差异。
找个>=10G的系统分区（win7,win8更好）试试。

mdyblog

不点 发表于 2014-12-22 10:44
该怎么办，由 chenall、yaya 来处理吧。这期间有至少两次改动，比较麻烦。其一，我看不出改动有任何毛病。 ...

下面是换台稍新店的笔记本电脑（大概11年的）
性能高点的SATA本地硬盘。
测试的是80G的win7X64分区。

因为分区是原来的8倍，但盘子性能好点，时间普遍是原来的5倍！


随大小而增长。这个不应该。看来主要是的算法问题。
是不是哪儿多了个和大小相关的循环。

grub0.45b2011714无法运行在该电脑上，无法测试。

mdyblog

chenall 发表于 2014-12-22 16:07
那就是a6bfd1a这个版本开始出现的问题了..可是这个里面没有改动任何磁盘读写的代码,,不到找原因.

估计也 ...

找原因，比解决问题更复杂， 尤其是这种嵌入式开发（或者说和硬件打交道，什么稀奇，什么地方都会出现）。

（根据我的经验）我建议，（绕开原因）直接从前面那个正确的版本出发，编译环境什么都不改。
再一点一点地， 将后面版本的代码移过去，每次尽量少移，移一次，测试一下；直到重要的代码都移过去了，还是正确的。就行了。
（至于找原因，那是权当个人兴趣，有空才特地去找。 说不定上面“顺便”就找的差不多了）

mdyblog

不点 发表于 2014-12-22 16:26
恶心人的 gcc，给我们造成了很多的问题。

看来最可靠的是汇编了，这不太容易出错。

》》gcc 除了开发者失误的可能性以外，还可能遭到间谍的攻击了。
免费的东西，也不要要求太高。

质量、稳定性和可靠性，是银子堆出来的。
况且gcc这么复杂的系统。
在这个急剧变化的时代，尤其如此。
人家免费，没有收入。
很多工作没有保证。



-----------
容易出问题，主要是使用环境引起的——嵌入式。
这种环境，大部分编译器都会出问题。

最容易出的问题是堆栈溢出。这个时候非常奇怪，换个（逻辑完全等效的）写法问题就没了。

我用摩托诺拉的编译器，也是这样，奇奇怪怪。 一个简单的整数除法，竟然会出问题，看代码根本看不出问题——代码逻辑根本没错。
最后反汇编才找出编译原因。

mdyblog

chenall 发表于 2014-12-23 11:16
这个问题看起来很难解决了.

-        char cmdline_buf[1500];

char cmdline_buf[1500];
这样可能会引起堆栈溢出。
嵌入式开发，最容易出现 堆栈溢出——内存太少，初始化的堆栈一般都很小，很容易溢出。

堆栈溢出，大部分马上死翘翘。
但是， 也有的 没有 马上死， 而是”改变了不改改变的内存“，造成 ”奇奇怪怪“ 的问题。

嵌入式开发 中， 经历避免使用大的临时数组——他们使用的是堆栈。


---
》》很难解决了.
可以定义成非临时变量。
法1） 放在函数外。 就是全局的了。
char cmdline_buf[1500];
void ABC()
{
}
这样， 函数返回后，别的函数还可临时用一下这个数据。
法2） 前面加上static 放在函数内。 就是静态持久的了。
void ABC()
{
        static char cmdline_buf[1500];
}


不是临时变量，这样用的就不是堆栈，就没问题。
不是临时变量， 这段内存始终不会释放。是专用内存。

//反正，看样子， 这个数组不是偶尔才用，变成了事实上的专用内存


》》》》
不知还有没有其它的解决方法?我也尝试过用malloc来分配内存也是一样的效果,真的是很奇怪.
试试这样：

1. static char cmdline_buf0[512+16+1500+512];
   
2. char *cmdline_buf=&cmdline_buf0[512];
   
3. cmdline_buf  +=  (~(int)cmdline_buf)&0x0F;
   
4. cmdline_buf[0]  = 0;
   

复制代码

mdyblog

chenall 发表于 2014-12-23 14:52
使用char cmdline_buf[1500]是旧版本的(也就是速度比较快的)

新的版本是使用专用内存块的.

>>因为这个函数里面的命令会再次调用这个函数,
你是说，会嵌套调用自己？

mdyblog

chenall 发表于 2014-12-23 14:52
使用char cmdline_buf[1500]是旧版本的(也就是速度比较快的)

新的版本是使用专用内存块的.

1） 嵌入式，尽量避免嵌套调用。 因为堆栈有限。

2）可以试试：

1. #define  NUM_CMDBUF  6    //嵌套调用层级
   
2. volatile char id_cmdbuf=0;  //有些命令需要重置为0，故为全局
   
3. int ABC()
   
4. {
   
5.     static int cmdline_bufs[NUM_CMDBUF][(32+1500+32)/sizeof(int)];
   
6.     char inclv=1;  //必须局部
   
7.     char *cmdline_buf=((char*)&cmdline_bufs[id_cmdbuf][0])+32;
   
8.     if(id_cmdbuf  >= NUM_CMDBUF )
   
9.     {   //printf("命令层次太深，命令被忽略\n");
   
10.         return -1;
    
11.     }
    
12.     id_cmdbuf+=inclv;
    
13.     cmdline_buf[0]  = 0;
    
14. 
    
15.     ///...努力干活中...
    
16. 
    
17. 
    
18.     id_cmdbuf-=inclv;  if(id_cmdbuf<0) id_cmdbuf=0;
    
19.     return 0;
    
20. }

复制代码

注意, 碰到某些不返回的命令,如configfile;   id_cmdbuf 重置为0。如果因此碰到冲突，可把当前命令中的重要参数提出来，单独存放。
碰到有些命令，可以提前释放cmd_buf：

1. id_cmdbuf-=inclv;  inclv=0;

复制代码

mdyblog

chenall 发表于 2014-12-23 15:51
所有执行的命令都是通过这个函数来执行的.

一个比较常见的情况就是执行了一个批处理..这时批处理里面 ...

麻烦， 试试上面的 #601楼 方法。 该方法限定 嵌套的层次。每一层有自己专用的cmdbuf.
说明一下即可。实际一般也就几层。

如果可以， 先将最新的0.46a出个版本，大家先用着。(我等着用)
后面再考虑怎么处理（处理可能伤筋动骨，那就很费时了）
而且还要改的， 因为实际0227还是比20110714慢很多。
80G的分区 要 15秒， 还是太长。
估计不是一时半刻的事。

上面 定的是6层。
如果内存够， 可以调大点。



---另外是否考虑command 运行脚本时，是否给开关，也可给个命令。
或者id_cmdbuf放到固定的地址，write 可以修改为0.
使得可以初始化命令层级。（实际不返回了）

mdyblog

chenall 发表于 2014-12-23 19:28
虽然表面上看起来是这里的问题,不过我估计应该有更深的原因.

我通过在MAP_FUNC函数里面插入一些DEBUG信 ...

估计是  blocklist (hd0)xxxx+yyyy 的问题。
前面 测试中，
不用 blocklist (hd0)xxxx+yyyy的形式。
直接用  (hd0,1) 瞬间完成——这才是我要的效果。

1. map    --in-place     (hd0,1)    (hd1)

复制代码

#或 map    --in-place     (hd0,1)    (hd1,0)

mdyblog

2011yaya2007777 发表于 2014-12-23 20:32
为了确定映像文件的连续性，0.4.6a 确实是对没有 --mem 参数的映像文件 1 扇区 1 扇区地从头读到尾。这样 ...

》》为了确定映像文件的连续性，0.4.6a 确实是对没有 --mem 参数的映像文件 1 扇区 1 扇区地从头读到尾。这样确实比 0.4.5c 慢得多。
但这不是问题的根本。从 mdyblog 报告的情况看，a 与 c 速度差不多，且出问题的时间段的 3 个补丁与 blocklist_func 无关。
---------------

这么说， 现在问题查不多找全了。
1）
-        char cmdline_buf[1500];
+        char *cmdline_buf = cmd_buffer;
--------------
是20120324比20120227慢的原因。
，这个可 试试前面 #601楼 方法。 该方法限定 嵌套的层次。每一层有自己专用的cmdbuf.
说明一下即可。实际一般也就几层。

2）
0.4.6a 确实是对没有 --mem 参数的映像文件 1 扇区 1 扇区地从头读到尾。这样确实比 0.4.5c 慢得多。
---
是0.46a 后来版本 如此慢的原因。
对与扇区序列，可以去掉连续性检查。参数本身就能看出好似否连续。
(hd0)a+b
不会出现不连续。
(hd0)1+100,200+100
不用检查，就知道 不连续。

只有基于文件名的才需要检查。应该读一遍即可，以获得扇区序列。

--------------
3a）应该还差个原因， 使得 20120227 比 20110714慢很多。
一直80G的分区， 要 15秒。
估计：还是 连续性检查的原因。

3b）应该还差个原因，20110714  不是瞬间完成。
而

1. map --in-place  (hd0,1) (hd1)

复制代码

是瞬间完成
耗时差不多和大小成正比。
估计：
即使很早的版本， 对扇区序列，和文件是统一处理，都至少有一次从头读到尾的检查。
所以 耗时差不多和大小成正比。

所以，扇区序列，应该和文件分开处理。
扇区序列 不需要 “实地"连续心检查。
这样耗时就和大小无关时间复杂度为O(0),而不是 O(n)
就是瞬间完成。

应该和文件分开考虑。
处理的时候，2个还是可以合并处理，不会有代码冗余：
1) 对与文件map，选获得扇区序列， check_map_sect_lsit()
这样 就转变为扇区序列的map,执行2).
2) 执行扇区序列的map


执行扇区序列map  就是文件map的简化过程，少调用一个子过程，因而瞬间完成。

mdyblog

chenall 发表于 2014-12-23 21:40
经过追踪,目前发现长时间执行的代码段在disk_io.c里面如下代码(0.4.5c),相差了一倍的时间,很是怪异.

这个算法，对 小的扇区序列问题。
对到的扇区序列时间上来了。
因为改算法的时间复杂度为O(n)
是通过每次”尝试加1“实现。

改成 直接计算 出结果，直接一步加到位。
不用尝试了。
这样时间复杂度为O(0)

就是多费脑汁， 思考出个计算公示。

---
我不清楚用到的数据结构，
不然 ， 可以帮忙给出计算公示。

mdyblog

chenall 发表于 2014-12-23 21:40
经过追踪,目前发现长时间执行的代码段在disk_io.c里面如下代码(0.4.5c),相差了一倍的时间,很是怪异.

下面是根据猜测的数据结果转换的O(0)复杂度的为代码。填上对应的实际类型。

1. const sector_size=buf_geom.sector_size;
   
2. const length=blk_buf.cur_blklist->length;
   
3. const d1=blk_buf.cur_filepos & (-sector_size);
   
4. const d2=filepos - d1;
   
5. if ( blk_buf.cur_filepos < filepos )
   
6. {
   
7.         const n1 = d2/sector_size;
   
8.         if(n1>0)
   
9.         {
   
10.                 blk_buf.cur_blknum+=n1;
    
11.                 const n2 = cur_blknum / length;
    
12.                 blk_buf.cur_blklist += n2;
    
13.                 blk_buf.cur_blknum -= n2 * length;
    
14.         }
    
15.         blk_buf.cur_filepos = filepos;
    
16. }

复制代码

mdyblog

chenall 发表于 2014-12-24 09:17
大部份参与计算的都是unsigned long long的.

64位的除法,编译不通过,需要自己写一个64位除法的函数.

buf_geom.sector_size;
blk_buf.cur_blklist->length;
的数值 是个很小的数值，可以用一个unsigned short表示。这样一个简单的除法如下。

1. typedef unsigned long long u64;
   
2. u64 div64mini(u64  a, unsigned short b)
   
3. {   register unsigned long a1=(unsigned long)(a>>32);  unsigned long a2=(unsigned long )a;
   
4.     unsigned long a1v=a1/ b; a1 -=  a1v*b;
   
5.     a1  <<= 16;
   
6.     unsigned long amv=a1/ b; a1 -=  amv*b;
   
7.     a1  <<= 16;
   
8.     unsigned long a2v=a2/ b; a2 -=  a1v*b;
   
9.     a2 += a1;
   
10.     unsigned long a3v=a2/ b;
    
11.     return (((u64)a1v)<<32)  +  (((u64)amv)<<16)+ (a2v+a3v);
    
12. }
    
13. 
    
14. const unsigned short sector_size=(unsigned short)(buf_geom.sector_size);
    
15. const unsigned short length=(unsigned short)(blk_buf.cur_blklist->length);
    
16. const d1=blk_buf.cur_filepos & (-sector_size);
    
17. const d2=filepos - d1;
    
18. if ( blk_buf.cur_filepos < filepos )
    
19. {   const n1 =div64mini(d2,sector_size);
    
20.     if(n1>0)
    
21.     {   blk_buf.cur_blknum+=n1;
    
22.         const n2 = div64mini(cur_blknum, length);
    
23.         blk_buf.cur_blklist += n2;
    
24.         blk_buf.cur_blknum -= n2 * length;
    
25.     }
    
26.     blk_buf.cur_filepos = filepos;
    
27. }

复制代码

mdyblog

chenall 发表于 2014-12-24 10:59
修改了一下上面的代码(复杂度还是不变,只是尽量减少了一些循环内部的计算),目前时间应该和0227差不多.

...

测试结果 10G的分区， 10秒。
和120322查不多(11秒)。
120227 是 3秒

刚才网络突然好慢啊。 图一直传不上来。
如图：