Sujet : Re: Files tree
De : rich (at) *nospam* example.invalid (Rich)
Groupes : comp.os.linux.miscDate : 12. Apr 2024, 15:19:01
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <uvbfsl$2d8f0$3@dont-email.me>
References : 1 2
User-Agent : tin/2.6.1-20211226 ("Convalmore") (Linux/5.15.139 (x86_64))
vallor <
vallor@cultnix.org> wrote:
On Fri, 12 Apr 2024 13:39:34 +0100, James Harris
As for run times, if anyone's interested, despite the server I ran
this on having multiple locally mounted filesystems and one NFS the
initial tests ran in 90 seconds to generate the first file and 5
minutes to generate the second, which would mean (as long as no
faults are found) that it would be no problem to run at least the
first script whenever required. Other than that, I'd probably also
schedule both to run each night.
Since there is a significant difference in run times, you might want
to try running your first find(1) with the -ls option, instead of using
the pipeline to ls(1). (You could also possibly do it all with one
find(1) command, and use cut(1), awk(1) or perl(1) to split things
up, but my brain isn't fully booted yet this morning to figure that
out. ;) )
The difference in runtime is not because of the pipeline.
The runtime difference is the "find" pass only has to retreive the
filenames, while the second "ls" pass has to also retreive all the
metadata (i.e., read the inodes).
Retreiving only filenames is less disk IO, and far fewer seeks (if on a
spinning rust disk), than retreiving all the file metadata.