支持含有碎片的文件仿真

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;

复制代码

chenall

不点 发表于 2014-12-23 15:07
这样就有溢出的可能了。反复调用这个函数，会导致内存消耗变大，这样就容易间接造成内存冲突。

所有执行的命令都是通过这个函数来执行的.

一个比较常见的情况就是执行了一个批处理..这时批处理里面的命令还是需要使用这个函数..

另外批处理里面还要再次调用批处理等.

mdyblog

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

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

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

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

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



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

chenall

虽然表面上看起来是这里的问题,不过我估计应该有更深的原因.

我通过在MAP_FUNC函数里面插入一些DEBUG信息,发现是blocklist_func的问题.在map 里面调用blocklist_func命令时等待了很长的时间.

看来还得继续花时间继续跟踪一下blocklist的情况.

你可以测试一下以下命令使用的时间.
blocklist (hd0)xxxx+yyyy

@不点,对于(hdx)AAAA+BBb是不是可以不用执行blocklist_func?

另外请yaya确认下,0.4.6a对map函数的修改是否有问题.
0.4.5c的map命令调用blocklist_func时只调用了disk_read_blocklist_func一次,而0.4.6a则调用了很多次..

所以0.4.6a应该会比0.4.5c慢上很多.

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)

不点

对于(hdx)AAAA+BBb是不是可以不用执行blocklist_func?

即使执行了也不可能慢。对于任何文件，map 所调用的 blocklist 命令，都只打开它的第一扇区和末尾扇区，这基本不花费时间。

我觉得，如果有问题，那是好事，正好可以用它来暴露代码的错误。“问题” 就是下蛋的母鸡，如果把母鸡宰杀了，那就没有鸡蛋了。平时你想找这样的母鸡，那还找不着呢。所以，问题报告是非常珍贵的。

根据 mdyblog 的报告，早期的版本没有问题。那就可以证明，不是因为对 (hdx)AAAA+BB 调用了 blocklist_func 所引起的问题。因此也能断定，是后来的代码中的错误，蔓延到、影响到 blocklist 的错误了。比如，有可能是某个内存溢出造成的结果。严重的内存溢出会导致死机。死机问题其实还比较容易定位。但不严重的内存溢出，会产生更加难以追踪的错误。

2011yaya2007777

另外请yaya确认下,0.4.6a对map函数的修改是否有问题.
0.4.5c的map命令调用blocklist_func时只调用了disk_read_blocklist_func一次,而0.4.6a则调用了很多次..

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

chenall

经过追踪,目前发现长时间执行的代码段在disk_io.c里面如下代码(0.4.5c),相差了一倍的时间,很是怪异.

1. 
   
2.           while (filepos > blk_buf.cur_filepos)
   
3.             {
   
4.               //if ((filepos - ((*((unsigned long*)FSYS_BUF)) & ~(buf_geom.sector_size - 1)))
   
5.               //  >= buf_geom.sector_size)
   
6.               if ( (filepos - (blk_buf.cur_filepos & (-(unsigned long long)buf_geom.sector_size)))
   
7.                   >= buf_geom.sector_size )
   
8.                 {
   
9.                   //(*((unsigned long*)FSYS_BUF)) += buf_geom.sector_size;
   
10.                   blk_buf.cur_filepos += buf_geom.sector_size;
    
11.                   //(*((unsigned long*)(FSYS_BUF+8)))++;
    
12.                   blk_buf.cur_blknum++;
    
13. 
    
14.                   //if ((*((unsigned long*)(FSYS_BUF+8))) >= *((unsigned long*) ((*((unsigned long*)(FSYS_BUF+4))) + 4)) )
    
15.                   if (blk_buf.cur_blknum >= blk_buf.cur_blklist->length )
    
16.                     {
    
17.                       //(*((unsigned long*)(FSYS_BUF+4))) += 8;        /* BLK_CUR_BLKLIST */
    
18.                       blk_buf.cur_blklist++;
    
19.                       //(*((unsigned long*)(FSYS_BUF+8))) = 0;        /* BLK_CUR_BLKNUM */
    
20.                       blk_buf.cur_blknum = 0;
    
21.                     }
    
22.                 }
    
23.               else
    
24.                 //(*((unsigned long*)FSYS_BUF)) = filepos;
    
25.                 blk_buf.cur_filepos = filepos;
    
26.             }
    

