From owner-freebsd-fs@FreeBSD.ORG Sat Jun 12 12:17:22 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 988371065676 for ; Sat, 12 Jun 2010 12:17:22 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 52CFF8FC1C for ; Sat, 12 Jun 2010 12:17:22 +0000 (UTC) Received: by iwn7 with SMTP id 7so2768066iwn.13 for ; Sat, 12 Jun 2010 05:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=xhE12Tler9mfTf7hv2jzvQaIo7S/bN9OXWeTKiGwpZc=; b=cAaZ1TWSIn6Oj48QufzHobzbmKiX08msW40WQc6nr4HfAgKisP7wnbI7TW49rkAXqT GsF3kebYuq1krZlBZ1gLSP5ovTcC6XrgCkhwGiXNDuKNCWnF1Q+IE5gsMNrvMacR/uCW 2RQcYrcIC4tteRFVnaRLldizsUfKBC6B7kzRk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=bYd7Xa2NbvM8QtW7qwA8cyKYiI36xtFzRQ1Z6RBNDRohpp2GlsrvQ8COyhbkB+wCHK a9lFe8Ew8f7Kfhwf3/sU1H0HZ9CuSh13noccWVxsgUkvPh5oZB7zIORp8AxODGhyrUqa mG0qiUG+j5jQWMfS9bZ0TReEW9RooiLW7Lhd4= Received: by 10.231.168.129 with SMTP id u1mr3302111iby.49.1276345040957; Sat, 12 Jun 2010 05:17:20 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-128-180.dsl.klmzmi.sbcglobal.net [99.181.128.180]) by mx.google.com with ESMTPS id a8sm10195975ibi.11.2010.06.12.05.17.18 (version=SSLv3 cipher=RC4-MD5); Sat, 12 Jun 2010 05:17:19 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C137ACE.9080900@dataix.net> Date: Sat, 12 Jun 2010 08:17:18 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100515 Thunderbird MIME-Version: 1.0 To: Alexander Leidinger 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> In-Reply-To: <20100611104219.51344ag1ah7br4kk@webmail.leidinger.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 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: Sat, 12 Jun 2010 12:17:22 -0000 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 same concerns apply to test(1) (or the corresponding buildin) in the > solution of Artem. > I agree. > By calculating with days everywhere (like in my solution), I'm sure that > it takes longer to hit a wall than by calculating with seconds since > epoch (which can cause a problem in 2038 or during a transition when > this problem is tackled in time_t but not here, which is not that far > away). The off-by-one day once every 4 years shouldn't be a problem. If > someone can assure with some nice facts, that using the seconds since > epoch will not cause problems in the described cases, I have no problem > to switch to use them. I agree with this, please see corrected example above. Another situation that had come to mind is when & certainly being possible that the time on the system could drop to before the last scrub has taken place causing (using the above script for example) todayjul to be less than scrubjul and in that case would output a negative integer that would skew results until the system time has been restored to its correct & current date & time. if [ $todayjul -gt $scrubjul ]; then expired=$(($todayjul-$scrubjul)) else expired=$(($scrubjul-$todayjul)) fi -- jhell