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

RE: Major JFFS2 bug (?)



>This is exactly what I thought people are doing. It brings up one
>important question about JFFS though:

>If I do a 'mv /etc/inittab.new /etc/inittab' (for example) will JFFS
>guarantee that the *.new file will not be gone unless it was correctly
>moved to the destination file?

The answer is most likely yes, but JFFS has nothing to do with that, as
that is most likey being guranteed by the "mv" command not deleting the
<src> file till it successfully copies it over the <dest> file.

Now, if I can be presumptious enough to rephrase your question to an even
more (IMHO) important one:

Will JFFS(2) guarantee that you will NOT end up with a /etc/inittab file
this is *some* combination of the old AND new file if power fails in 
the middle of the move? Then based on what I understood with my exchanges
with Alan (the last 2 days on this thread), the answer is NO! Unless your
"mv" command is designed to be power fail "safe", like the example Alan had
quoted above. Is a regular "mv" power fail safe? I don't know.

JFFS was designed for file *system* consistancy, not file *data* consistancy
(during power fails). I valiantly tried to make a case for file data
consistancy also, but no luck so far.

>It would be OK to end up with the new contents in both files.

This would happen when the move completed, but power failed before "mv" was
able to unlink the <src> file. This is a trivial case, that will work with
almost any fs out there.

>Did somebody do test on that? This will be important to do reliable
>remote
>upgrades of critical system components.

I have tested what I asked above in my "repharased" question above. See
discussion under "Major JFFS2 bug (?)" in the last 2 days.

Vipin

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