getdents64 problem in 2.6.23

Joakim Tjernlund joakim.tjernlund at
Fri Oct 26 19:03:37 EDT 2007


> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2 at] 
> Sent: den 26 oktober 2007 21:14
> To: joakim.tjernlund at
> Cc: Linux-MTD Mailing List
> Subject: Re: getdents64 problem in 2.6.23
> On Wed, 2007-10-24 at 15:47 +0200, Joakim Tjernlund wrote:
> > started to use 2.6.23 in our development system a few days ago and
> > now I got problems when deleting files from a large directory
> > structure. A rm -rf does not delete all files.
> > 
> > Did a strace and found that some files does not appear in the
> > strace, the same ones that doesn't get deleted.
> Following up on the IRC conversation... the problem here is the horrid
> readdir() interface, and how it interacts with f_pos on the 
> directory's
> file descriptor. The file position simply represents the offset within
> the linked list of dirents -- which used to be fairly safe, 
> because when
> we unlinked something, we'd write out a 'deletion dirent', which would
> serve as a placeholder in the list.
> Someone changed that code recently though, and those deletion dirents
> are no longer written on NOR flash.... :)

Yeah, I wonder who that was. Can't really recall :)

> The answer is probably to keep a 'deletion dirent' in the 
> f->dents list
> of jffs2_full_dirents, but with NULL for the 'raw' field. I think that
> shouldn't break any other part of the code. Then you'd want to remove
> those dummy dirents when the filedescriptor for the directory in
> question is closed.

Is this what you mean(just a stupid hack for now)?
          //*prev = this->next;
            jffs2_mark_node_obsolete(c, (this->raw));
            this->raw = NULL;

Perhaps add a jffs2_add_fd_to_list(c, this, &dir_f->dents)?

How do I find where the filedescriptor is closed?


More information about the linux-mtd mailing list