jffs_file_write

[David Woodhouse]

prumpf at uzix.org said:
>  I disagree with queueing nodes - just updating a "which byte ranges
> of the file have been modified" list should be both simpler and allow
> more efficient write merging/compression. 

OK. As long as we're aware of the possibility that a certain byte range 
could be changed _again_ in a different transaction. 

i.e.	pwrite(fd, "aaaaaaaaa", 10, 0);
	pwrite(fd, "bbbbbbbbb", 10, 5);

If you're not going to take a copy of data in the first write, but just 
keep it in the page cache and remember where it is, then you cannot write 
that transaction unless you combine it with the second one. 

That is - you _must_ combine the two into a single node write. It's not 
just an optimisation. If you were to write "aaaaabbbbb" to the beginning of 
the file and lose power before writing the rest of the 'bbbbb', I believe 
you're violating POSIX by having non-atomic write().

So if you're going to write data to the flash directly from the page cache, 
you have to have some lock in place which prevents anything else from 
dirtying it during the mtd_write() call.

--
dwmw2




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