支持含有碎片的文件仿真

mdyblog

chenall 发表于 2014-12-26 17:50
抽了一些时间改了一个版本,先试试看有没有什么问题...

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

这个还是慢。 10G需要50秒。


--continuou不支持了。


盼啊---盼啊---

chenall

可以先测试一下目前这样子会不会有问题.

上面的修改主要是让0.4.6a的这些代码和0.4.5c保持大体一致.

明天再针对块文件(block file)优化一下,,也就是(hdx,y)aaaa+bbbb这类的块文件.

1. 首先用0.4.5c的方法判断文件是否连续的,如果是的话就直接返回了.(对于blockfile和普通文件都很快)
2. 如果不是连续的文件的话就分两种情况处理
   对于block文件,根据块列表来处理,这样很快.
   对于普通文件,目前没有什么很好的方案还是使用老方案,一扇区一扇区读过去.

chenall

发现几乎所有的文件系统最终都是调用rawread函数来读的..

也许可以在rawread函数上动些手脚,这样子不用管什么文件系统应该都可以通用.

具体的明天再试验一下.

mdyblog

chenall 发表于 2014-12-26 20:44
可以先测试一下目前这样子会不会有问题.

上面的修改主要是让0.4.6a的这些代码和0.4.5c保持大体一致.

>>对于普通文件,目前没有什么很好的方案还是使用老方案,一扇区一扇区读过去.
不是有文件分配表吗。
一般是分析分配表，就知道文件布局，也就知道连续性，也获得扇区列表。
这些算法都是或接近O(0)的算法。
如果文件和少碎片，就是O(0)。
如果全是碎片，那就是O(n).

用来map的文件，一般是连续的，（或基本是连续的，就几个分段）。
对巨大的文件， 这种算法实际也是O(n)，但是极大缩小了比例因子。
文件分配表的1扇区，对应许多个节点信息。1个节点信息对应许多个文件扇区。
如果磁盘整理好了，由于比例因子极小， 一般也是不到1秒。

----
我想，目前的设计，本来就是分析 文件分配表吧。
否则， block命令没那么快。读完一个巨大的文件， 时间那可老长了！！！

chenall

使用上面的方案实验了一下,大家可以对比测试一下新旧版本的使用情况,如果我的逻辑和算法正确的话应该是不会有什么问题.

可能会影响到map的准确性,先上传上来测试一段时间.

这个改动对于blocklist命令进行了优化,特别是对于大文件效果更明显.

使用这个版本map一个大文件,一般情况下都可以瞬间完成.使用blocklist命令查看文件的块列表同样的速度飞快.

chenall

mdyblog 发表于 2014-12-27 09:31
>>对于普通文件,目前没有什么很好的方案还是使用老方案,一扇区一扇区读过去.
不是有文件分配表吗。
...

之前的设计不是分析文件分配表的,就像前面yaya所说的一样,如果按照文件分配表那当然快了,但是需要针对每个文件系统,很麻烦.

0.4.5c的情况
执行blocklist会一个扇区块一个扇区块读(没有真的读),然后最终得到块列表.
map命令调用的blocklist命令只读首尾扇区,然后进行判断是不是一整个块,这样速度很快.

0.4.6a完全是一个扇区一个扇区读的,如果文件很大的话需要很大的循环才能完成,所以就造成了上面的10G分区需要50秒.

mdyblog

chenall 发表于 2014-12-27 09:34
使用上面的方案实验了一下,大家可以对比测试一下新旧版本的使用情况,如果我的逻辑和算法正确的话应该是不会 ...

1：瞬间完成，牛！



2：
》》可能会影响到map的准确性,先上传上来测试一段时间.
难道 获得是扇区序列可能不准吗？ 那可要命啊。

chenall

mdyblog 发表于 2014-12-27 10:25
1：瞬间完成，牛！

因为改变了blocklist的计算方法,理论上是没有什么问题,需要多多测试而已

这个不只是针对(hd0)xx+y的,而是针对所有类型文件的,包括(hd0,1)/100G.VHD这种情况.