复制代码

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. }

复制代码

chenall

mdyblog 发表于 2014-12-23 23:22
下面是根据猜测的数据结果转换的O(0)复杂度的为代码。填上对应的实际类型。

大部份参与计算的都是unsigned long long的.

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

目前看来应该和编译器优化有一些关系,同样的代码,执行结果也一样,但所花的时间差了一倍.

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. }

复制代码

不点

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

我给出另外一种思路，供参考。

用汇编语言实现这段代码的功能，看看它还会出问题吗？

gcc 是靠不住的。

我甚至怀疑它的开发团队，你懂的。

chenall

修改了一下上面的代码(复杂度还是不变,只是尽量减少了一些循环内部的计算),目前时间应该和0227差不多.

要继续优化的话就只能考虑前面mdyblog给的方案了.

mdyblog

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

...

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

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

chenall

和我的测试结果相差太多了,我用前面的版本时间减小了一半...

再试试这个版本,应该可以瞬间完成了.

原理,考虑到目前GRUB4DOS的sector_size值只有两种512和2048,所以针对这两种情况优化了一下算法,其它情况使用原来的方案,慢慢计算.

这个版本一般情况下都可以瞬间完成.

我是按照我对这一段代码的理解来改写的,就是不知会不会产生其它问题,需要更多的时间测试一下.

mdyblog

chenall 发表于 2014-12-24 11:42
和我的测试结果相差太多了,我用前面的版本时间减小了一半...

再试试这个版本,应该可以瞬间完成了.

这个算法牛！！ 瞬间完成。

麻烦加到 最新的0.46a上， 我再试试。

chenall

mdyblog 发表于 2014-12-24 12:29
这个算法牛！！ 瞬间完成。

麻烦加到 最新的0.46a上， 我再试试。

把这个补丁应用到0.4.6a上,效果不是很明显,

因为0.4.6a需要读取所有扇区的,一个一个读过去的,这个要看yaya是不是能优化一下了.

mdyblog

chenall 发表于 2014-12-24 14:35
把这个补丁应用到0.4.6a上,效果不是很明显,

因为0.4.6a需要读取所有扇区的,一个一个读过去的,这个要看 ...

新版0.46a问题最多最严重，
现在解决的部分，对 新版0.46a， 反倒只是小头。
最耗时的那个 “需要读取所有扇区的,一个一个读过去的”。
测试还要52秒。

目前这个版本是最新的0.46a(20141206)吗

麻烦你先用上面的成果， 将0.46a20120334和0.46a20141206改正。 后面yaya再接着改。免得yaya有重复你的工作。

chenall

上面就是基于最新版本的0.4.6a代码.测试没有问题之后我再更新一下源码,yaya可以接着继续优化.

mdyblog

热切期盼 yaya大 赶快 解决 0.46a 山区序列 map巨慢的问题。
测试最新grub4dos-0.4.6a-2014-12-25.7z, 10G分区， 要52秒。

2011yaya2007777

几种方案：
1.  判断是否属于扇区序列。即便是，也不能简单跳过块列表函数。因为不连续的扇区序列也可以映射，此时需要建立映射表。要增加不少代码。
另外，对于大的文件映射，连续时，也白白浪费时间。
2.  执行块列表函数时，不真正读磁盘。效果不理想。仍然有延时，且对于不连续文件，只返回 1 组参数。没有仔细研究错在哪里。
3.  从文件分配表判断连续性。这是快捷的方法。但是文件系统类型太多，增加代码过多。

权衡利弊，觉得增加一个参数较妥。当用户确认文件连续时，可以使用该参数，加快执行速度。
参数是    --continuou

chenall

对于0.4.6a的这个map检测流程我看得不是很明白.

请问一下0.4.6a执行blocklist_func,返回的主要信息是什么?有没有具体的流程也许可以再优化下,

个人认为使用一个额外的参数来解决不太好,对于用户来说能够不用参数就尽量不要使用.越简单越好.

