Hmmm
OK it looks like the entry is staying "alive" in the dentry which means that
the directory is not becoming empty. This causes problems because when a
look-up is attempted the dentry no longer has an associated inode - this
would be a BadThing. The defered deletion might be causing this problem.
I'll do some tests here, but if you have a system all set up amd faulting, it
would be interesting to see a trace of yaffs messages as well as doing "ls
-ial" on a broken directory. The -i option then gives inode info which helps
to tie up the faulting file
-- Charles
On Thursday 06 January 2005 20:35,
bbosch@iphase.com wrote:
> Charles,
>
> I recently updated my kernel to the latest CVS YAFFS code and
> discovered rather serious filesystem corruption apparently triggered
> by heavy file unlink and creation activity. The symptoms are easily
> reproduced by repeatedly extracting a tar archive containing several
> files and symbolic links in an initially empty YAFFS file system.
> Soon, tar reports "tar: Couldnt remove old file: Directory not empty"
> for a random file which was not supposed to be a directory! Other
> symptoms are YAFFS errors which read "**>> yaffs chunk 792 was not
> erased **>> yaffs write required 2 attempts".
>
> After the errors, the filesystem shows corrupted directories with ls
> output like:
>
> ~ # ls -l /mnt/bin
> ls:
> /mnt/bin/ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
>ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
>ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
>ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ: No such file or directory ls:
> /mnt/bin/ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
>ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
>ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
>ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ: No such file or directory ls:
> /mnt/bin/ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
>ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
>ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
>ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ: No such file or directory ls:
> /mnt/bin/ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
>ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
>ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
>ÿÿÿÿÿÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ: No such file or directory
> lrwxrwxrwx 1 root root 14 Dec 8 18:24 [ -> ../bin/busybox
> lrwxrwxrwx 1 root root 14 Dec 8 18:24 ash ->
> ../bin/busybox lrwxrwxrwx 1 root root 14 Dec 8 18:24 awk
> -> ../bin/busybox lrwxrwxrwx 1 root root 14 Dec 8 18:24
> basename -> ../bin/busybox
>
> Unmounting and remounting the file system seems to make the directory
> corruption go away (at least most of the time).
>
> My kernel is based on 2.4.26. The architecture is ppc. YAFFS is
> running over a pretty stock MTD/NAND layer.
>
> A condensed summary of configuration from my Makefile:
>
> #USE_RAM_FOR_TEST = -DCONFIG_YAFFS_RAM_ENABLED
> USE_MTD = -DCONFIG_YAFFS_MTD_ENABLED
> #USE_OLD_MTD = -DCONFIG_YAFFS_USE_OLD_MTD
> #USE_NANDECC = -DCONFIG_YAFFS_USE_NANDECC
> #USE_WRONGECC = -DCONFIG_YAFFS_ECC_WRONG_ORDER
> USE_GENERIC_RW = -DCONFIG_YAFFS_USE_GENERIC_RW
> #USE_HEADER_FILE_SIZE = -DCONFIG_YAFFS_USE_HEADER_FILE_SIZE
> #IGNORE_CHUNK_ERASED = -DCONFIG_YAFFS_DISABLE_CHUNK_ERASED_CHECK
> #IGNORE_WRITE_VERIFY = -DCONFIG_YAFFS_DISBLE_WRITE_VERIFY
> ENABLE_SHORT_NAMES_IN_RAM = -DCONFIG_SHORT_NAMES_IN_RAM
>
> I have isolated the change which introduced this behavior to the CVS
> changes made on 10/21/2004. IE, "cvs diff -c -D 2004/10/20 -D
> 2004/10/21" will show the changes that seem to be causing the problem.
> CVS 2004/10/20 seems to work fine and I would just drop back to that
> revision, but, of course, that leaves the bug which Michael found to
> bite me later.
>
> I'm not familiar enough with the VFS layer to guess at the cause, but
> this is quite reproducable. Any ideas where to look? Any suggestions
> on narrowing this down to a specific VFS interaction?
>
> BTW, my trek back thru CVS history might have been less confusing with
> fewer "empty log messages". :-)
>
> Thanks,
>
> --Brad Bosch
>
> Quite some time ago, Charles Manning wrote:
> > I have just checked in changes to yaffs_fs.c, yaffs_guts.c, yaffs_guts.h
> > to fix this problem.
> >
> > Now yaffs Objects in the object look up hash table are not freed until
> > the coresponding inode is cleared.
> >
> > I did some tests with a smaller bucket size (8) and observed that the
> > recycling problem does not happen. Object numbers are now only recycled
> > when the Linux cache tells us it is OK.
> >
> > This mechanism does not use any new kernel calls and should thus be good
> > with older kernels.
> >
> > Thanx to Michael for his efforts in hunting down the problem.
> >
> > -- Charles
> >
> > _______________________________________________
> > yaffs mailing list
> > yaffs@stoneboat.aleph1.co.uk
> > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
(text/plain)