Do we want a periodic script for a zfs scrub?

Stefan Esser se at FreeBSD.org
Tue Jun 15 20:04:09 UTC 2010


Am 15.06.2010 15:10, schrieb Bruce Evans:
> On Tue, 15 Jun 2010, Stefan Esser wrote:
>> I extended expr and test (standalone binaries and /bin/sh builtins) to
>> handle 64 bit on i386 a looong time ago (and I also added overflow
>> checks to all calculations). But then it was decided, that POSIX demands
>> 32 bit range on 32 bit machines, so support for 64 bit range was made
>> conditional on a switch (expr -e if memory serves me right ...). So yes,
>> 64 bit range is available on all platforms.
> 
> Hmm, POSIX doesn't require this brokenness for the shell, though it
> requires practically equivalent brokenness for all operands and option-
> arguments generally: it requires "all" integer arithmetic to use
> signed long variables and "all" floating point arithmetic to use double
> variables, with Standard C semantics.  signed long may have any size,
> but normally has 31 or 63 value bits as above.  [...]

Well, 64 bit arithmetic was generally used in expr for 22 months,
(10 July 2000 to 10 May 2002) after I had added support (and range
checks, on your advise ;-) ).

Then Garrett Wollman switched off 64 bit range by default, to be
only optionally enabled by "-e". Then EXPR_COMPAT was made to have
the same effect, and a few months later support for configuration
of a system default by a symlink "/etc/compat-FreeBSD-4-util -> x,y"
where one of the comma separated values that symlink "links to" can
be "expr" to enable expr compat mode (and thus -e). Ain't that ugly?
I have not checked (and being far away from my FreeBSD systems can
not easily check), whether this is still in place in -CURRENT ...
Maybe it is time to be tossed out, since FreeBSD-4 compatibility is
not a big goal in -CURRENT anymore, I assume ...

Anyway, implementation details of expr are far away from the topic
of this thread and I'll let the issue rest. But I'll take a note
to check whether check_utility_compat(3) really exists in -CURRENT
and what use it might have today. It adds startup time to every
single invocation of /bin/sh, test (?) and expr and I doubt that
a lot of people know this feature exists.

Best regards, STefan

--------------------------

Excerpt from SVN log for "expr", showing commits that affected the
64 bit numeric range:

Revision 106065  - (view) (annotate) - [select for diffs]
Modified Mon Oct 28 00:15:43 2002 UTC (7 years, 7 months ago) by wollman
File length: 12834 byte(s)
Diff to previous 96382

Create a small library function, check_utility_compat(3), to determine
whether a named utility should behave in FreeBSD 4.x-compatible mode
or in a standard mode (default standard).  The configuration is done
malloc(3)-style, with either an environment variable or a symlink.

Update expr(1) to use this new interface.


Revision 96382 - (view) (annotate) - [select for diffs]
Modified Sat May 11 03:08:12 2002 UTC (8 years, 1 month ago) by wollman
File length: 12797 byte(s)
Diff to previous 96367

EXPR_COMPAT should imply -e, since there is no way to specify it
otherwise, and -e reflects the historic behavior of FreeBSD's expr.


Revision 96367 - (view) (annotate) - [select for diffs]
Modified Fri May 10 22:59:29 2002 UTC (8 years, 1 month ago) by wollman
File length: 12784 byte(s)
Diff to previous 95278

The response to my POSIX interpretation request says that `expr'
is required to be oblivious to overflow and to use the data type `long'.
(Division by zero is undefined in ISO C so it's still OK to check for it
here.)  Add a new `-e' flag to get the old, more useful behavior.

--------------------------

Revision 62926  - (view) (annotate) - [select for diffs]
Modified Mon Jul 10 21:30:55 2000 UTC (9 years, 11 months ago) by se
File length: 8761 byte(s)
Diff to previous 50471

Extend numeric operations to support 64 bit numbers.


More information about the freebsd-fs mailing list