File Systems (ext2, ETFS) & Data Acquisition

Hello,

I have a few questions about setting up filesystems in qnx, especially ext2 and ETFS.

First of all my problem: I have a pc (pc104) with a 32GB ssd drive (solid state disk). I run qnx on the machine and log data with a high data rate on a second partion (same disk). In my special case it is possible, that there is a power-off or a reset without closing the file correctly. When this happens, all data in the (write-) buffer is lost an I am not able to read the logfile. But I want to do this :slight_smile:

Now, my questions:

  1. How can I set up a synchronous I/O, so that the write buffer to the disk is disabled?

  2. Is it possible to format an ext2 partition with qnx? Until now I found no included tool to do that.

  3. For the second partion (first one is a normal qnx4 partition) I’ve tried to set up an ETFS Filesystem using the flashctl command. This seems to be a better solution than qnx4- or ext2-filesystem because the ssd-drive is NAND based. But it never worked :frowning:
    When I use commands as written in the utilities reference nothing happens. I’ve also tried to use fdisk to create a partition an then using flashctl to format the partion. Then I get an error message “can’t erase partiton”.
    So what must I do to get this ETFS Filesystem working? :confused:

Hope somebody can help me?

Regards,
CGP

Check the commit option of devb-eide (io-blk) if you set commit to high everything becomes synchronous. You also have to make sure the write buffer in the SSD is disable, don’t remember what the option is to do that.

Don’t know but stay away from ext2. As the documentation says ext2 requires special tools to recover from a power failure and these tools aren’t available under QNX6

SSD drive (assuming IDE/SATA) have their own logic to deal with the NAND layout, wear leaveling and so forth. Hence the fact that the device is NAND based is totaly irrelevent with the usage of ETFS since SSD driver looks like a normal HD… That being said it could be more reliable then fs-qnx4. Can’t help you with ETFS, never really used it.

QNX6.4 ( alpha ) has a new filesystem fs-qnx6 that aims at improving reliability.

My major problem is that I want to read a datafile, that isn’t correctly closed (because of an accidental power-off). So the data in this file exists somewhere on the disk, but I can’t read them.
I thought, that maybe another filesystem could solve this problem. That’s why intentionally ETFS was choosen.
Maybe there is a simple method or a work-around to solve this problem?

About ETFS:
There is not so much information about this filesystem. So far what I found out:

  • Max. filesize 32kb, max number of files: 4096 → means one partition can be 128MB max.
  • To create a partition you have to use the flashctl utility, this interacts with the flashdriver. So your raw partition has to be detected as a flash device, but this is not the case when you use a ssd drive.
  • To start the flashdriver manually the physical address and the size of the flash is needed, this is also a problem when using a partition on a ssd.

If these information is true, I could suggest why it doesn’t work on my system :frowning:

If the data is on the disk a chkfsys run at boot time should recover the data. However it’s possible the data was not committed to the disk.

ETFS is intented for direct access to flash hardware which is not your case so it makes sense. Check my original reply for suggestion. You might also modify your program to open the file with O_DSYNC flag.

Additional advice to minimize the effect of accidental power-off:

  1. When initializing the file system, use dinit -i blocks, this will prevent writing to the .inodes file at runtime
  2. Immediately following the dinit, make a “.fillerâ€

[quote=“ysinitsky”]

  1. Immediately following the dinit, make a “.fillerâ€

I write 10 files parallel with 200Hz, they’re only including sensor data. The files are writen on an extra partition. On this partition is nothing else except the .inodes, .boot files and this stuff.
To disable the updating of the .inodes file sounds good an is probably advantageous for my special case. But what are the disadvantages when I’m doing that?
The sense of the .filler file isn’t clear for me.