Hi there!
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?
Any comments…
Any suggestions…
Please help.
Thanks
Mac
Did you take note of this from the docs?
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.
Hi bren,
Thanks for your reply.
I have not opened any file from that parition while running “chkfsys”.
I am doing clean shutdown every time. There is no abrupt shutdown at all. My application will close all the files opened before going for shutdown.
The CF access time depends on the manufacturer and CF type (NOR, NAND)? Any idea?
I have taken care all pre-requisits to use “chkfsys”… I hope…
Where the new bitmap image (by chkfsys) will be created? in RAM? in Flash?
-Mac
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.
Let me see what is happening by removing -u option.
Thanks
-Mac