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个扇区。
|
|
