JFS corrupt data recovery after power loss

[Altera_Forum]

In preparation for a Custom board I'm using the Cyclone II Eval board with the Compact Flash to record data.  

 I need a quick boot - which I've accomplished. (5-8 seconds)  The next step was what "fsck" will be the fastest to maintain my fast boot.   I know there will be power losses while I'm writing data and - The system can be running for 1 hour before the power is cycled and I've found with the NiosII running at 100 MHz  1. EXT3 "fsck" can take over 2 minutes !! 2. EXT4 "fsck" -- almost as bad 3. JFS "fsck" -- 30 seconds (which I can live with)  However, the data in the JFS file is CORRUPTED whereas with EXT3/4 the data is fine.  I've never used the JFS filesystem before so I'm wondering WHAT AM I DOING WRONG? Are there settings when I format? SHould I tune it in some way.  Thanks in advance.

[Altera_Forum]

O.K. I've finally found a link that says JFS is not reliable on the data (link and note below).  

So, can I speed up EXT3 fsck ? Below is the boot of what the scis and ata1 are doing for me - PIO0  scsi0 : pata_altera_cf ata1: PATA max PIO4 mmio cmd 0x6425040 ctl 0x6425078 irq 6 Command: ifconfig eth0 hw ether 00:22:15:CC:27:82 ata1.00: CFA: STI Flash 8.0.0, 01/17/07, max MWDMA2 ata1.00: 16190496 sectors, multi 0: LBA  ata1.00: configured for PIO0 ata1.00: configured for PIO0 ata1: EH complete scsi 0:0:0:0: Direct-Access ATA STI Flash 8.0.0 01/1 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 16190496 512-byte hardware sectors: (8.28 GB/7.71 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA  sda: sda1 sd 0:0:0:0: [sda] Attached SCSI removable disk   Or due to the fact that the Compact Flash is in configured for PIO0   *****************************************************************************************  http://www.linuxquestions.org/questions/linux-general-1/jfs-vs-xfs-vs-ext3-power-failure-492619/  note: JFS uses a journal to maintain consistency of metadata only. Thus, only consistency of metadata (and not actual file contents) can be assured in the case of improper shutdown. This is also the case for xfs and ReiserFS. Ext3, on the other hand, does support journaling of both metadata and data [5], though with a significant performance penalty, and not by default.   **********************************************************************************************  Thanks for ANY inputs !

[Altera_Forum]

I think that the journal recovery require a lot of read/write operations, so the fact that the card is in PIO0 mode must have a big negative impact on starting time. 

There are some compact flash controllers with UDMA support for the Nios platform, but none are free AFAIK.

[Altera_Forum]

It does not make sense to use a Flash file system with a compact flash card, as same performs the wear management internally and the file system can't do it as it does not know the page boundaries.  

 Using an FC in an environment without a battery, so that unexpected power fail is possible is very critical, as most FCs might trash all data (not only the recently stored) if power fails quite soon after a write access. The "quite soon" time is not specified anywhere buit it can be several seconds, as internal wear leveling might trigger a huge data moving operation.   I have been told that there are (rather expensive) "industrial" CF card that don't suffer from this, but I don't know any details.   The fact that ext3 needs an fschk suggests that something bad has happened internally in the card, as ext3 should just very quickly roll back its journal on restart when some write has failed.   -Michael

[Altera_Forum]

Thanks for the inputs. 

 @mschnell  I've used this scheme with a Cirrus ARM processor and you are correct that consistantly my boot time is 30 seconds with an "fsck" on ext3 Compact Flash (Industrial "expensive" - with UDMA). My scheme helps a lot - I get the data in "chuncks" and I "fsync" which is another key to using CF. So any recovery is 'minimal.'  The hardware/firmware engineer has designed power down hardware (to give me about 1.5 second to clean up and unmount) which we'll get the parts to next week and try out externally. The thing about our application is that our Flight Data recorder is in a avionics computer with limited real estate, etc.    @mschnell @daixiwen From all my tests I must conclude that the PIO0 is the "bottleneck" here.  The hardware/firmware engineer is going to see if he can "tweek" any of the Altera CF IP settings and get me an updated design to see if we can get any better.  The hardware/firmware engineer did mention to me that we can get a CF controller for $$, but our situation is always 'tight on $$'    Question - Do you know the names of the compact flash controllers with UDMA ?  And do they have Linux / uClinux drivers ?    Thanks 

[Altera_Forum]

I suppose it's quite easy to construct the DMA enabled hardware, but you will need to create a new Kernel driver for same. 

 -Michael

[Altera_Forum]

I've done many kernel drivers for our custom hardware (PCI and ARM embedded). I just worry about the time to do it (am I good enough to get it to work). 

 The hardware engineer is -- inquiring about a paid ATA-3 core for the NIOS-II.   I'll post info on whatever we do. May open a new post with an appropriate title about Compact Flash performance.   

[Altera_Forum]

If you want to be sure that the slow speed is due to the PIO0 interface, you could hack the driver and add some read/write access counters. Then from your application, read those counters every second. You can therefore measure the read/write transfer speeds. If you are close to the PIO0 theoretical limit, it means that it is the PIO0 interface that limits your speed, and using a higher PIO or DMA should improve it. 

There is an IDE controller on Opencores that you could use but I don't know how well it is tested. We use the Evatronix controller in our projects and it works very well, in all PIO and DMA modes.  @Michael: we talked about the industrial compact flash that could recover from a power loss in this thread (http://www.alteraforum.com/forum/showthread.php?t=25702)

[Altera_Forum]

@Daixiwen - This Evatronix controller - is there a uClinux compatible driver ? 

 We did find that the write times are definitely PIO0.

[Altera_Forum]

IIRC they can provide a generic driver with an API to access the ATA interface, and you need to write the glue between the operating system and their API yourself. They have some glue codes for a few operating systems, but you'll have to ask them if they have one for uClinux