fsck的一个场景

添加的一个vfat文件系统，概率性发现有些板子开机起来后发现多了FSCK0000.REC、FSCK0001.REC…FSCK0023.REC这些文件。

REC文件

这些命名以FSCK开头，后缀为REC的是什么文件？

A REC file is a data recovery file created by fsck, a utility used to check the integrity of a file system in Unix and Unix-like operating systems. It contains a log of “inconsistencies” in a filesystem that were detected during an fsck check that can be analyzed by users to investigate issues in a file system. REC files are similar to .chk files created by the “CHKDSK” system tool for Windows.

The fsck tool is typically used in Unix-like operating systems, such as Linux, macOS, Free BSD. The utility typically runs during the bootup of the operating system to check the consistency of the filesystem. If the utility finds any issues, it logs them in one or more REC files to be analyzed.

When fsck creates REC files it names them as FSCK####.REC with the #### ascending from 0000 for each data recovery file created. For example, the first REC file is FSCK0000.REC, the second is FSCK0001.REC, the third is FSCK0002.REC, and so on.

REC files store data in plain text and can be opened with a text editor, such as Apple TextEdit or gedit. The files can also be deleted without affecting the performance of the system but they may be regenerated during the operating system bootup process.

NOTE: fsck is short for File System Consistency Check.

dosfstools

还好这个系统分区里面的其他文件看起来都正常，没有被损坏，如果文件系统损坏了，dosfstools这个工具可以帮助修复。

1. 下载

   $ git clone https://github.com/dosfstools/dosfstools.git

2. 编译

   $ ./autogen.sh
   $ ./configure
   $ make

   根目录产生一个fsck.fat文件。

交叉编译

但是要在Android平台上运行，需要交叉编译：

找到平台编kernel用的gcc工具，查看kernel根目录的.config文件，得到：

CONFIG_CROSS_COMPILE="asdk-linux-"

把asdk-linux-的实际路径，添加到环境变量：

$ export PATH=$PATH:/home/xtg1800/hk2851/kernel/system/tmp/toolchain/asdk-6.4.1-a55-EL-4.4-g2.26-a32nut-170810/bin

编译fsck.fat：

$ make CC=arm-linux-gnueabi-gcc

得到fsck.fat，将其拷贝到平台，chmod添加权限，但无法运行。

执行file命令：

$ file fsck.fat
fsck.fat: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=5500515d59327f7001948e5159d6158b2a37e840, with debug_info, not stripped

执行readelf命令：

$ readelf -d fsck.fat

得到如下信息：

Dynamic section at offset 0xaf18 contains 24 entries:
Tag        Type                         Name/Value
0x00000001 (NEEDED)                     Shared library: [libc.so.6]
0x0000000c (INIT)                       0x10af4
0x0000000d (FINI)                       0x185fc
0x00000019 (INIT_ARRAY)                 0x2af0c
0x0000001b (INIT_ARRAYSZ)               4 (bytes)
0x0000001a (FINI_ARRAY)                 0x2af10
0x0000001c (FINI_ARRAYSZ)               4 (bytes)
0x00000004 (HASH)                       0x101ac
0x00000005 (STRTAB)                     0x106d0
0x00000006 (SYMTAB)                     0x10330
0x0000000a (STRSZ)                      454 (bytes)
0x0000000b (SYMENT)                     16 (bytes)
0x00000015 (DEBUG)                      0x0
0x00000003 (PLTGOT)                     0x2b000
0x00000002 (PLTRELSZ)                   408 (bytes)
0x00000014 (PLTREL)                     REL
0x00000017 (JMPREL)                     0x1095c
0x00000011 (REL)                        0x1092c
0x00000012 (RELSZ)                      48 (bytes)
0x00000013 (RELENT)                     8 (bytes)
0x6ffffffe (VERNEED)                    0x1090c
0x6fffffff (VERNEEDNUM)                 1
0x6ffffff0 (VERSYM)                     0x10896
0x00000000 (NULL)                       0x0

依赖libc，是这个原因吗？

编译一个静态的fsck.fat试试：

$ make CC=arm-linux-gnueabi-gcc LDFLAGS=-static

file命令检查一下：

$ file fsck.fat
fsck.fat: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=a6a69c42911b5ca79702e813773a7e4ebf7e5eaf, with debug_info, not stripped

fsck.fat使用

将这个静态的fsck.fat拷贝到平台运行试试

$ umount /smarttv
$ fsck.fat -atv -w /dev/block/mmcblk0p17
fsck.fat 3.0.26 (2014-03-07)
CP437: Invalid argument
fsck.fat 3.0.26 (2014-03-07)
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "mkdosfs"
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
       512 bytes per cluster
         6 reserved sectors
First FAT starts at byte 3072 (sector 6)
         2 FATs, 32 bit entries
    516608 bytes per FAT (= 1009 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 1036288 (sector 2024)
    129048 data clusters (66072576 bytes)
16 sectors/track, 4 heads
         0 hidden sectors
    131072 sectors total
Checking for bad clusters.
Reclaiming unconnected clusters.
Checking free cluster summary.
/dev/block/mmcblk0p17: 62 files, 14665/129048 clusters
$
$
$ mount /dev/block/mmcblk0p17 /smarttv
$ ls smarttv/
FSCK0000.REC FSCK0006.REC FSCK0012.REC FSCK0018.REC common              
FSCK0001.REC FSCK0007.REC FSCK0013.REC FSCK0019.REC smarttv.json        
FSCK0002.REC FSCK0008.REC FSCK0014.REC FSCK0020.REC smarttv.json.backup 
FSCK0003.REC FSCK0009.REC FSCK0015.REC FSCK0021.REC 
FSCK0004.REC FSCK0010.REC FSCK0016.REC FSCK0022.REC 
FSCK0005.REC FSCK0011.REC FSCK0017.REC FSCK0023.REC
$

fsck.fat可以正常使用，但是REC文件还在，这个应该是留着修复文件系统损坏的。

详细用法：

$ fsck.vat
usage: fsck.fat [-aAbflrtvVwy] [-d path -d ...] [-u path -u ...]
            device
-a       automatically repair the filesystem
-A       toggle Atari filesystem format
-b       make read-only boot sector check
-c N     use DOS codepage N to decode short file names (default: 437)
-d path  drop that file
-f       salvage unused chains to files
-l       list path names
-n       no-op, check non-interactively without changing
-p       same as -a, for compat with other *fsck
-r       interactively repair the filesystem
-t       test for bad clusters
-u path  try to undelete that (non-directory) file
-v       verbose mode
-V       perform a verification pass
-w       write changes to disk immediately
-y       same as -a, for compat with other *fsck