lkml.org 
[lkml]   [1997]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: New feature
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?

Thanks!
--Arthur

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
>
>


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.069 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site