测试的话主要是看blocklist命令返回的信息和旧版的是否一致.一样的话就没有什么问题了.

我自己测试了一下都是一样的.

可以用blocklist命令对比一下新旧版本,看有没有什么区别.

mdyblog

chenall 发表于 2014-12-27 10:33
因为改变了blocklist的计算方法,理论上是没有什么问题,需要多多测试而已

这个不只是针对(hd0)xx+y的 ...

》》因为改变了blocklist的计算方法,理论上是没有什么问题,需要多多测试而已
哦。
不是原理上的漏洞，那就好。——不是"明知有问题，装作没看见。"

即使有问题，那也只能算作BUG——慢慢改吧——BUG是改不完的。
---------
这么说，这基本上是个发行版本了？！

chenall

没什么问题的话就是差不多这样子了

mdyblog

chenall 发表于 2014-12-27 11:04
没什么问题的话就是差不多这样子了

网上版本1227，正常，瞬间，如图：

chenall

这个版本和前面的代码是一样的,没有修改..

0.4.5c的暂时还没有修改,0.4.5c只影响blocklist命令,map命令影响不是很大,以后再看情况打是否要打这个补丁进去.

2011yaya2007777

关于变量 long query_block_entries（查询块项） 的探讨：

0.4.5c：初始化=0; 外部3处测试连续性设置=-1；函数返回1=连续，2=不连续，3=压缩文件认为不连续，0=程序失败（撤销请求‘-1’，回归0）。
0.4.6a：初始化=0; 外部3处测试连续性并且获取分段参数设置=-1；函数返回 blklst_num_entries（块列表项数=0～n），3=压缩文件，-1=程序失败。

disk_read_blocklist_func 函数是根据 query_block_entries 变量判断：
0.4.5c： >=0，是命令行调用，需测试文件全部长度，并打印信息； <0，是 G4D 内部调用，仅判断连续性，只测试文件首扇区及末扇区，不打印信息。
0.4.6a： >=0，是命令行调用，需测试文件全部长度，并打印信息； <0，是 G4D 内部调用，获取分段参数，需测试文件全部长度，不打印信息。
因此，程序失败时返回 ‘-1’ 不妥，应当撤销请求 ‘-1’，回归0。否则紧接命令行调用时，会出错。
另外返回 3 也没有意义，并且会被错误认为 blklst_num_entries=3。

发现 1 个 bug：
执行    blocklist (hd0)+0x20000000
返回    (hd0)
错误定位在

1. blocklist_func (char *arg, int flags)
   
