sysutils/diskcheckd needs fixing and a maintainer
utisoft at gmail.com
Thu Aug 18 06:21:22 UTC 2011
On 18 August 2011 09:03, <perryh at pluto.rain.com> wrote:
> Chris Rees <utisoft at gmail.com> wrote:
>> We don't want to provide broken software.
> Mark Linimon <linimon at lonesome.com> wrote:
>> ... it's obsolete, broken, junk ...
> Unless there is more to this than is reported in those two PRs,
> I'd call it a considerable exaggeration to describe diskcheckd
> as "broken".
> * http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/115853
> is shown as "closed", so presumably is no longer a problem.
Wow, would it have been too difficult to actually READ the closing
message from Jeremy? I suggest you look again -- I've pasted it here
so you can see it.
"The problem here is that the code does not do what the manpage says (or
vice-versa). The 3rd column does not specify frequency of checking, but
rather, over what duration of time to spread a single disk scan over.
Thus, 7 days would mean "spread the entire disk check at X rate over the
course of 7 days". There is still a bug in the code where large disks
will cause problems resulting in updateproctitle() never getting called,
and so on, but that's unrelated to this PR. I'm closing the PR because
trying to fix all of this should really be ben@'s responsibility.
(Sorry for sounding harsh.)"
How does that indicate it's fixed? It's an 'abandoned' PR.
> * http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/143566
> says "... diskcheckd runs fine when gmirror is not involved ..."
> and then goes on to describe a problem _when diskcheckd is run
> on a component of a gmirror_.
> How anyone got from "in some way incompatible with gmirror" to
> "broken" escapes me. One could as well claim that gmirror is
> "broken" because it is incompatible with diskcheckd >:->
No. It's broken because there's no logical reason -- it will probably
break with other things.
> I'm currently running diskcheckd on an 8.1 gmirrored system with
> config file
> /dev/ad0 * * 8192
> -- which should be using about 1/6 of that disk's bandwidth -- and
> will see what happens when it reaches the end of the disk (sometime
> tomorrow). So far I have not seen any issues.
Thank you for testing and investigating, this is what the port has
needed, and two days of being deprecated has achieved more than 18
months of a PR being open.
Chris Rees | FreeBSD Developer
crees at FreeBSD.org | http://people.freebsd.org/~crees
More information about the freebsd-ports