We are using chkfsys command in our boot script with the options -ruPq. We have 4 paritions in the CF (Nand flash). chkfsys is run in the fourth parition before mounting it. Find the command:
“chkfsys -ruPq /dev/hd0t8”
We have a feeling that chkfsys with the specified options slows down the CF access . A set of activities which took 1.7 seconds initialiiy, started taking 2.6 and more after ~100 reboots (i.e.) after running the chkfsys 100 times.
And…after ~100 times, suddenly chkfsys throwed an error. “chkfsys cannot be run on non-Qnx file system” and the 4th parition got corrupted. The whole purpose of using chkfsys went waste .
Why chkfsys slows down the CF access?
What changed the QNX file system to non-QNX file system?
The chkfsys utility should be used only when the filesystem is stable. There should be NO files open for writing when
chkfsys is running. If you make any repairs, remount the filesystem by slaying and restarting the disk driver.
Another thing to check regarding the file system corruption,
Are you doing a clean shutdown or an abrupt power down? could there be files left open?
What data is being written to the flash?
If you are writing lots of data, could the disk be fragmenting?
Chkfsys will not, or at least I doubt it is, causing the slow down, it is more likely to be something you are doing to the disk, i.e. bashing it with data.
I don’t know what is going wrong. It is unlikely that chkfsys caused the flash corruption. As far as I know, it only writes sectors if it finds something wrong. I’d suggest leaving off the -u option. If you don’t trust the file system, then why trust chkfsys? You might also want to temporarily remove the -q option until you know what is going on.
Chkfsys creates a new bitmap in ram and then compares it with the disk version.
. A set of activities which took 1.7 seconds initialiiy, started taking 2.6 and more after ~100 reboots (i.e.) after running the chkfsys 100 times.