bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: du: fts and vfat


From: Justin Pryzby
Subject: Re: du: fts and vfat
Date: Sun, 25 Nov 2007 09:21:24 -0500
User-agent: Mutt/1.5.16 (2007-06-11)

On Sun, Nov 25, 2007 at 09:18:33AM +0100, Jim Meyering wrote:
> Justin Pryzby <address@hidden> wrote:
> > It appears that fts uses some stat data which doesn't work as expected
> > for fat32 filesystems.
> >
> ...
> > Since the output changes on each invocation of the program, I'm of the
> > impression this is a bug in the filesystem driver (an apparent result
> > of generating data to fill the structure fields to appease the
> > traditional system calls when the filesystem doesn't natively use
> > those values).
> >
> > The same problem occurs even when the FS is remounted readonly, but
> > disappears if the FTS_NOCHDIR option is set.  Here's a diff fragment
> > of strace -v demonstrating the d_ino field differing between
> > invocations.
> 
> Thanks for the report.
> 
> You're right.  This is a problem in your environment, not with du/fts.
> If the driver changes the dev/inode of an open file, all bets are off.
> 
> Why are you using FTS_NOCHDIR anyway?  no openat support?
It was just for debugging.

> What version of du are you using?
5.97-5.3 from debian etch.

> For things like this, it's good to mention what kernel and libc
> version you're using -- for reference if/when others encounter
> the same problem later.
linux-2.6.22-3-vserver-686, glibc-2.7-1 (although the problem was
initially experienced with 2.6.X, I just reproduced it with this new
version).

However this time the problem occurred only on the first invocation.
$ du -sh /mnt/1/music/jake/
du: `/mnt/1/music/jake/Music/Newly Ripped': No such file or directory
du: `/mnt/1/music/jake/Music/Napster Directory': No such file or directory
du: `/mnt/1/music/jake/New Folder': No such file or directory
du: `/mnt/1/music/jake/Holiday CD 2006 takes': No such file or directory
177G    /mnt/1/music/jake/
$ du -sh /mnt/1/music/jake/
186G    /mnt/1/music/jake/

I note that yesterday I added a 2nd 128MB ram chip to this machine.
So my current hypothesis is that there's a hash table or such of
inodes which was being overflowed.  So this may just be an (expected?)
consequence of accessing a large devices (with many files) on a
machine with not much ram.
 
Justin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]