Due to an electrician flipping the wrong circuit breaker this morning, I had my servers go down hard ... they are all -STABLE, with one of the four taking a *very* long time to fsck: jupiter# ps aux | grep fsck root 361 99.0 2.3 95572 95508 p0 R+ 4:21PM 121:13.21 fsck -y /dev/da0s1h jupiter# date Tue Sep 30 18:37:02 ADT 2003 jupiter# Now, CPU time is rising, so I figure its still working away, and fsck shows: jupiter# fsck -y /dev/da0s1h ** /dev/da0s1h ** Last Mounted on /vm ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts so it isn't finding any errors ... A friend of mine asked if we had a journalling file system, which I told him know, as I don't believe we do ... but are/have there been any improvements to fsck in -CURRENT to improve performance on large file systems (this is a 6x36G RAID5 system)? Does UFS2 address any of this? I've actually had a 6x18gig RAID5 file system once take 11+hrs to fsck ... and when it was completed, everything seemed fine, with no reports of any file or directory corruption ... it obviously did a good job of checking the file system, just hate the lengthy downtime ...Received on Tue Sep 30 2003 - 12:43:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:24 UTC