Il 07/01/2011 19:42, Tony Luck ha scritto: > On Thu, Jan 6, 2011 at 4:01 AM, Marco Stornelli > <marco.stornelli@xxxxxxxxx> wrote: >> +accessed data that must survive system reboots and power cycles. An >> +example usage might be system logs under /var/log, or a user address >> +book in a cell phone or PDA. > > Some usage model questions: > > How do you handle errors? I see that there are a few sanity checks in the > "mount" path ... but there would seem to be several opportunities for the > file system to get corrupted in other ways. Since you don't have a block > device, a standard "fsck" program looks challenging (though I guess you > could mmap("/dev/mem") to peek & poke at the filesystem before trying > to mount it). Actually not (at least when strict devmem options is turned on) because the memory region is marked exclusive at the moment (only a design constraint). About the errors: pramfs does not maintain file data in the page caches for normal file I/O, so no writeback, the read/write operation are done with direct io and they are always sync. The data are write protected in hw when the arch provide this facility (x86 does). Inode contains a checksum and when there are problems they are marked as bad. Superblock contains checksum and there is a redundant superblock. > Some sort of recovery path would seem useful for the "address > book" use model ... or do you just expect users to back their address book > up (to the cloud?) and have the phone just make a clean filesystem if any > errors are found? Yeah maybe the address book can be a case not perfectly suitable, but it was only an example. I thought about the fs as a "cache" in this use case. However the designer can use this area whatever he wants, recently I saw in a project this fs used as a system cache for decrypted files where the files were stored in flash encrypted, so I think it's flexible. > What about quotas? You have a fixed amount of persistent space, and > presumably a number of apps that the user installs on their device that > may like to use pramfs to store data. Do you need some kernel enforcement > to stop one rogue application from using up all the space? Or do you expect that > this would be handled in some library level interface that applications will > use to access pramfs? Sincerely in my embedded systems I've never used quotas even to save footprint (for the kernel support I mean). I don't think it's an hot feature in this case and other fs for embedded use as ubifs, jffs2 etc. don't support it. Marco -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html