From v@renyi.hu Tue May 19 11:28:42 2009
Received: from mirror.math-inst.hu ([193.224.79.10])
	by stoneboat.aleph1.co.uk with esmtps
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69)
	(envelope-from <v@renyi.hu>) id 1M6MYn-0004K5-1b
	for yaffs@lists.aleph1.co.uk; Tue, 19 May 2009 11:28:42 +0100
Received: from hexagon.math-inst.hu ([193.224.79.1])
	by mirror.math-inst.hu with esmtps(TLSv1:AES256-SHA:256) (Exim)
	from <v@renyi.hu>id 1M6MYj-0001zp-1h
	for <yaffs@lists.aleph1.co.uk>; Tue, 19 May 2009 12:28:33 +0200
Received: from v (helo=localhost)
	by hexagon.math-inst.hu with local-esmtp (Exim) id 1M6MYi-0004gM-W0
	from <v@renyi.hu>
	for <yaffs@lists.aleph1.co.uk>; Tue, 19 May 2009 12:28:33 +0200
Date: Tue, 19 May 2009 12:28:32 +0200 (CEST)
From: Babrian Viktor <v@renyi.hu>
X-X-Sender: v@hexagon.math-inst.hu
To: yaffs@lists.aleph1.co.uk
Message-ID: <Pine.LNX.4.64.0905191151470.25036@hexagon.math-inst.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-SPF: 
X-SA-Exim-Connect-IP: 193.224.79.10
X-SA-Exim-Mail-From: v@renyi.hu
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
	stoneboat.aleph1.co.uk
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=no
	version=3.2.5
X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000)
X-SA-Exim-Scanned: Yes (on stoneboat.aleph1.co.uk)
Subject: [Yaffs] power cycle during rm
X-BeenThere: yaffs@lists.aleph1.co.uk
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: Discussion of YAFFS NAND flash filesystem <yaffs.lists.aleph1.co.uk>
List-Unsubscribe: <http://lists.aleph1.co.uk/cgi-bin/mailman/options/yaffs>,
	<mailto:yaffs-request@lists.aleph1.co.uk?subject=unsubscribe>
List-Archive: <http://lists.aleph1.co.uk/lurker/list/yaffs.html>
List-Post: <mailto:yaffs@lists.aleph1.co.uk>
List-Help: <mailto:yaffs-request@lists.aleph1.co.uk?subject=help>
List-Subscribe: <http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs>,
	<mailto:yaffs-request@lists.aleph1.co.uk?subject=subscribe>
X-List-Received-Date: Tue, 19 May 2009 10:28:43 -0000

Hi all,

I experience a strange phenomenon if I do a power cycle during performing 
a file removal. It is easily reproduceable (at least using my setup).
I am using a fairly new (on week old or so) version of yaffs2, kernel 
version 2.6.26, yaffs_guts.c version: 1.82.
(however I also got the very same results with a somewhat older version)
(note: all other functionality seems to be OK)

Here is what I do briefly:
- flash_eraseall /dev/mtd13
- mount as yaffs2
- creating 2 files (dd if=/dev/zero of=/mnt/file bs=1M count=100)
- removing the second one (interrupted by power cycle)
- reboot, mount
- df, ls show things correctly
- now I re-create the second file
- ls is correct
- df shows much less free space than expected (the usable space is 
limited; free space is 'lost')


here is what I do exactly:
(flash_erase, mount not included, started from creating the second file)
/ $ ls -l /mnt
-rw-r--r--    1 root     root    104857600 Jan  1 00:04 file
drw-rw-rw-    1 root     root         2048 Jan  1 00:00 lost+found
/ $ df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/mtdblock5           32768     18184     14584  55% /
tmpfs                    63956         0     63956   0% /var/tmp
/dev/mtdblock13        2097152    106372   1990780   5% /mnt
/ $ dd if=/dev/zero of=/mnt/file1 bs=1M count=100
100+0 records in
100+0 records out
/ $ ls -l /mnt
-rw-r--r--    1 root     root    104857600 Jan  1 00:04 file
-rw-r--r--    1 root     root    104857600 Jan  1 00:05 file1
drw-rw-rw-    1 root     root         2048 Jan  1 00:00 lost+found
/ $ df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/mtdblock5           32768     18184     14584  55% /
tmpfs                    63956         0     63956   0% /var/tmp
/dev/mtdblock13        2097152    208900   1888252  10% /mnt
/ $
/ $ rm /mnt/file1

!!!!!!!! interrupted by power cycle

//after reboot, mount: (still normal)
/ $ ls -l /mnt/
-rw-r--r--    1 root     root    104857600 Jan  1 00:04 file
drw-rw-rw-    1 root     root         2048 Jan  1 00:00 lost+found
/ $ df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/mtdblock5           32768     18120     14648  55% /
tmpfs                    63956         0     63956   0% /var/tmp
/dev/mtdblock13        2097152    106372   1990780   5% /mnt
/ $

// and the strange part:

/ $ dd if=/dev/zero of=/mnt/file1 bs=1M count=100
ls -l /mnt
df
100+0 records in
100+0 records out
/ $ ls -l /mnt
-rw-r--r--    1 root     root    104857600 Jan  1 00:05 file
-rw-r--r--    1 root     root    104857600 Jan  1 00:01 file1
drw-rw-rw-    1 root     root         2048 Jan  1 00:00 lost+found
/ $ df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/mtdblock5           32768     18124     14644  55% /
tmpfs                    63956         0     63956   0% /var/tmp
/dev/mtdblock13        2097152    742624   1354528  35% /mnt
/ $

It can be seen that the number of used blocks is very high (without 
reason).

/ $ cat /proc/yaffs
YAFFS built:May 19 2009 05:24:47
$Id: yaffs_fs.c,v 1.79 2009/03/17 01:12:00 wookey Exp $
$Id: yaffs_guts.c,v 1.82 2009/03/09 04:24:17 charles Exp $

Device 0 "MAP"
startBlock......... 0
endBlock........... 16383
totalBytesPerChunk. 2048
nDataBytesPerChunk. 2048
chunkGroupBits..... 0
chunkGroupSize..... 1
nErasedBlocks...... 14764
nReservedBlocks.... 5
blocksInCheckpoint. 0
nTnodesCreated..... 7400
nFreeTnodes........ 77
nObjectsCreated.... 200
nFreeObjects....... 93
nFreeChunks........ 678095
nPageWrites........ 0
nPageReads......... 0
nBlockErasures..... 695
nGCCopies.......... 2
garbageCollections. 4865
passiveGCs......... 4865
nRetriedWrites..... 0
nShortOpCaches..... 10
nRetireBlocks...... 0
eccFixed........... 0
eccUnfixed......... 0
tagsEccFixed....... 0
tagsEccUnfixed..... 0
cacheHits.......... 0
nDeletedFiles...... 1
nUnlinkedFiles..... 1
nBackgroudDeletions 0
useNANDECC......... 1
isYaffs2........... 1
inbandTags......... 0
/ $

Note: the same happens with any number of files (including 1)


I have searched the net for similar cases but the ones I found are 4 years 
old and seemingly solved.
Is the problem familiar to anyone here?
What logs/traces should I make to find the lost blocks?

Any help is appreciated,
Viktor Babrian




