Date: Sat, 4 Sep 2004 00:40:49 -0300 (ADT) From: "Marc G. Fournier" <scrappy@hub.org> To: Chris Laverdure <dashevil@sympatico.ca> Cc: Giorgos Keramidas <keramida@linux.gr> Subject: Re: what is fsck's "slowdown"? Message-ID: <20040904003919.X812@ganymede.hub.org> In-Reply-To: <1094232909.76688.1.camel@elemental.DashEvil> References: <20040903175434.A812@ganymede.hub.org> <20040903211427.GB1199@gothmog.gr> <1094232909.76688.1.camel@elemental.DashEvil>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 3 Sep 2004, Chris Laverdure wrote: > On Fri, 2004-09-03 at 21:14, Giorgos Keramidas wrote: >> On 2004-09-03 18:01, "Marc G. Fournier" <scrappy@hub.org> wrote: >>> >>> load: 0.99 cmd: fsck 67 [running] 15192.26u 142.30s 99% 184284k >>> /dev/da0s1h: phase 4: cyl group 408 of 866 (47%) >>> >>> wouldn't it be possible, on a dual CPU system, to have group 434 and above >>> run on one process, while group 433 and below running on the second, in >>> parallel? Its not like the drives are being beat up: >> >> My intuition says that if metadata of the first part of the disk references >> data residing on the second part synchronization and locking would probably >> be a bit difficult; actually very difficult. > > My intuition tells me that it would be a much better solution to run > multiple fsck's concurrently. What harm could there be in fscking (num > of processors) partitions at the same time? I already do that ... the problem file system is the 100+GB one that just took 12hrs to run through on a machine that was 50% idle for the whole time :( I'm looking forward to moving to 5.x because of the bkgd fsck, *but* ... if it takes 12hrs as a foreground process when it can suck all the CPU it wants, how long is it goin to take on a live server where its sharing with several hundred other processes? :( ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040904003919.X812>