[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: memory mapped files on jffs?
On Fri, 8 Dec 2000, David Woodhouse wrote:
> We don't support shared writable mappings because it could mean writing out
> a whole 4KiB page each time a single byte on the page is changed. I suppose
> we could play games in writepage() with comparing the contents of the dirty
> page with the previous contents of the file. We don't do that. I don't
> really fancy trying to write it either :)
Conversely, for a "well-behaved" application, there should not be any
differences in performance re. JFFS with writepage vs write, but for any
non-well-behaved application it might be a call for difficult-to-find
trouble (like running out of flash, excessive GC'ing etc).
Consider the case that application A needs to write 8 kB to a file on the
flash. It should not matter if it does that through a shared writable
mapping or through an explicit write(). It's the same data that goes to
the same flash at the same place in the file.
Actually, the page method can be more efficient because it gets a chance
of combining writes until the flush (for this to be usable we need to be
certain that fsync actually writes the dirty pages to JFFS so we do not
loose the synchronization possible with write() - I know you fiddled with
this in the 2.2/2.4 port though so it might already be gone :)
The nasty case is like you note if only say 1 byte in every page is
changed. Is it feasible to do a binary sort of diff really ?
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to email@example.com