From owner-freebsd-fs@FreeBSD.ORG Tue Jun 15 14:55:59 2010 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E80E9106566C for ; Tue, 15 Jun 2010 14:55:59 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id C1F1F8FC1C for ; Tue, 15 Jun 2010 14:55:58 +0000 (UTC) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o5FDAhjT007155 for ; Tue, 15 Jun 2010 23:10:43 +1000 Received: from c122-106-175-69.carlnfd1.nsw.optusnet.com.au (c122-106-175-69.carlnfd1.nsw.optusnet.com.au [122.106.175.69]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o5FDAaVv021171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jun 2010 23:10:38 +1000 Date: Tue, 15 Jun 2010 23:10:36 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Stefan Esser In-Reply-To: <4C173693.9020603@FreeBSD.org> Message-ID: <20100615221954.R38827@delplex.bde.org> References: <20100609162627.11355zjzwnf7nj8k@webmail.leidinger.net> <4C0FAE2A.7050103@dataix.net> <4C0FB1DE.9080508@dataix.net> <20100610115324.10161biomkjndvy8@webmail.leidinger.net> <20100610173825.164930ekkryr5tes@webmail.leidinger.net> <4C1138D0.7070901@dataix.net> <20100611104219.51344ag1ah7br4kk@webmail.leidinger.net> <4C137ACE.9080900@dataix.net> <20100615095330.89843jrd13kffdkw@webmail.leidinger.net> <4C173693.9020603@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexander Leidinger , fs@freebsd.org Subject: Re: Do we want a periodic script for a zfs scrub? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 14:56:00 -0000 On Tue, 15 Jun 2010, Stefan Esser wrote: > Am 15.06.2010 09:53, schrieb Alexander Leidinger: >> Quoting jhell (from Sat, 12 Jun 2010 08:17:18 -0400): >> >>> On 06/11/2010 04:42, Alexander Leidinger wrote: >>> : #!/bin/sh >>> : >>> : lastscrub=$(zpool history exports |grep scrub |tail -1 |cut -f1 -d.) >>> : todayjul=$(date -j -f "%Y-%m-%d" "+%j" $(date "+%Y-%m-%d")) >>> : scrubjul=$(date -j -f "%Y-%m-%d" "+%j" $lastscrub) >>> : >>> : echo $lastscrub Last Scrub From zpool history >>> : echo $todayjul Today converted to julian >>> : echo $scrubjul Last scrub converted to julian >>> : >>> : expired=$(($todayjul-$scrubjul)) >>>> >>>> Apart from the fact that we can do this with one $(( ))... what happens >>>> if/when time_t is extended to 64 bits on 32 bit platforms? Can we get >>>> into trouble with the shell-arithmetic or not? It depends upon the >>>> bit-size of the shell integers, and the signedness of them. Jilles (our >>>> shell maintainer) suggested also to use the seconds since epoch and I >>>> asked him the same question. I'm waiting for an answer from him. >>> >>> I do not think this would be a problem for the script as the script is >>> relying on date for the conversion except for the subtraction that is >>> taking place. >>> >>> If there was a problem then I would believe it would have to be >>> corrected in date(1) & possibly sh(1), I could be wrong though. >> >> The question is if the integer arithmetic in shell is supposed/allowed >> to handle 64bit unsigned integers on 32bit machines or not. Of course it is not required. It is not required even on 64-bit machines. Only signed long integer arithmetic is required in POSIX.1-2001. signed long may have any size with >= 31 value bits. Thus only 31 value bits and 1 sign bit are required on all machines. Longs should be twice as long as the register width on all machines, so they should be 64 bits on 32-bit machines and 128 bits on 64-bit machines, but this is normally broken; normally, 32-bit machines normally have 32-bit longs with 31 value bits, while 64 bit machines normally have 64-bit longs with 63 value bits; thus the shell normally handles only 31-bit unsigned integers on 32-bit machines and 63-bit unsigned integers on 64-bit machines. time_t may have any arithmetic type in C90/99 or POSIX (with POSIX's broken representation in POSIX and any representation in C), but it is normally signed integer, so if it is extended to 64 bits then it probably wouldn't need 64-bit unsigned integers anyway. > 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. It is unclear how a variable can ever be floating point. Then it contradicts^Woverrides "all" with certain extensions for the shell. However, these extensions are almost useless since they mainly make a difference when the signed long arithmetic would overflow, in which case the behaviour is undefined (?) so it can DTRT using any extension that it wants. Bruce