[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Major JFFS2 bug (?) No! Feature request? Yes!




Vipin.Malik@xxxxxxx.com said:
> > I'm unconvinced either way, but because write() is permitted to
> > return having written fewer data than it was requested to,

>  There is no debating that. That's the current implementation. But
> does it *have* to be? 

It does *have* to be permitted by POSIX. In practice, however, stuff breaks 
if you actually do it, so we don't. I mention it simply to banish the 
'POSIX requires this' suggestion.

I would like to continue to limit individual nodes to PAGE_SIZE though, for 
simplicity's sake. We therefore need to loop in write() - and it means we 
can actually use generic_file_write().


Vipin.Malik@xxxxxxx.com said:
>  All or non is fine, portion (what I'm arguing for) is not. 

All or none is what you'll get if you don't power cycle in the middle, 
_except_ if you get -ENOSPC after writing the first pages.

What you're asking for is exposing start_transaction() and
commit_transaction() to userspace, and having some way to ensure that nodes 
which are written as part of a transaction which was never committed get 
ignored.

The 'chunk_n_of_m' approach covers only writes to a single contiguous 
region in a single file, and it would actually be quite difficult to 
implement. We don't have the context in the right place to do the loop you 
suggest. 

Hmmm. Let me think about it some time when it isn't one in the morning, and 
I'm not trying to get my OLS paper completed.

> > I believe ext3 exposes transactions to userspace for use by
> > Intermezzo.  Take a look at the API used for that. Also consider the
> > requirements of  database backends.

> I can *attempt* to look at this, but it is probably way beyond my
> present abilities. Care to give me some place to start? 

Grab ext3 and InterMezzo code. Read. Work out the API used for the 
transaction stuff, whether it's appropriate for us, what locking guarantees 
it provides, how they avoid deadlock, etc.


--
dwmw2



To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com