linux无效设备,linux – 如何在闪存设备上调试此FS错误？

在位和字节级别上实际发生的是文件分配表的4个字节(或更多)已被0x00字节覆盖.

我将简要解释文件分配表的工作原理.它可以看作一个数组,其值是同一个数组的索引.因此,如果我们知道文件的第一个簇号是i,那么下一个簇号是fat [i],之后的下一个是fat [fat [i]],依此类推. (这稍微简化了一下).为了表示到达链的末尾,使用特殊的EOC值而不是有效的簇号.

要从磁盘读取FAT文件,需要按顺序存储文件所在的簇编号.目录条目给出第一个簇号(i).其余的可以在链脂[i],脂肪[fat [i]]等之后找到,直到遇到EOC值.然后,这是一个简单的计算,从群集号中获取每个群集的磁盘位置,将每个群集读入内存并连接它们.

fat_get_cluster：在这样的链之后发生when the value 0x00000000 is found无效的簇链错误.这不应该发生.它应该是新的有效簇编号或EOC值.发生这种情况时,不能再读取该文件,因为无法进一步跟踪链. (0x00000000值用于将群集标记为空闲.群集0从不用于存储数据,因此没有歧义)

你的情况可能是一个特殊情况,因为i_pos给出为0.当我收到这条消息时,这是一个很大的数字. Kernel source说：

loff_t i_pos; /* on-disk position of directory entry or 0 */

所以i_pos不是簇号,而是磁盘上的位置.当它为零时它意味着什么,我不知道.

编辑：关于可能导致它的原因,我只能推测,但这里有一些可能性：

>一个FAT驱动程序错误.

> Cosmic rays

>病毒或other malicious software.

>也许如果两个程序/驱动程序由于某种原因同时写入和读取同一个FAT,它们可能会相互绊倒.不知道是否可能.

>在错误的时刻断电.闪存驱动器必须在写入更改之前将块清零,因此理论上在擦除后立即关闭电源会导致此结果.虽然有大多数驱动器都有failsafes阻止这种情况.

>用户错误或破坏(例如dd if = / dev / zero = = dev / sda1 bs = 512 count = 1 seek = 32 – 请勿在家中尝试！)

FAT文件系统驱动程序实际上保留了两个FAT表是最新的冗余,第二个是@L_403_6@.检查它们是否相同可能会提供可能发生的事情的线索.如果它们只是破坏集群链的价值不同,那么我认为它会更有可能以某种形式直接篡改,因为至少有1和3应该“正常”地完成工作.

但是,对我来说,大多数现代驱动程序都会将整个FAT表保留在RAM中并将更改的部分写回驱动器副本.因此,即使一次存在差异,也可能在正常使用期间快速且无声地“固定”.请注意,这只是一个有根据的猜测.

最后,如果没有关于具体情况的进一步信息,很难确切地知道,即便如此,也可能是猜测.理想的情况是,如果你可以可靠地重现问题.然后,我将比较“之前”和“之后”FAT表(以及FAT标题),以确切了解已更改的内容和内容,查找位置和更改内容的提示.