b***i 发帖数: 3043 | 1 一个2GB的CF卡有问题。FAT16,每个扇区512字节。要求比较发现哪些扇区相同。现在
暂时规定只看最开始的32字节是否相同。整个扇区都是0的则不考虑。
比如扇区342344和6552455都是以hh:mm 2013/09/15, 12:34:00, 34.15, 203/09/15,
12:34:05, 58.18
开始,则认为有重复。目前只比较扇区开始的32字节。一个65536 x 64个扇区。 | s*****n 发帖数: 5488 | 2 问题是什么?
用什么语言?
你定义一个header obj.然后定义一个equals, hashcode.
然后hash一下,比较好了。
难点在哪里?performance?算法?
【在 b***i 的大作中提到】 : 一个2GB的CF卡有问题。FAT16,每个扇区512字节。要求比较发现哪些扇区相同。现在 : 暂时规定只看最开始的32字节是否相同。整个扇区都是0的则不考虑。 : 比如扇区342344和6552455都是以hh:mm 2013/09/15, 12:34:00, 34.15, 203/09/15, : 12:34:05, 58.18 : 开始,则认为有重复。目前只比较扇区开始的32字节。一个65536 x 64个扇区。
| b***i 发帖数: 3043 | 3 用什么无所谓,关键是算法.比如说用C#好了,反正肯定先把2GB读入内存的。或者就把
每个扇区前32个字节保存。
之后怎么办?怎么hash?大概多长时间能扫描一遍?一共64*65536个扇区,就是4M个
hash。是随便做个随机数计算吗? hash用多少bit?32?
【在 s*****n 的大作中提到】 : 问题是什么? : 用什么语言? : 你定义一个header obj.然后定义一个equals, hashcode. : 然后hash一下,比较好了。 : 难点在哪里?performance?算法?
| X****r 发帖数: 3557 | 4 实际的解决方案是:别用有问题的CF卡。
【在 b***i 的大作中提到】 : 一个2GB的CF卡有问题。FAT16,每个扇区512字节。要求比较发现哪些扇区相同。现在 : 暂时规定只看最开始的32字节是否相同。整个扇区都是0的则不考虑。 : 比如扇区342344和6552455都是以hh:mm 2013/09/15, 12:34:00, 34.15, 203/09/15, : 12:34:05, 58.18 : 开始,则认为有重复。目前只比较扇区开始的32字节。一个65536 x 64个扇区。
| b***i 发帖数: 3043 | 5 这个真的是实际的问题。现在的目标是测试CF卡是否有问题,不是面试题。而且,也可
能不是硬件问题,也许是软件问题?看看有没有知道。
这个固件用的是1999年SanDisk的API,Compact Flash。不知道当年有没有现在的wear
leveling,这个固件当年是否做这些还不清楚,还要看一下资料。
CF卡里面,一个page是512字节,可以写一次,随便读,继续写需要erase,一次erase
一个block既64个page。这是硬件层的。固件Api呢,是FAT16,每个文件必须占用64个
扇区为一个cluster,一个扇区512字节。这个层,我不清楚是否知道CF不能写一个扇区
多次,假设它不知道。软件层写文件的时候,每5秒更新一次,大约20个字节,这样,
假如api那里缓冲够了,就写入CF,而CF负责新找一个sector,把原来的标记为不可用,
这样可以延长寿命。每次写文件的时候,文件在目录表的记录也需要修改,文件长度和
时间要被改。
这个过程出现了问题。现在看到两个CF卡,其中某个目录里,文件的内容不仅出现在文
件的cluster那里,也出现在了文件目录表,覆盖了个文件记录所在的扇区。只是一个
扇区被覆盖了,同一个cluster前面的扇区挺好,就是说同一个目录前面几个(比如32
个)文件是正查功能的。这个我在想是软件/固件问题,还是硬件CF里面的软件问题,
都有可能。一个stack overflow, 指针搞错,就把文件的buffer给了目录表的buffer,
造成目录出错。
所以,现在要找到几百个CF卡,然后看我们的软件能把多少个CF卡搞出问题。
【在 X****r 的大作中提到】 : 实际的解决方案是:别用有问题的CF卡。
| b***i 发帖数: 3043 | 6 最新进展,这个不是CF本身问题,是嵌入式软件问题。
发现的问题:文件内容被覆盖到文件目录去,该文件的目录项(以及附近同一个扇区的
所有目录项)消失,从而,api不能继续写入文件。
原来的嵌入式软件执行一个无限循环,里面做所有的事情。后来用了第三方的TCP/IP的
软件,估计使用了一些函数指针把CF的api记录了。这样我觉得可能ftp的时候,第三方
的软件直接呼叫了CF API,这些api都是不可重入的,里面有全局变量,比如纪录当前
正在写哪个缓冲区。这个绝对可以造成同一个内容被写入不同区域。我看这个探测CF里
面重复区域的任务不用做了,下面的任务就是确定这个原因,然后需要手写semaphore
级别的东西,因为原来没有使用操作系统,无法实现这些功能。
【在 b***i 的大作中提到】 : 一个2GB的CF卡有问题。FAT16,每个扇区512字节。要求比较发现哪些扇区相同。现在 : 暂时规定只看最开始的32字节是否相同。整个扇区都是0的则不考虑。 : 比如扇区342344和6552455都是以hh:mm 2013/09/15, 12:34:00, 34.15, 203/09/15, : 12:34:05, 58.18 : 开始,则认为有重复。目前只比较扇区开始的32字节。一个65536 x 64个扇区。
|
|