2. {
   
3.   char *dummy = NULL;
   
4.   int err, i;

复制代码

应当是

1. blocklist_func (char *arg, int flags)
   
2. {
   
3.    char *dummy = NULL;
   
4.   int i;
   
5.   unsigned long long err = 0;

复制代码

不点

你们做这个工作很有效率，很棒，我不再参与了。究竟该怎么做，你们研究着办。

贯通 DOS 与 grub4dos，可能是我做的最后一个工作了。今后我不再参与 grub4dos 的开发了。

通报一下，让大家知道我的情况。

sunsea

mdyblog 发表于 2014-12-27 09:31
>>对于普通文件,目前没有什么很好的方案还是使用老方案,一扇区一扇区读过去.
不是有文件分配表吗。
...

常数时间复杂度是O(1)吧。。。

查文件分配表是个好方法。但是以后每添加一个文件系统就得多写一段代码了。

纠正以上:可以从读文件的算法里抄一下代码，稍微改动一下就行。（读文件貌似已经解决碎片问题了）

sunsea

chenall 发表于 2014-12-27 09:38
之前的设计不是分析文件分配表的,就像前面yaya所说的一样,如果按照文件分配表那当然快了,但是需要针对 ...

再不行浪费点拓展内存，把所有访问次数大于5次的磁盘的文件分配表什么的放进内存（反正现在内存大了，拓展内存按照srtalf教程的说法64M以下保留，那可以浪费了），再不行压缩存储

mdyblog

sunsea 发表于 2014-12-30 19:51
常数时间复杂度是O(1)吧。。。

查文件分配表是个好方法。但是以后每添加一个文件系统就得多写一段代码 ...

>>查文件分配表是个好方法。但是以后每添加一个文件系统就得多写一段代码了。
据我所知。
查文件分配表 是唯一的方法。
不查 文件分配表， 你知道文件保存在磁盘的哪些扇区？
对于文件系统，只能用这种方法。

现在， 可能底层函数，封装了查文件分配表这个功能。所以给人一个错觉，没有查文件分配表。实际是查了。

mdyblog

sunsea 发表于 2014-12-30 19:55
再不行浪费点拓展内存，把所有访问次数大于5次的磁盘的文件分配表什么的放进内存（反正现在内存大了，拓 ...

这个要小心了。
grub4dos 和 dos /window/Linux等正常使用的OS不同。
后者，后者文件系统的使用寿命很长，使用越长，缓存节省的时间月多，也有效。
但是，缓存本身也要浪费时间。对于文件系统，这个被无数次的方分分担了，忽略不计。
但是，grub4dos 的主要功能是启动一下，很多数据，不会多次访问。遮掩，缓存效果几乎没有了，反倒试过负担。

chenall

目前0.4.6a最新版的,blocklist就是基于底层,和文件系统无关,
但是实际上,所有的文件系统都是通过这个底层来读取文件内容的,所以变相的就相当于一劳永逸的解决了这个问题.
大家可以测试一下,不管任何文件系统,使用0.4.6a总是可以很快速地得到分件分配表.

另外我最近比较忙,估计一个星期之后才过再过来看看.

2011yaya2007777

又发现 1 个 bug：
执行：blocklist (md)+0xffffffff
返回：(md)0+-1
错误定位于：

1. diff --git stage2/builtins.c stage2/builtins.c
   
2. @@ -420,7 +421,7 @@ blocklist_func (char *arg, int flags)
   
3.    if (blklst_num_sectors > 0)
   
4.      {
   
5.        if (query_block_entries >= 0)
   
6. -        grub_printf ("%s%ld+%d", (blklst_num_entries ? "," : ""),
   
7. +        grub_printf ("%s%ld+%ld", (blklst_num_entries ? "," : ""),
   
8.                  (unsigned long long)(blklst_start_sector - part_start), blklst_num_sectors);
   
9.        else if (blklst_num_entries < DRIVE_MAP_FRAGMENT)
   
10.         {

复制代码

2011niumao

2011yaya2007777 发表于 2014-12-31 20:30
又发现 1 个 bug：
执行：blocklist (md)+0xffffffff
返回：(md)0+-1

好像对于有碎片文件的仿真变坏了.
我有两个vhd文件,使用原来2014-11-27的0.46a版本可以启动.
但是2014-12-31 的 0.46a不能启动.

2011niumao

2011niumao 发表于 2015-1-1 11:47
好像对于有碎片文件的仿真变坏了.
我有两个vhd文件,使用原来2014-11-27的0.46a版本可以启动.
但是201 ...

进一步对各个版本测试结果:

0.46a 2014-12-26正常.可以引导. 0.45c 2014-12-24也正常引导.
0.46a 2014-12-27就和2014-12-31一样出现上面图片所示错误.

应该是2014-12-27 0.46a 开始出现错误的.

mdyblog

报告20141227-0.46a一个问题：

如下的菜单中用grub.exe.

title  SSHYDOS     kernel  (hd0,0)/grub/grub.exe --config-file="          debug off;clear;root           (hd0,0);command /IMG/SSHYDOS.IMG.SH || configfile /IMG/SSHYDOS.IMG.LST   "

上面优先启动 /IMG/SSHYDOS.IMG.SH
其次/IMG/SSHYDOS.IMG.LST


测试中没有/IMG/SSHYDOS.IMG.SH， 只有 /IMG/SSHYDOS.IMG.LST
其中的"debug off"没有启到屏蔽错误消息的作用。
会打印出 没有 /IMG/SSHYDOS.IMG.SH。


1206版没这个问题。

1227 难道不是接着 紧前的 版本修改的。
按说1227的修改，和这些问题没有一点关系。
是不是， 直接回到很早的版本，或者 版本管理出来问题？

2011yaya2007777

Re 2011niumao :
请测试一下官网的 0.4.6a 24/25/27 版本，准确定位。

会打印出 没有 /IMG/SSHYDOS.IMG.SH。

不点要求，命令行没有成功执行的命令，应打印出错信息，以便提醒操作者。chenall  按此做了更改。

mdyblog

2011yaya2007777 发表于 2015-1-2 09:06
>>会打印出 没有 /IMG/SSHYDOS.IMG.SH。
>不点要求，命令行没有成功执行的命令，应打印出错信息，以便提醒操作者。chenall  按此做了更改。

--config-file="
应当 当作内置菜单一样看待，这里不是“人机互动”的那种“命令行”场合。
这种提示只有 “人机互动”的那种“命令行”场合 才有意义。
否则，反倒是让人憋的难受。

还有 脚本 中也一样，debug off后应当统统不提示，而是通过错误码传递错误信息。

不管怎么想的， 总要提供一种手段，让人能屏蔽所有出错信息。（ > nul 不算， 因为连echo的正常输出都屏蔽了）

还有，突然让debug off 部分失效，变得不兼容， 以前开发的代码，不再是原来的效果。
冒出那么多出错信息，让人还以为软件运行出错了。
以前开发的时候，是在【debug off 】能完全屏蔽出错提示的前提保证先开发的。

如果一切“保证”都不能作为“保证”，那么怎么用来开发？没有保证的前提，开发是无法开展的。
1+1不能保证等于2，算术无法开展的。

不点

Fatal 错误不受 debug off 的影响，应该总是显示出来。Fatal 错误直接用 printf 来显示，不带 if (debug) 之类的判断条件。

而一般的 Error 信息，似乎是可以用 debug off 来屏蔽的。不过我声明：我岁数大了，脑子不如以前好使了，也许我会弄错的。最近一两年我在编程方面已经犯了很多低级错误，以前也犯错，但似乎没这么严重。

究竟什么样的错误在什么样的场合显示出来，由 chenall 你们决定。

mdyblog

不点 发表于 2015-1-2 10:04
Fatal 错误不受 debug off 的影响，应该总是显示出来。Fatal 错误直接用 printf 来显示，不带 if (debug)  ...

1》 这种屏提示提示，只有 “人机互动”的那种“命令行”场合 才有意义。     非“人机互动”， 重要的出错提示，有代码自己echo出来。

2》不管怎么想的， 总要提供一种手段，让人能屏蔽所有出错信息。（ > nul 不算， 因为连echo的正常输出都屏蔽了）


3》尽量保证兼容性。
     新的功能用新的命令后开关。
      这样测能用来开发。
可以考虑加个 debug foff
就是你们说的，那些Faltal总是打印出来。

不点

2011yaya2007777 发表于 2015-1-2 09:06
Re 2011niumao :
请测试一下官网的 0.4.6a 24/25/27 版本，准确定位。

我作为一个 bug 报告者，发现了 bug，并加以报告。chenall 对 bug 报告进行了处理。

2011niumao

2011yaya2007777 发表于 2015-1-2 09:06
Re 2011niumao :
请测试一下官网的 0.4.6a 24/25/27 版本，准确定位。

官网的 0.46a 24/25都正常引导.27不行.出现错误.

不点

mdyblog 发表于 2015-1-2 10:10
1》 这种屏提示提示，只有 “人机互动”的那种“命令行”场合 才有意义。     非“人机互动”， 重要的出 ...

我们都是建议者，所提出的建议，经由开发维护者权衡以后，作出处理的决定。

这些小问题，又不涉及巨头的硬件封杀，我相信开发者们完全可以处理好。

我们只要把 bug 报告写清楚，把该说的话说完，就行了。