Marco wrote: > There's the checksum, but the most important feature of this fs is the > write protection. The page table entries that map the > backing-store RAM are normally marked read-only. Write operations into > the filesystem temporarily mark the affected pages as writeable, the > write operation is carried out with locks held, and then the pte is > marked read-only again. This feature provides protection against > filesystem corruption caused by errant writes into the RAM due to > kernel bugs for instance. I provided a test module for this. When the > module is loaded tries to do a dirty write in the superblock, at this > point you should see an error on the write.
Ok. Random question: does it work with NOMMU? :-) (I'm biased, my devices are NOMMU). Second question: what happens if the system crashing _during_ a write to a file. Does it mean that file will fail it's checksum when it's read at the next boot? Maybe files aren't so important. What about when you write a file, and then rename it over an existing file to replace it. (E.g. a config file), and the system crashes _during_ the rename? At the next boot, is it guaranteed to see either the old or the new file, or can the directory be corrupt / fail it's checksum? > > As you say PRAMFS can work with special SRAMs needing memory > > protection (and maybe cache coherence?), if you mmap() a file does it > > need to use the page cache then? If so, do you have issues with > > coherency between mmap() and direct read/write? > > See my response above about my concept of protection. However the mmap > it's a similar approach. I can "mmap" the SRAM and I can write into it > my data, but I think the possibility to have a fs it's great. We can use > the device as normal disk, i.e. we can use cp, mv and so on. I meant when you mmap() a file on the filesystem, like you do when running an executable, for example. Does mmap() on a file work or is it forbidden? Just curious, I'd guess it's forbidden, and you wouldn't want _direct_ mappings to the backing SRAM anyway so you can keep those checksums up to date. > >> On this point I'd like to hear other embedded guys. > > > > As one, I'd like to say if it can checksum the RAM at boot as well, > > then I might like to use a small one in ordinary SRAM (at a fixed > > reserved address) for those occasions when a reboot happens > > (intentional or not) and I'd like to pass a little data to the next > > running kernel about why the reboot happened, without touching flash > > every time. > > > > -- Jamie > > Yeah Jamie, the goal of this fs is exactly that! Great :-) -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
