1 |
Am Mon, Dec 13, 2021 at 04:54:30PM -0500 schrieb Rich Freeman: |
2 |
> On Mon, Dec 13, 2021 at 4:42 PM Michael Orlitzky <mjo@g.o> wrote: |
3 |
> > |
4 |
> > On Mon, 2021-12-13 at 22:38 +0100, Frank Steinmetzger wrote: |
5 |
> > > |
6 |
> > > Well I *could* disable run-crons altogether and add entries to fcron’s own |
7 |
> > > crontab which would run those scripts in /etc/cron.{hourly,daily,...} |
8 |
> > > instead. |
9 |
> > > |
10 |
> > > However, I like predictable times at which those jobs will run. Especially |
11 |
> > > if one of them is a zfs scrub; the NAS is powered down for weeks, sometimes |
12 |
> > > months. And when I power it up, it’s for a reason. And that reason usually |
13 |
> > > is not a scrub, which—at the current zfs fill level—takes 10½ hours. |
14 |
> > > |
15 |
> > |
16 |
> > Why choose fcron then? It sounds like you have the same rationale as I |
17 |
> > do: "no, I don't want to run the 4am backup job in the middle of the |
18 |
> > business day just because it wasn't run at 4am." |
19 |
|
20 |
Fair point. |
21 |
Fcron has a serialisation feature, so that for instance updatedb and mandb |
22 |
don’t run at the same time. Me kinda liky. |
23 |
|
24 |
> fcron is perfectly capable of running jobs at either set times or at |
25 |
> loosely-defined intervals that are compensated for if the machine is |
26 |
> off. |
27 |
|
28 |
Indeed, I can say "@monthly * 0 *" to run a monthly job (like the scrub) |
29 |
only at night. *pondering* |
30 |
|
31 |
> Systemd timers can also be set that way, and can also have |
32 |
> limits put on scheduling (daily nominally at 3AM but allowed between |
33 |
> 11PM and 5AM or whatever). Obviously the more expressive the crontab |
34 |
> equivalent is, the more you can tweak it to do what you want it to. |
35 |
|
36 |
I’ve gotten used to systemd on my Arch-based desktops. But the NAS is still |
37 |
on good-ol’ openrc. :) |
38 |
|
39 |
> I'll also note that zfs scrubs checkpoint at shutdown and will |
40 |
> auto-resume where you leave off. |
41 |
|
42 |
That’s a nice bit of knowledge. |
43 |
|
44 |
> If they are involved multiple times |
45 |
> with the default options I think any attempt to scrub something that |
46 |
> is already being scrubbed is just a no-op. Obviously if you don't |
47 |
> want all that IO during the day you'll have to do something more |
48 |
> clever - you can instruct it to pause and resume so you could have a |
49 |
> couple of crontab entries and scripts to do just that. |
50 |
|
51 |
Or, since I am the only user of that system, I could go back to my previous |
52 |
way: just run the scrub manually every other month or so before I go to bed. |
53 |
Because then I know that nothing will interfere with it and it won’t |
54 |
interfere with anything else. |
55 |
|
56 |
-- |
57 |
Grüße | Greetings | Qapla’ |
58 |
Please do not share anything from, with or about me on any social network. |
59 |
|
60 |
This message was written using only recycled electrons. |