Date: Sat, 4 Sep 2004 11:34:31 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: dillon@apollo.backplane.com Cc: freebsd-current@FreeBSD.org Subject: Re: what is fsck's "slowdown"? Message-ID: <200409041834.i84IYVrk032267@gw.catspoiler.org> In-Reply-To: <200409041723.i84HNi4Q046252@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 Sep, Matthew Dillon wrote: > :This sort of thing was my initial thought, but the posted CPU usage > :statistics show that fsck is burning up most of its CPU cycles in > :userland. > : > :>> load: 0.99 cmd: fsck 67 [running] 15192.26u 142.30s 99% 184284k > : > :Increasing MAXBUFSPACE looks like it would make the problem worse > :because getdatablk() does a linear search. > > Oh my. I didn't even notice. That code dates all the way back to 1994 > so I wont bash the author too badly, but it is pretty aweful coding. At least it moves the buffer to the front of the list so that repeated accesses of the same buffer are fast. > Hashing the buffer cache is trivial. I'll do it for DragonFly and post > the patch as a template for you guys to do it in FreeBSD (or you could just > do it on your own, it really does look trivial). You might want to instrument the code to find out how much reuse there is of the cached data. I would not expect much reuse within a pass, which may mean that increasing MAXBUFSPACE might not help much. Doing read-ahead might help, especially if it can be hinted (do read-ahead when reading inode blocks but not indirect blocks). The read-ahead already done by the drive gets rid of the latency caused by mechanical issues, but explicitly doing read-ahead in the fsck code would eliminate some kernel overhead and drive command latency. As I mentioned before, profiling the code is likely to be interesting.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200409041834.i84IYVrk032267>