I will summarise this thread and try to set the picture of what has been discussed and concluded. 1. ext3 with mode data=journal in kernel 2.6.x is probably working as intended. One has responded with using this mode heavily on 2.6.6 without corruption related to the fs code. Since nobody has said that they have seen faults, we should belive that it is safe. It is in an stable kernel... 2. Mode data=journal will not gain much more than correct mtime compared to mode data=ordered. 3. Applications that need a very consistent filesystem, e.g. consistent writes, they need to do this by implementing there own transaction/journaling system. Alberto Bertogli has written a library that can assist with this. See URL, http://users.auriga.wearlab.de/~alb/libjio/. I have not used it so I can not say for sure how good it is, but it seems like a nice start and worth to take a look at. 4. Because mode data=journal does not gain much, it would be better to use mode data=ordered and use any form of transaction/journaling itself. Mode data=ordered is the default in ext3 and probably most used, and therefor also best tested. 5. If, and only if, you have less than 1 block size updates (that do not cross block boundaries), these operations (write) can be done atomically. (with help of fsync and stuff,(from Oleg and others)). 6. Wear leveling on a Compact Flash card: Wear leveling is an important task. SanDisk has Industrial Grade support for some of there CF-cards, see these links. http://www.sandisk.com/pressrelease/020522_toughness.htm http://www.sandisk.com/pressrelease/021112_igapps.htm http://www.sandisk.com/pdf/oem/WPaperWearLevelv1.0.pdf We are in the telecommunications and networking business and need this kind of Compact Flash cards. From there site: * Enhanced error correction and sophisticated wear leveling technology * Card level MTBF >3 million hours * 2 million program/erase cycle endurance per block We are not bound to SanDisk. We could use any suplier that meet these criteria. I do not know the wear leveling algorithm in detail so how they shuffle read-only data (or if they do) around the disk, and even how it does it if we create partitions on this CF disk (partition are probably transparent for the wear leveling algorithm), is an issue we need to find out of. Thanks for all your replies ( there are 32 threads:-) spread along the ext3 ML and the LKML and a couple private ). It has helped me a lot. Best regards -- Petter Larsen cand. scient. moreCom as 913 17 222 _______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
