On Tue, 23 Sep 1997, Arthur Jerijian wrote:
> Sounds like the ls -lR operation updated the atimes of every single
> directory entry starting from /, and perhaps all the files in all the
> directories as well. The sync command writes these atimes back to
> the disk, which is why it takes so long.
> There used to be a patch that disabled the use of atime altogether. Is
> this patch still around? Did it make it to 2.1?
> On Tue, 23 Sep 1997, Richard B. Johnson wrote:
> > Possible bug or feature in V2.1.55 with pre-patch-2.1.56B (which?).
> > o Boot machine with init=/bin/bash
> > o Mount the root file-system.
> > `mount -n -o remount /`
> > o Mount /proc if you want. Do not start /sbin/update.
> > o Perform `ls -R /`. The hard disk will be active.
> > o If you have plenty of RAM, the second time you perform `ls -R /`
> > no disk activity will occur because the whole directory structure
> > is is RAM. This is nice. This is how it should be.
> > o Now perform `sync`. Every directory entry will be updated, causing
> > an enormonous amount of wasted CPU cycles and disk activity!
> > Sync should have done nothing. The disk was never written.
> > If you execute `ls -R /`, the entire directory structure is again
> > read from the physical media. Not nice.
> > o Now, if you start /sbin/update, you will see the same problem as
> > update calls sync() every so-often. Every time sync() is called
> > by update, the entire directory structure that exists in the new
> > dcache is either read from, or written to, the physical disk!
> > o This undoes all the good work that the new dcache code did.
> > Cheers,
> > DJ
> > Richard B. Johnson
> > Analogic Corporation
> > Penguin : Linux version 2.1.55 on an i586 machine (66.15 BogoMips).
> > Warning : It's hard to stay on the trailing edge of technology.
> > Linux : Engineering tool
> > Spam : sync@localhost, daemon@loghost