* Problem deleting files with NAND/JFFS2 and a possible solution
@ 2004-01-27 11:47 Howard Gray
2004-01-27 13:22 ` David Woodhouse
0 siblings, 1 reply; 2+ messages in thread
From: Howard Gray @ 2004-01-27 11:47 UTC (permalink / raw)
To: linux-mtd
Hi,
I am using kernel 2.4.20 with the latest cvs MTD version. The system is a
PowerPC-based embedded device with both NOR and NAND flash. I have a
partition in NAND flash using JFFS2 as the file system.
If I mount a JFFS2 partition, delete a single file and unmount again,
everthing is o.k.
But if I mount the JFFS2 partition, delete a file and then (after a long pause
to ensure the garbage collector has finished) turn off the device without
unmounting, the file reappears after the reboot and new mount command. There
are various variations on this like mounting read-only before unmounting etc.
(with this device, I cannot assume that a user turns off this device in a
controlled way....)
It appears as if just deleting a file is not enough to mark any inodes as
dirty so that kupdated ignores them. It doesn't matter how long you wait for
the GC to be started because it won't be unless you do something else to the
file system too, like creating a new file or sending a SIGHUP to the GC. For
the same reason a "sync" doesn't help either.
After some time I came to the conclusion that there is a problem in the
function "jffs2_full_dirent" in the file "fs/jffs2/write.c". A call is made
to "jffs2_flash_writev" which has as its final parameter an inode number
(assuming alloc_mode is not ALLOC_GC). It looks like this:
write.c: approx. line 282.....
ret = jffs2_flash_writev(c, vecs, 2, flash_ofs, &retlen,
(alloc_mode==ALLOC_GC)?0:fd->ino);
"fd->ino" would appear always to be "0" in the case where a file is just being
deleted which, in turn, at the end of "jffs2_flash_writev" stops the inode
being dirtied (i.e. the superblock's "s_dirt" flag is not set to "1"): Here's
the call at the wnd of "jffs2_flash_writev":
wbuf.c: approx. line 752.....
if (c->wbuf_len && ino)
jffs2_wbuf_dirties_inode(c, ino);
I'm not sufficiently knowledgeable about the internals of JFFS2 to supply a
proper patch, but it would seem to me that the call to "jffs2_flash_writev"
in write.c at line 282 should be like this:
Suggestion....
write.c: approx. line 282.....
ret = jffs2_flash_writev(c, vecs, 2, flash_ofs, &retlen,
(alloc_mode==ALLOC_GC)?0:je32_to_cpu(rd->pino));
This would appear to be the inode of the directory entry and this is really
what we are changing when we delete a file, or am I missing something here ?
In any case, this change seems to have the desired effect and the problem is
cured.
Any comments would be appreciated. Thanks.
--
Howard
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Problem deleting files with NAND/JFFS2 and a possible solution
2004-01-27 11:47 Problem deleting files with NAND/JFFS2 and a possible solution Howard Gray
@ 2004-01-27 13:22 ` David Woodhouse
0 siblings, 0 replies; 2+ messages in thread
From: David Woodhouse @ 2004-01-27 13:22 UTC (permalink / raw)
To: rhea; +Cc: linux-mtd
On Tue, 2004-01-27 at 12:47 +0100, Howard Gray wrote:
> I'm not sufficiently knowledgeable about the internals of JFFS2 to supply a
> proper patch, but it would seem to me that the call to "jffs2_flash_writev"
> in write.c at line 282 should be like this:
Correct diagnosis, correct fix. I've applied it to CVS -- thanks.
--
dwmw2
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-01-27 13:22 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-01-27 11:47 Problem deleting files with NAND/JFFS2 and a possible solution Howard Gray
2004-01-27 13:22 ` David Woodhouse
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox