I started with YAFFS from CVS back on 2005-05-26, and have made YAFFS
work on a 547x running linux-2.4.26 targeting Intel strata-flash (32Mb,
0x20000 block size), using 512 byte chunks and creating a spare area at
the end of each flash block so I get 248 chunks per flash block
(131072 / (512 + 16)), and I have it all working.
What I'm finding however is that its performance as a filesystem can at
times be abysmal. I'm not sure why, but I'm finding cases where the
gross lock is held in excess of a *minute* which causes other processes
that access the filesystem to block. This was observed while copying
2.3MB of data from /lib into the flash, and at the same time doing a
'du' of the flash filesystem.
To make matters worse, the code in yaffs_GrossLock() uses down() instead
of down_interruptible() which makes it impossible to interrupt any
processes waiting for the lock.
1) Has anyone patched Yaffs to use down_interruptible() instead of
'down'?
I've instrumented yaffs_grossLock/yaffs_grossUnlock to discern where the
time goes, and turned nShortOpCache to zero
[root@localhost root]# cp /lib/libc* /mnt/flash-user/junk/
yaffs_GrossLockPriv: blocked by yaffs_file_write:806
yaffs_GrossLockPriv: blocked by yaffs_file_write:806
yaffs_GrossLockPriv: blocked by yaffs_file_write:806
[root@localhost root]# rm /mnt/flash-user/junk/*
yaffs_GrossUnlock: lock held by yaffs_unlink:1053 for 4 jiffies
[root@localhost root]# cp /lib/libc* /mnt/flash-user/junk/
yaffs_GrossUnlock: lock held by yaffs_file_write:806 for 78 jiffies
yaffs_GrossLockPriv: blocked by yaffs_file_write:806
yaffs_GrossLockPriv: yaffs_readdir:871 wait 21297 jiffies by
yaffs_file_flush:488
[root@localhost root]#
Notices that the file flush holds the lock for over three *MINUTES*.
2) Is there anyway to more finely lock YAFFS instead of the gross lock
that exists now?
3) How can yaffs_file_flush take *so* long is nShortOpCache is set to
zero so yaffs_FlushFilesChunkCache should take no time?
4) Has anyone seen this type of problem on other NOR-based YAFFS
implementations?
--
Peter Barada <
Peter.B@LogicPD.com>