Sergei

Is this a power-fail problem or an interpretation of POSIX problem?

ie. Did you force the problem by power cycling or did you observe it without 
cycling power?

I freely admit that my state of POSIXness is nowhere near the best in the 
planet.

One of the things I did to conserve space was to use a single "objectheader" 
structure to use for inodes and links. This was done because in most cases 
there is a 1:1 relationship. This makes some of the POSIX stuff like 
hardlinks and unlinked-but-still-existing files a bit hairy.

To summarise for my own benefit below:

Consider 

#touch a
#touch b
#mv -f a b

There should always be a "b" visible to all processes, but in YAFFS there 
exists a (short) time during which there is no "b". 

Is that a correct summary?

-- Charles




On Friday 29 April 2005 04:24, you wrote:
> Charles,
>
> > You should find the power fail stuff very robust (ie. zero
> > problems). If you
> > don't then please shout ***loud***.
>
> the first problem found after a dozen power cycles ;-(
>
> I have a counter file that contains a number
> that needs to be incremented. Increment is done as:
> 1. Read the number from the counter file (open as O_RDONLY, read, close)
> 2. Increment the number
> 3. Write the number to a temporary file
> 4. Rename temporary file to counter file
>
> Rename() suppose to be atomic per
> http://www.opengroup.org/onlinepubs/007908799/xsh/rename.html:
> "If the link named by the new argument exists, it is removed and
> old renamed to new. In this case, a link named new will remain
> visible to other processes throughout the renaming operation and
> will refer either to the file referred to by new or old before
> the operation began."
>
> After a few power cycle tests the counter file disappeared, but
> the temp file is still there. rename() never reported failure.
>
> -------------------Code---------------------
> ret = rename(FnameBlockTmp,FnameBlock);
>     if(ret < 0) terminate(instance,ERR,
> 			  "writer: failed to rename tmp block file %s",
> 			  FnameBlockTmp);
>
> ------------------Output-------------------
> running external script /mnt/flash/run.sh
> writer 0 started
> instance 0 terminated with status -1
> writer: failed to open block file /mnt/flash/blockno0
> writing status to </mnt/flash/status0>
>
> # cd /mnt/flash/
> # ls
> blockno.tmp0  jffs2tester   run.sh        test0         write.sh
> init.sh       lost+found    status0       verify.sh
>
> # cat /proc/yaffs
> YAFFS built:Apr 20 2005 14:39:45
> $Id: yaffs_fs.c,v 1.35 2004/10/20 20:12:43 charles Exp $
> $Id: yaffs_guts.c,v 1.37 2004/10/20 20:12:43 charles Exp $
>
> Device yaffs
> startBlock......... 1
> endBlock........... 8191
> chunkGroupBits..... 2
> chunkGroupSize..... 4
> nErasedBlocks...... 7
> nTnodesCreated..... 33400
> nFreeTnodes........ 2
> nObjectsCreated.... 32800
> nFreeObjects....... 83
> nFreeChunks........ 187105
> nPageWrites........ 6
> nPageReads......... 14
> nBlockErasures..... 0
> nGCCopies.......... 0
> garbageCollections. 0
> passiveGCs......... 0
> nRetriedWrites..... 0
> nRetireBlocks...... 0
> eccFixed........... 0
> eccUnfixed......... 0
> tagsEccFixed....... 0
> tagsEccUnfixed..... 8
> cacheHits.......... 0
> nDeletedFiles...... 32706
> nUnlinkedFiles..... 32706
> nBackgroudDeletions 0
> useNANDECC......... 1
> #
> -------------------------------------------
>
> Sergei