mdyblog

2011yaya2007777 发表于 2014-12-25 20:39
几种方案：
1.  判断是否属于扇区序列。即便是，也不能简单跳过块列表函数。因为不连续的扇区序列也可以映 ...

1：
这个效果好啊！ 瞬间完成。
佩服！佩服！
终于看到了希望——就在眼前。


看来问题接近完美了。

2：
可以直接通词法分析， 就能判断扇区序列是否连续。
这样相对扇区序列空间大小的时间复杂度为 O(0).

(hd0,0)2+20,33+5,87+300
这个肯定是不连续的。

(hd0,0)2+2000
这个肯定是连续的。

下面也是连续的，map其实不考虑， map只能扇区对齐
(hd0)800+100,51100     //不能map

1） 最简单的方法， 就数逗号。没有逗号就是直接当连续的。有逗号走原来的流程。
对我们中国人来说，这个完全够用了。（代价也最小）。
if (逗号数=0) 就是连续的。(走--continuou流程)
else               就是不连续的。 (走原来的流程)

2）复杂点(完善点——完美主义者)。
执行一次排序，合并，
再:
if (分片数=1) 就是连续的。(走--continuou流程)
else               就是不连续的。  (走原来的流程)
//适用的角度，意义不大。但是作为程序员，感觉心里舒服点。

yaya好样的，加油哦！

2011yaya2007777

对于0.4.6a的这个map检测流程我看得不是很明白.

其实我也不太明白，尤其是扇区序列。
在 map 中执行 blocklist_func，原来 0.4.5c 是读文件的首扇区及末扇区，用来确定文件的首扇区（start_sector）和扇区数（sector_count）。
但是后面紧接着 disk_read_start_sector_func() 将重新设置start_sector和sector_count。因此，对于 0.4.5c，
if (mem == -1ULL)
{
......
}
可以删除。

对于 0.4.6a，此处是用来确定文件的连续性，获得各段文件起始及扇区数。
前面描述的不对，确定连续性也不是 1 扇区 1 扇区地读。fat，iso9660 是最大 4 扇区，ntfs 是最大 8 扇区。

个人认为使用一个额外的参数来解决不太好,对于用户来说能够不用参数就尽量不要使用.越简单越好.

那就采用：如果是连续的扇区序列，则跳过连续性检查。
我已经上传了一个补丁，打在我的分支，不知这么没有进入你的主干。如果可能的话，请帮忙撤销，或者告诉我如何撤销。

chenall

发现没有同步到过来,比较奇怪,

不过这样也好,省得麻烦.

一般原则上不建议撤销,特别是已经上传同步的代码.

不过目前看来没有同步过来,你自己可以撤销

撤销的话就是强制更新

具体操作方法
首先在本地分支恢复到上一个版本(下面的dabcf1d就是版本ID).
git reset dabcf1d

注: 以上只是恢复log,会保留代码的改动.如果不需要保留可以加参数--hard即
git reset --hard dabcf1d
然后修改重新更新
git commit xxxxx

最后要更新源码时需要加-f进行强制覆盖更新.
git push -f

chenall

另外好像原来的blocklist_func就是可以直接返回块列表的吧?

只不过0.4.5c的map只是简单检测是否连续,这样速度很快.

0.4.6a应该只需要稍微修改一下就行了,我看你增加了一个query_block_entries=4的类型.

我觉得可以继续使用0.4.5的方式,只需要修改blocklist_func让它检测所有块就行了.

mdyblog

chenall 发表于 2014-12-26 16:54
另外好像原来的blocklist_func就是可以直接返回块列表的吧?

只不过0.4.5c的map只是简单检测是否连续,这 ...

大哥们啊， 能先放出个版本吗？ 能自动判读的。（不要--continuou，这个开关迟早会被淘汰）
等米下锅啊！

chenall

抽了一些时间改了一个版本,先试试看有没有什么问题...

yaya也可以检查一下,看看我逻辑是否有问题.

PS: 可以尽量测试看看能发现多少问题(尽可能的多测试,比如单文件块,多文件块,还有扇区块之类的),我要等明天10点之后才有时间继续处理.