On Fri, Oct 16, 2020 at 09:03:26AM +0200, Pierre Maitre wrote:
> Le jeu. 1 oct. 2020 à 11:47, felix a écrit :
>
> >(Nota: je préfère ``tirer les données depuis la machine de backups'',
> > plutôt que d'avoir un accès à la machine de backups depuis une
> > machine en production
Le sam. 17 oct. 2020 à 11:09, felix a écrit :
>
> C'est donc l'inverse, dans ce que tu décris, la machine en prod **accède**
> au backup pour **initier** la synchronisation!?
Alors j'ai mal décrit? Chez moi c'est bien la machine de backup qui va
tester si la machine à backuper est allumée et qui
> On Fri, Oct 16, 2020 at 09:03:26AM +0200, Pierre Maitre wrote:
> > le backup est initié sur le serveur, la machine à backuper peut être
> > éteinte.
>
> C'est donc l'inverse, dans ce que tu décris, la machine en prod **accède**
> au backup pour **initier** la synchronisation!?
Au temps pour moi
Au fait, voici une ligne qui figure facilement au début de ces scripts bash:
#!/bin/bash
(( $(nice) < 19 )) && exec nice -19 ionice -c 3 $0 "$@"
Ceci re-démarre le script avec un niveau de priorité os et fs abaissé,
afin de conserver un maximum de disponibilité aux tâche *normales* de
la mac
On Sat, Oct 17, 2020 at 01:41:59PM +0200, felix wrote:
> (( $(nice) < 19 )) && exec nice -19 ionice -c 3 $0 "$@"
>
> Ceci re-démarre le script avec un niveau de priorité os et fs abaissé,
Attention, j'ai l'impression que sur les kernels modernes, le scheduler
I/O classique (celui qui était infl
Bonsoir,
Je suis tombé sur un étrange problème qui en cascade a engendré le fait
que je ne peux plus booter un système.
J'étais en train de faire une mise-à-jour et, soudain, celle-ci s'est
plantée avec un message disant que mon file-system était en read-only
(comme ça soudainement). La maj
