Re: jffs_file_write

[Philipp Rumpf <prumpf@uzix.org>]

On Tue, Jul 25, 2000 at 04:12:11PM +0100, David Woodhouse wrote:
> 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().

prepare_write can look like this:

	if(try_to_abort_pending_conflicting_writes_fails()) {
		sleep until the writes happened;
	} else {
		reschedule merged writes;
	}

I'm not actually sure there's a POSIX requirement to do this - as long as
the fs doesn't crash the page cache will keep our view of it consistent.

BTW, the simplistic implementation would simply add

	__u32 first_modified_byte;
	__u32 last_modified_byte;

to jffs_file and keep track of only one range that has been modified - it
should work well enough for the common case (non-conflicting consecutive
writes) and we can easily detect the cases in which it doesn't work and
fall back to sleeping until the write are finished.

> 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.

If all writes are done by one thread that shouldn't be necessary.


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