File system corruption with power safe filesystem

Hi,

Has anyone experienced with file system corruption with power safe file system?

Is there any work arounds to handle it?

Regards
Sheran

I don’t have much experience using the power safe file system, however I have two comments.

  1. I believe that the guarantee of the file system is that it will stay coherent. That is an update will either complete or not, but it will not leave a corrupt file. It is however possible that the file system could lose blocks during an update, a more subtle form of corruption.

  2. I also recall that there are certain requirements on the hardware for it to function properly and provide the above guarantee. It must be possible to do a write and know that the data has gone to disk. This might seem obvious, but todays hard drives use caches to improve performance. In some cases a drive could receive data, report that a write was successful, but subsequently lose that data in a cache during a power failure.

Do you think CFast cards (SLC flash) implement such caches as the hard drives?

That’s a good question. I don’t really know the answer. They are SATA drives. I’m sure SATA has the interface in which a driver can request that the cached data be sent to disk. Even though CFast cards are silicon, I believe they must have a cache. There’s some weird internal stuff with CFast and Compact Flash cards that allows even wearing of sectors. Whether this interface works properly or not might depend on the brand and model.

I have an associate who knows more about them, and I will ask and report back if I learn anything new. You could also check with the manufacturers website.

My associate didn’t have anything to add, however here’s an interesting link I found with Google:

dpreview.com/news/330779707 … -x-mark-ii

Seems like it might be a cache flushing problem.

Thanks for the information. when starting the block driver i tried “qnx6 sync=mandatory” and it mounts my CFast card. Guess then my CFast card suports SYNC as required by fs-qnx6.so. Not sure how this corruption can be avoided.

I think you might want to try another brand. We have 4000 units in the field that I know people just turn on and off whenever they like. The only time I recall getting corruption was when we accidentally updated our file system and then immediately rebooted before the QNX file system cache was flushed.

I concur with Mitchell. I have had for some years now a few dozen small QNX6 embedded units out in the field that in some cases work with Windows machines. The QNX6 units use the QNX6 file system on a Compact Flash card as well as a USB thumbdrive (FAT32). The Windoze boxes have NTFS on their internal CF cards (no rotating drives in these systems).

The users are in the habit of simply switching everything off - they simply pull the power cord (literally).

I have never had a QNX6 (or QNX4 for that matter) file system corrupt with such treatment but I have had on numerous occasions had the Windoze units sent back to me for recovery. I now charge for this “service”.

But I do know the caching “problem” very well - back in the QNX4 days with the floppy driver (remember them???) One had to ensure the light was out after a write before removing the disk.

Geoff.

“Accidently updated filesystem” meaning? like powered off when writing to a file?

Our systems automatically go out looking for an update. The update is a package that gets downloaded, de-archived and installed. After the installation there is a custom install script that comes with the package that is run. This script copied some files around and then immediately did a reboot before the data was flushed to disk.

This was software corruption to the disk, not hardware corruption on the CFAST, as it was never powered off.

I do have a shutdown. but have a sync command before shutdown.

chkqnx6fs reports corruption only in etc/system/trap/ directory. Does it actually mean, only that folder is corrupted? and corruption happened when that folder is getting updated?

[/etc/system/enum/devices/usb/]
[/etc/system/enum/include/]
[/etc/system/helpviewer/]
[/etc/system/trap/]
!! /etc/system/trap/: invalid name for . or … !!
!! /etc/system/trap/: invalid ino for . or … !!
!! /etc/system/trap/: invalid inode in directory entry !!
!! /etc/system/trap/: invalid filename length !!
!! Inode#1769104755: invalid ino !!
!! /etc/system/trap/: invalid name for . or … !!
!! /etc/system/trap/: invalid ino for . or … !!
!! /etc/system/trap/: invalid inode in directory entry !!
!! /etc/system/trap/: invalid filename length !!
!! Inode#1634493216: invalid ino !!
!! /etc/system/trap/: invalid inode in directory entry !!
!! /etc/system/trap/: invalid filename length !!
!! Inode#1986164083: invalid ino !!
[/etc/timezone/]
[/etc/openssl/]

I am suspicious of “sync”. If you an, doing an unmount on root and waiting for it to finish should be pretty reliable.

Does sync not take care of flushing everything to CFast card?

It’s supposed to. I recall situations in the past where it did not. I may be thinking of QNX 4, but I don’t recall. I’m skeptical.

I should point out that sync only would work if nothing running is writing to a file. Otherwise an instant after you run sync, there could be unflushed buffers again.