> > (If I'm the only one to debug with ears, please excuse)
> > I think that "df" makes more noise on my harddisk than previous (i.e.
> > 2.0.30) kernels.
> >
> > Can it be that some metadata is never written back to disk unless a
> > "df" (or manual sync()) is done? My ears suggest that more data is
> > written back now...
> >
> > Maybe someone can check it. And you can send me the CD "The sounds of
> > the most popular harddisks"... ;-)
>
> Hmm. Recreated in 2.1.55, df sounds like sync... And looks like sync,
> too (on blinkenlights)... And guess what:
>
> And it is because df _calls_ sync!
Honestly, I'm not surprised, but the argument is: When bdflush is
running, shouldn't all the dirty inodes be written back to disk from
time to time. If so, sync() shouldn't have to do much work.
To me it seems as if much more blocks are written back than before.
If it's not a problem of bdflush or sync, can it be that more inodes
are made dirty than before? (Or is something forgetting to clear the
dirty bit?)
>
> write(1, "Filesystem 1024-blocks "..., 67Filesystem
> 1024-blocks Used Available Capacity Mounted on
> ) = 67
> sync() = 0
> statfs("/", {f_type=EXT2_SUPER_MAGIC, f_bsize=1024, f_blocks=491660,
> f_bfree=21860, f_files=127472, f_ffree=89438, f_namelen=255}}) = 0
> write(1, "/dev/hda4 491660 46"..., 58/dev/hda4
> 491660 469800 16780 97%
>
> So "bug" is in df (or is sync required before df-ing?).
That is UNIX tradition somehow; I don't know if it makes a large
difference with and without.
Ulrich