wismerhill a écrit 2608 commentaires

Ben alors désinstalle baloo.

Heu, est-ce que tu utilise plasma comme environnement de bureau?

Il faut aller dans la "configuration du système" de l'environnement plasma, systemsettings est le nom de la commande (enfin, systemsettings5 pour plasma 5).

Pourtant, sur ma mageia, la partie recherche de la configuration de plasma est fournie directement par le paquet systemsettings, donc ça devrait être disponible dans la section espace de travail.

Si tu recherche directement dans systemsettings, il devrait le trouver.
(ou alors c'est que ce n'est pas installé)

Baloo est le système qui indexe (entre autre) les fichier pour pouvoir faire des recherches basées sur leur contenu.

Si tu fais Alt-F2 et que tu tape baloo dans le champ de recherche de plasma, il devrait te proposer la configuration de la recherche de fichier.

Si tu ne l'utilise pas, tu peux le désactiver (dans systemsettings).

Maintenant que la table partitions a été retrouvée, l'étape suivante est de faire un fsck sur la (les?) partition retrouvée.
Si effectivement seule la table de partition avait été perdue, il ne devrait y avoir aucune erreur dans le système de fichiers.
Après, si tu as des sommes de controle (md5, sha, …) pour les fichiers contenus dans ce disque, utilise-les pour t'assurer que les fichiers ne sont pas corrompus.

Juste pour info (puisque ça ne répond pas à son besoin, vu qu'il veut du quasi temps réel), avec bash (et probablement d'autres shells), ça peut s'écrire plus simplement:

cat log.{60..1..-1} log > log_assemble.txt

Et ces outils ont besoin de l'information en temps réel, c'est un problème s'ils ne voient pas tout de suite les lignes des dernières minutes?
Ça me donne plutôt l'impression que ces données devraient être stockées dans une base de données (pas forcément relationnelle), plutôt que dans un simple fichier de log.

Or ce dont j'ai besoin c'est d'un seul fichier contenant 1 mois glissant.

Je ne comprend pas ce besoin.
Que fais-tu avec ce fichier de log qui exige que tout reste dans un seul fichier?
Pourquoi est-ce que ça ne fonctionnerait pas si les données sont réparties dans plusieurs fichiers aux noms prévisibles?
J'ai l'impression qu'on est dans un cas de Problème XY

A la base je recherchais plutôt une solution du type cat file combiné à un awk pour filtrer les lignes.

Si c'est acceptable de perdre les lignes qui seraient ajoutées pendant que tu est en train de traiter le fichier, ou que tu as un moyen d'empêcher l'ajout de logs pendant le traitement, tu peux effectivement partir sur une solution bourrin comme ça.
Si ces logs sont important, ne fait pas de bricolage et utilise des outils fait pour ça.

que signifie MiO ?

Mébioctet

La partition 1 ne commence pas sur une frontière de cylindre physique. dommage qu'il reste ça !

Ça n'a pas d'importance, ça fait longtemps que cette notion de cylindre n'a plus rien à voir avec la géométrie réelle des disques dur, et n'est conservée que pour la compatibilité avec les (très) vieux systèmes.
La recommandation moderne, c'est plutôt d'alligner les partitions au MiO, ce qui devrait garantir que les blocs du système de fichiers seront alignés avec les blocs physiques du périphérique (ce qui est meilleur pour les performances).

Allez, une quatrième solution, avec la commande smartctl (faisant partie des smartmontools):

smartctl -a /dev/sda

Et si tu veux une jolie interface graphique, il y a gsmartcontrol.

Ça peut être un conseil pertinent si le RAID ne fait que son reshape, parce qu'il va le faire séquentiellement.

Mais si le périphérique est en cours d'utilisation (les FS sont montés et utilisés par des programmes), alors tu va avoir des accès aléatoire qui vont venir s'ajouter à ce beau processus séquentiel, ce qui va te massacrer les performances.

Maintenant, j'aimerai bien que tu m'expliques l'avantage pour un utilisateur moyen (celui qui fait surtout de la navigation web, du mail et quelques documents de bureautique) de la sensibilité à la casse ?

Je ne prétend pas le savoir.

Ça fait très longtemps qu'on peut chercher des fichiers en ignorant la casse (find -iname). Ici il est question d'empêcher la création de plusieurs fichiers dont le nom ne diffère que par la casse.

Cela étant dit, d'après l'article (et j'ai l'impression que les gens dans ce fil de discussion ne l'ont pas lu), c'est une fonctionnalité qui doit être activée explicitement pour chaque répertoire individuel où on le veut, et ce n'est faisable que sur un répertoire vide.

Ou plus récemment le cas de javaEE, dont ils ont "cédé" la gestion à la fondation eclipse, mais ils ont gardé les marques, obligeant à renommer en jakartaEE.
Même les noms de packages ont du changer, parce qu'oracle refuse de céder le préfixe javax. !

je suis sous freeBSD.

Dans ce cas, quel shell utilise-tu?
Vérifie sa documentation pour voir s'il supporte la substitution de processus.

Bash ne corrige rien (ou alors tu as une configuration bizarre de readline), as-tu tapé manuellement (avec tes doigts sur le clavier) cette commande, ou tu as fait un copier/coller sans vérifier?

La réponse de quoi?
De tee ou grep?
Quelle commande as-tu exécute?
Attention qu'il n'y a pas d'espace entre le ">" et la "("

Tee te fait un "branchement" de son entrée vers sa sortie standard et un (ou plusieurs) fichiers.
Si tu veux garder le contenu complet sur la sortie et seulement un sous-ensemble dans le fichier de log, il faut filtrer uniquement dans la branche en question.
Cela peut se faire avec la substitution de processus (je sais que ça fonctionne avec bash, si tu utilise un autre shell, il faut vérifier):

rsync … | tee >(grep 'file has vanished:' > error.log)

C'est factuellement faux.

Pas tout à fait, ça l'était jusqu'à l'arrivée de java 9, mais depuis ils se sont mis à vraiment retirer certaines des API qu'ils déprécient.

Et au passage il tourne plus vite grâce aux amélioration du JIT.

C'est d'ailleurs amusant de voir que d'anciennes bonnes pratiques d'optimisation (par exemple le cas du toArray) sont devenues des contre-optimisations avec les JVM modernes.

Ça ne t'aidera pas pour ton problème actuel, mais je vais réagir à ça:

c'est moi qui avait choisi UEFI pour ne plus être coincé avec le nombre de partitions primaires

UEFI n'a rien à voir là-dedans, c'est une question de partitionnement de ton disque.
C'est vrai que démarrer en UEFI impose (au moins sur un des périphériques de stockage) un partitionnement GPT.
Mais rien ne t'interdit de partitionner tes disques en GPT (ou autre format supporté par Linux) et démarrer en mode legacy, c'est ce que je fais sur mon ordinateur actuel.