jffs_file_write

[David Woodhouse]

bjornw at axis.com said:
> But you will run into the same problem then that the buffer-cache we
> avoid solves. If you start queueing stuff, the reads will need to
> check the queue before reading from the flash for example (the in-core
> node which keeps track of the data contents of the files can of course
> have a pointer to the queued data if it's not on flash yet). You
> cannot rely on the page cache caching the changes because the pages
> might have become invalidated. 

True. It should be possible to make JFFS use the page cache and
generic_file_{read,write}() though, so the data in the page cache are always
valid. There are apparently ways to do it without having to write 4 KB nodes
each time we're told a page has been dirtied.

I need to schedule myself a crash course on Linux VFS so that I know what 
I'm talking about :)

bjornw at axis.com said:
> . When he has hit OK and gotten the "Saved" webpage, he pulls the
> plug. OK that is perhaps fixed by writing files with O_SYNC or
> whatever that mechanism is called like you say...

Netscape does actually write changes to its config files with O_SYNC, and I
think it's reasonable to expect that to be necessary. A journalling
filesystem should always have a consistent state, but it allowed to have
write-behind. It doesn't necessarily have to commit writes to the media
before returning - that's what O_SYNC is for.




--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org