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

Re: Major JFFS2 bug (?)

On Tue, 15 May 2001, Tim Riker wrote:

> Under what conditions could the 3rd step fail? Failure to allocate space
> for the new copy of the directory? Wouldn't the removal of foo then also
> fail?

Yeah, basically. I can't imagine the removal of foo ever actually working.
But we still shouldn't be trying it.

> The other cases look fine. Expected behavior. as long as steps one and
> two are atomic "everything will be all right" (tm).

True, and that's why it's done that way at the moment. The rename(2) man
page expects this:

       If  newpath  already exists it will be atomically replaced
       (subject to a few conditions - see ERRORS below), so  that
       there  is  no point at which another process attempting to
       access newpath will find it missing.

       If newpath exists but the operation fails for some  reason
       rename  guarantees  to  leave  an  instance  of newpath in

       However, when overwriting there will probably be a  window
       in  which both oldpath and newpath refer to the file being

The problem is the error case, where the subsequent unlink dirent for
'foo.new' cannot be written out because there's insufficient space.
We're supposed to return -ENOSPC. It's not clear that creating a hard
link before doing so is within the permitted behaviour.

At the very least, we should reserve sufficient space for both nodes and
write them both before releasing the allocation semaphore. At least we
only have to worry about physical errors then.

A single 'rename' node containing a normal positive dirent and also an
{inum,name,hash} of a dirent to be unlinked would possibly be a better
was to solve this problem. It involves teaching a few places in the code
that there's more than one type of dirent node, though.

Then again, Vipin's transaction API could do it too - start_transaction();
do_link(foo.new, foo); do_unlink(foo.new); commit_transaction();


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