Date: Fri, 11 Jun 2010 17:20:33 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: CFT: periodic scrubbing of ZFS pools Message-ID: <20100611172033.42001s90ahe57oe8@webmail.leidinger.net> In-Reply-To: <hut8o7$q2o$1@dough.gmane.org> References: <20100610162629.38992mazf0sfdqg0@webmail.leidinger.net> <hut8o7$q2o$1@dough.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Ivan Voras <ivoras@freebsd.org> (from Fri, 11 Jun 2010 14:04:24 +0200): > On 06/10/10 16:26, Alexander Leidinger wrote: >> Hi, >> >> as there seems to be interest in a periodic script to scrub zpools, I >> modified my monthly-POC into a daily script with parameters for which >> pools to scrub, how many days between scrubs (even different per pool, >> if required), and several error checks (non-existing pool specified, >> scrub in progress). >> >> You can find it at >> http://www.Leidinger.net/FreeBSD/current-patches/600.scrub-zfs >> >> Please put it into /etc/periodic/daily and test it. Possible >> periodic.conf variables are: >> daily_scrub_zfs_enable="YES" >> daily_scrub_zfs_pools="name1 name2 name3" # all if unset or empty >> daily scrub_zfs_default_threshold="<number_of_days>" # default: 30 >> daily_scrub_zfs_<POOLNAME>_threshold="<number_of_days>" >> >> If there is no specific threshold for a pool (= days between scrubs), >> the default threshold is used. > > Fairly good and useful, but could you add a small check of "zpool > status" information before scrubbing that would a) complain LOUDLY AND > VISIBLY if a previous scrub failed and b) skip issuing a new scrub > command if there is such an error, to avoid stressing possibly broken > hardware? Can you please provide an example of such a failed scrub? Things I fixed so far: - use the creation time of the pool if no scrub was done before - rename the script via s/600/800/ (this is a I/O intensive task and we want to have this done late in the periodic run, so that other stuff is not slowed down too much) Bye, Alexander. -- Winning isn't everything, but losing isn't anything. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100611172033.42001s90ahe57oe8>