Journal Défragmenter une partition FAT32 sous Linux …

Posté par  . Licence CC By‑SA.
Étiquettes :
28
9
mai
2018

Ho putain ce titre de journal, bienvenue dans les années 90 !

Le FAT32 reste, pour notre plus grand malheur, le seul format dont on soit à peu près sûr qu'il soit entièrement utilisable partout. J'utilise donc ce format pour stocker sur clé USB ma collection musicale afin d'en profiter en voiture.
Mais ma voiture semblait bouder certains morceaux, de manière reproductible, sans que je ne comprenne le problème : on entendait une saccade 3, 4, 10 fois sur certains fichiers. TRÈS désagréable. Je supputais un problème avec certains codecs (j'ai du flac et du vorbis, qui sont rarement testés par les fabricants). Mais une idée m'est venue : et s'il s'agissait de fragmentation et que le lecteur de la voiture ne pré-chargeait pas correctement le fichier, provoquant donc des saccades ensuite à la lecture ? Je souffre déjà de problèmes similaires sur un disque dur avec des vidéos en HD ou en UHD, il faut réduire au maximum le nombre d'extent pour que la lecture ne soit pas saccadée… Se peut-il ?

0) Rappel sur ce qu'est la fragmentation

La fragmentation, c'est stocker un fichier en plusieurs parties sur le disque dur au lieu d'un ensemble contigu de blocs. Elle se produit quand un disque devient trop rempli, ou quand le système de fichiers est mal ficelé et ne gère pas correctement certaines opérations.

1) Les outils pour gérer la fragmentation sous linux

C'est simple, y'a pas grand monde… Pour vérifier l'état de fragmentation, il y a filefrag, du paquet e2fsprogs, qui marche pour la plupart des systèmes de fichiers. Et il y a les outils spécifiques à certains systèmes de fichier, btrfs filesystem defragment par exemple.

Et c'est tout. Tristesse

2) Comment corriger…

Ma clé USB a beaucoup de place libre. La fragmentation a du se produire lors de l'import de la collection musicale (j'avais copié jusqu'à 3 dossiers en parallèle). Donc a priori une simple copie de chaque fichier devrait être suffisante en FAT32 (il ne fait pas de copy-on-write…)
Mais j'ai une centaine de fichiers à corriger, dans une grand arborescence… Donc scriptons !

#!/usr/bin/env python3

from pathlib import Path
import re
import shutil
import subprocess
import sys

# /my/beautiful/path/filename: 42 extents found

ffrag_re = re.compile(r".*: (\d+) extents? found$")
FRAGMENT_LIMIT = 5

def get_fragments_count(file_path):
    f_frag = subprocess.check_output(["filefrag", file_path.as_posix()])
    m = ffrag_re.match(f_frag.decode('utf-8'))
    assert(m is not None)
    return int(m.group(1))

def defrag(file_path):
    temp_file = Path(file_path.with_name(file_path.name + '.new'))
    shutil.copy(file_path, temp_file)
    new_frags = get_fragments_count(temp_file)
    if new_frags > FRAGMENT_LIMIT:
        print("New file %s still has too many fragments - %s", (temp_file.as_posix(), new_frags))
        temp_file.unlink()
    else:
        file_path.unlink()
        temp_file.rename(file_path)
        print("New file has %s fragments" % new_frags)

def check_folder(folder, recurse = True):
    for item in folder.iterdir():
        if recurse and item.is_dir():
            check_folder(item)
        else:
            frags = get_fragments_count(item)
            if frags > FRAGMENT_LIMIT:
                print("File %s: TO DEFRAG - %s" % (item.as_posix(), frags))
                defrag(item)
            else:
                #print("File %s: OK" % item.as_posix())
                pass

if __name__ == "__main__":
    if len(sys.argv) != 2:
        sys.exit(1)
    folder = Path(sys.argv[1])
    check_folder(folder)

Ce script est assez basique, je vous laisse rajouter l'aide, le decorum usuel… En gros, on le lance en donnant en paramètre le dossier à défragmenter, il va interroger filefrag pour chaque fichier de chaque dossier récursivement, et si ce fichier a plus de 5 fragments (valeur obtenue par le lancer d'un dé), alors on fait une copie du fichier et l'on écrase l'original. Cela a pour effet de forcer le noyau à créer un nouveau fichier qui ne sera pas fragmenté…

Exemple de sortie :

File /media/snoopy/KINGSTON/Renaud/A la Belle de Mai/07 - Le petit chat est mort.mp3: TO DEFRAG - 108
New file has 1 fragments
File /media/snoopy/KINGSTON/Celtas Cortos - Vamos!/02 - 20 de Abril.flac: TO DEFRAG - 166
New file has 1 fragments

Maintenant il n'y a plus qu'à attendre et écouter, j'espère que le problème ne se produira plus, je déteste qu'on abîme ma musique.

Et n'hésitez pas à reprendre ce script, l'améliorer, en faire des papillotes ou des tee-shirts ou que sais-je ! :)

  • # Intéressant !

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

    Ça explique peut-être le problème que ma mère a dans la même situation avec une clé USB sur un autoradio (il a fallu que j'explique que "non, la clé USB n'est pas rayée" ^^).

    J'aurais jamais pensé que la fragmentation des fichiers pouvaient en être l'origine, à tester pour confirmer.

  • # stockage flash

    Posté par  (Mastodon) . Évalué à 9. Dernière modification le 09 mai 2018 à 14:02.

    Dans le cas d'un stockage flash comme celui de ta clé usb la fragmentation ne doit pas avoir d'impact (ou alors très minime) sur les performances. Derrière la couche filesystem, le chip va de toute façon fragmenter les données via les algorithmes d'égalisation de l'usure des cellules.

    Je suis donc assez sceptique sur le résultat final dans l'autoradio de la voiture. À moins de rouler en Lexus haut de gamme ou équivalent qui isolera au maximum les bruits de roulement, moteur et aéro tu peux te permettre d'encoder les fichiers dans un bitrate bien plus faible. J'applique aussi un paramétrage de compression de la bande (dynamic range compression) comme le font les radios FM pour les médias que je compte écouter dans un environnement hostile à la haute fidélite.

    • [^] # Re: stockage flash

      Posté par  (Mastodon) . Évalué à 4.

      La fragmentation est un pb pour les disques mécanique (il faut du temps pour déplacer des têtes à l'autre bout du disque), mais bcp moins pour du flash où il n'y a plus du tout d'avantages à l'accès linéaire vs l'accès aléatoire.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: stockage flash

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      Normalement, la fragmentation n'est pas un problème avec la mémoire flash, pour laquelle :

      • Les temps d'accès sont identiques quelles que soient les positions des blocs dans le système,
      • L'organisation physique des données peut être très différentes entre ce que voit l'OS et la réalité.

      Cela dit, on trouve des traces de problèmes de fragmentation avec des SSD et NTFS, à priori à cause du niveau d'indirection nécessaire pour retrouver les données si le fichier est trop fragmenté (des blocs qui pointent sur des blocs etc… ce qui allonge la lecture). Mais il y a peu de sources et elles concernent des SSD sous NTFS, le cas d'une clé USB sous FAT32 peut être différent.

      Dans tous les cas :

      (j'avais copié jusqu'à 3 dossiers en parallèle).

      Ça c'est la garantie que tes fichiers sont fragmentés, en plus du fait que c'est probablement plus lent que faire les copies séquentiellement.

      La connaissance libre : https://zestedesavoir.com

      • [^] # Re: stockage flash

        Posté par  . Évalué à 3.

        Je crois avoir déjà lu que même si l'impact est faible il y en a un. Grosso modo (du vague souvenir que j'en ai) pouvoir demander des blocs les plus gros possibles rend plus simple la lecture et plus performante. Mais c'est très loin de ce que demande un déplacement d'une tête de lecture. Tu retrouve même comportement pour la mémoire vive et l'utilisation des huge pages.

    • [^] # Re: stockage flash

      Posté par  . Évalué à 2.

      Réencoder en réduisant la qualité serait faisable, mais bien plus chronophage que la simple copie et ce script de «défragmentation».
      J'aurais du mesurer le temps de lecture d'un fichier fragmenté et d'un fichier non fragmenté pour évaluer la différence, mea culpa. Pour l'instant, sans observation en conditions réelles (je vais pas rouler pour le plaisir de tester une théorie), je note que les fichiers qui se faisaient le plus massacrer par l'autoradio étaient les plus fragmentés. À suivre donc.

    • [^] # Re: stockage flash

      Posté par  . Évalué à 1.

      Il parle d'une clef USB, pas d'un disque SSD.

      • [^] # Re: stockage flash

        Posté par  . Évalué à 3.

        Tu sous-entends que les clés USB, contrairement aux disques SSD, n’ont pas un tel mécanisme de répartition des données pour éviter d’écrire toujours aux mêmes endroits ?

        • [^] # Re: stockage flash

          Posté par  . Évalué à 4. Dernière modification le 14 mai 2018 à 23:05.

          Pas du tout le même profil de perf en tout cas, et une ptite clef USB est à des années lumières d'un bon SSD. Et les algos de wear levelling n'impliquent pas que les accès random n'auront pas de latence supplémentaire par rapport aux accès linéaires.

          Même l'Optane, qui a des perfs qui défoncent la plupart des SSD dans la plupart des workloads, conserve une latence en random par rapport à du linéaire. Faible, certes, mais mesurable. On verra pour l'Optane en DIMM si ça sort un jour, mais en fait même la RAM a cette propriété… :p Faut vraiment atteindre les caches les plus bas pour que ça soit plus le cas.

    • [^] # Re: stockage flash

      Posté par  . Évalué à 8.

      Hé bien je pense que le problème était bien la fragmentation des fichiers. Je viens de faire ~40 minutes de route sur un album que je ne pouvais écouter avant à cause des fichiers qui s'interrompaient, et il n'y a eu aucune forme d'interruption.

      Je pense que le mécanisme de répartition des écritures sur la mémoire flash n'a aucune influence ici. Le lecteur ne doit faire aucune forme de lecture en avance sur le fichier, l'OS ne met pas en cache préventive le fichier, seul le read-ahead au niveau bloc est utilisé, or il n'est pas capable de prendre en compte la fragmentation. Et donc à chaque changement de fragment, on se retrouve avec un véritable accès disque quasi-synchrone, et il suffit d'un peu de latence pour que la lecture en soit impactée.

      • [^] # Re: stockage flash

        Posté par  . Évalué à 5.

        Je pense que le mécanisme de répartition des écritures sur la mémoire flash n'a aucune influence ici.

        Je pense aussi. Je vais essayer d’expliquer, en espérant pas dire de connerie, on me corrigera je l’espère si c’est le cas.

        Ce mécanisme il fonctionne toujours de la même manière, il est « considéré transparent ». Quand on indique les vitesses d’IO c’est en prenant en compte ce mécanisme, qui est activé par défaut (et pas toujours désactivable peut-être ?).

        Alors que la fragmentation du FS ça peut varier beaucoup, de 1 à des tas de fragments. Même s’il n’y a pas un déplacement de tête de lecture il y a forcément plus de calculs, de cycles d’horloge nécessaires, soit au niveau du firmware de la clé, soit au niveau de celui de l’auto-radio.

        • [^] # Re: stockage flash

          Posté par  . Évalué à 2.

          Ce mécanisme il fonctionne toujours de la même manière, il est « considéré transparent ». Quand on indique les vitesses d’IO c’est en prenant en compte ce mécanisme, qui est activé par défaut (et pas toujours désactivable peut-être ?).

          Le wear levelling est totalement transparent au SE et il est justement là pour rendre moins séquentiel les accès, mais je n'ai jamais entendu parler de clef USB avec un firmware pour faire ça…

          • [^] # Re: stockage flash

            Posté par  . Évalué à 1.

            C'est le boulot du controleur présent dans la carte, la "clé" ou le "disque" et bien entendu il y a du controle d'usure

            Ce n'est pas un accès brut à une puce NAND ou NOR (pour lesquels il vaut mieux utiliser des systèmes de fichiers spécialisés comme UbiFS ou F2FS), mais il est certain qu'utiliser une clé USB ou une carte SD pour un OS qui n'est pas en lecture seule comme un LiveCD va être beaucoup moins durable que sur un SSD (à part les anciens en Sata ayant un controleur Sandforce qui se briquent sans raison)

            • [^] # Re: stockage flash

              Posté par  . Évalué à 1.

              Je présume que c'est vraiment très basique, par exemple il n'y a pas besoin de l'opération trim sur les périphériques USB. POur moi le contrôle d'usure consiste surtout à vérifier qu'une puce est encore valable ou pas. Je doute qu'il y ai un algo de répartition à proprement parlé.

              • [^] # Re: stockage flash

                Posté par  . Évalué à 4.

                Sur ces controleurs USB, SD, eMMC ou UFS c'est du dynamic wear leveling. L'algo est basique et ne fait pas un roulement complet des données mais il existe et il y a tout de même une gestion des secteurs morts. Comme je le disais, c'est pas une puce NAND ou NOR brute.

                On est bien évidemment pas au niveau d'un SSD (qui gère aussi SMART en plus du TRIM) mais la dimension du PCB et le prix sont différents.

      • [^] # Re: stockage flash

        Posté par  . Évalué à 2.

        Mon hypothèse est que l'autoradio a une semi-implementation de filesystem pour FAT32. Les manifestations que j'ai vu sont: tri les fichiers par ordre apparamment arbitraire, en fait ça semble être trié par adresse du fichiers

        Du coup si le fichier est fragmenté, un tel système primitif peut aussi partir en sucette

        Il me semble avoir règler mes problèmes de clefs USB pour autoradio avec:
        – rm -rf *
        – cp -r /* .

        En ligne de commande, les gestionnaires de fichiers ont l'air d'avoir tendance à faire des trucs bizarres dans les copies (notamment à propos de l'ordre). My 2 cents

  • # Python

    Posté par  . Évalué à 7.

    Je suis toujours surpris de voir ce genre de choses faites en python quand le shell est plus simple :

    for fragmented ( $(find . -type f -exec filefrag \{\} \+ | awk -F: '!/ [1-5] extent found$/{print $1}') ) do 
    cp "$fragmented" "${fragmented}.tmp" && mv "${fragmented}.tmp" "$fragmented"
    filefrag "$fragmented" | awk -F: '!/ [1-5] extent found$/{print $1}'
done

    Ça économise pas le mv, mais pour le coût que ça a je pense que c'est acceptable.

    • [^] # Re: Python

      Posté par  . Évalué à 10.

      Je suis toujours surpris de voir ce genre de choses faites en python quand le shell est plus simple

      Je ne trouve pas si surprenant que ça de réaliser une opération dans un langage qu'on maitrise (sans qu'il soit nécessairement le plus adapté) plutôt que de se former et de produire un code bancal dans un langage qu'on ne maitrise pas. Au niveau individuel, c'est assez rationnel.

      Par contre, je suis bien d'accord qu'au niveau collectif (communauté du logiciel libre), c'est plus délicat. Publier et faire vivre une communauté autour d'un logiciel qui n'est pas conçu «dans les règles de l'art» dès le départ, c'est toujours assez compliqué. Est-ce que l'autocensure doit être une limite au partage? Parce qu'au fond, il y a fort à parier que la plupart des utilisateurs ne relira pas le code, et ne sera même pas capable de juger si les outils et les méthodes sont pertinentes.

      • [^] # Re: Python

        Posté par  . Évalué à 8.

        C'est quand même un bon moyen d'attirer des commentaires constructifs (comme c'est le cas ici), donc "oui", il faut partager, quitte à parfois se tromper (et surtout dans ces cas-là, je dirais)

      • [^] # Re: Python

        Posté par  . Évalué à 1.

        Oula ! Non il n'est pas du tout question de censurer ou autre !

        Un gars qui fait quelque chose a bien plus de valeur que celui qui commente sans rien faire !

        Voila pour le plus important : écrivez du code comme vous le voulais !!!

        Je ne trouve pas si surprenant que ça de réaliser une opération dans un langage qu'on maitrise (sans qu'il soit nécessairement le plus adapté) plutôt que de se former et de produire un code bancal dans un langage qu'on ne maitrise pas. Au niveau individuel, c'est assez rationnel.

        En fait quand tu as vu le fonctionnement de ton outil (filefrag ici) tu as déjà fait 80% du boulot. En fait tu le fait une fois en ligne de commande (pour voir comment ça fonctionne), tu copie le tout dans un fichier, tu met une variable et tu as déjà un script sympa. Ensuite golfer c'est pour les accros qui veulent faire une pause au travail. J'ai l'impression que le fait d'utiliser python ne vient pas du "c'est ce que je sais faire", mais d'un "si je veux faire propre c'est pas le shell qu'il faut utiliser". Je trouve ça dommage parce que ça ajoute de la complexité.

        • [^] # Re: Python

          Posté par  . Évalué à 9.

          Le problème du shell, c’est que tu fais vite une opération problématique parce que tu as oublié de mettre une variable entre guillemets. Ou autre piège qu'on ne retrouve pas d'autres langages. Du coup, si tu n'as pas l'habitude, tu fais vite de grosses erreurs.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Python

            Posté par  . Évalué à 2.

            Je suis d'accord que le shell a des pièges, mais pour ce genre de choses je préfère un script que je suis capable de relire très facilement (moins de lignes, seulement des opérations simples) qu'un script plus long dans un langage réputé plus sûr mais que je ne relirais pas par TL;DR.

            Mais ça n'est que mon avis de personne qui ne partage pas grand chose, hein !

    • [^] # Re: Python

      Posté par  . Évalué à 7.

      Le but était de partager avec tout le monde, donc j'ai pris python pour aider à la relecture.
      Au passage, ta regexp est incorrecte, c'est extent quand il y en a 1 et extents quand il y en a plusieurs :)

      • [^] # Re: Python

        Posté par  . Évalué à 8.

        Au passage, ta regexp est incorrecte, c'est extent quand il y en a 1 et extents quand il y en a plusieurs :)

        J'ai pas de fichiers fragmentés pour essayer.

        Le but était de partager avec tout le monde, donc j'ai pris python pour aider à la relecture.

        Je trouve justement que ça rend la relecture bien plus compliquée. C'est la version que j'aurais fais moi et c'est la raison qui fait que je ne partage pas ça. C'est juste un trucs que je fais dans ma shell. Pour te montrer une version shell simple et partageable.

        #!/bin/bash

FRAGMENT_LIMIT=5

defragment() {
    cp -- "$1" "$1.tmp" && mv -- "$1.tmp" "$1"
}

nb_fragment() {
    filefrag -- "$1" | cut -d' ' -f2
}

for music in ( $(find "$1" -type f) ) do
    fragment=$(nb_fragment "$music")
    if [[ ${FRAGMENT_LIMIT} -lt $fragment ]] then
        defragment "$music"
    fi
done

        Ça décrit bien ce que l'on veut faire :

        • comment on défragmente un fichier
        • comment on sait combien de fragments composent un fichier
        • on cherche tous les fichiers et s'ils ont plus de FRAGMENT_LIMIT fragments on les défragmente

        On peut ajouter quelques infos mais la base est très lisible sans avoir à gérer de fonction récursive, de sous process (bien sûr c'est juste que c'est transparent), ni même d'expression régulière. Il y a une subtilité dans ma version, l'utilisation du -- pour ne pas avoir de problème dans les cas où tu as un fichier qui commence par "-".

        • [^] # Re: Python

          Posté par  . Évalué à 2.

          Tu peux et passer de fonction récursive en python avec quelque chose comme os.walk, qui va itérer sur les fichier d’une arborescence.

          Dans le monde python, xonsh permet de combiner de meilleur des deux monde en lançant des commandes comme en shell (c’en est un) en écrivant tout le code comme en python

        • [^] # Shell…

          Posté par  . Évalué à 2.

          Il y a une subtilité dans ma version, l'utilisation du—pour ne pas avoir de problème dans les cas où tu as un fichier qui commence par "-".

          Bien vu ! Encore un piège du shell…

          La raison pour éviter le shell autant que possible, c’est bien le temps de déminage et le fait qu’on peut difficilement être sûr qu’on l’a bien terminé.

          « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

          • [^] # Re: Shell…

            Posté par  . Évalué à 2.

            Et tu crois que c'est mieux avec python, ou n'importe quel autre langage ?

            En tout cas pour python, des pièges, yen a pas mal. LEs trucs du genre str(machin pour obtenir la conversion d'un objet en string, ou len(array) pour obtenir la taille d'un tableau, mais de l'autre côté un truc du style mydict.keys() pour obtenir les clés d'un dictionnaire … Ca fait perdre pas mal de temps parce qu'on ne sait jamais dans quel cas est la "bonne" façon de faire. Et il y a d'autres pythonneries du genre bien gavantes.

            • [^] # Re: Shell…

              Posté par  . Évalué à 3.

              Heureusement qu'il y a PowerShell qui va nous sauver !

              /me sort…

          • [^] # Re: Shell…

            Posté par  . Évalué à 5.

            La raison pour éviter le shell autant que possible, c’est bien le temps de déminage et le fait qu’on peut difficilement être sûr qu’on l’a bien terminé.

            Aucun langage ne te garantira ne pas avoir de bug…

            Bien vu ! Encore un piège du shell…

            Ça n'est pas un piège du shell. C'est un piège des options… Si tu lance le programme via un exec de ton langage, tu aura le problème. Tu l'a juste plus souvent en shell parce que tu utilise plus de commande. Je viens de vérifier d'ailleurs avec le script python, tu aura le problème au lancement de filefrag.

    • [^] # Re: Python

      Posté par  . Évalué à 3.

      Un des avantages à utiliser un langage comme Python plutôt que du shell Unix c’est dans le cas où on souhaitera faire évoluer le script. En shell, si ce n’est pas prévu dès le départ il faut souvent tout réécrire.

      Je te rassure : j’aime le shell. Je fais principalement du shell (sh/bash) et du Python (un peu de Perl aussi). Pour moi ce sont clairement deux manières toute à fait distincte d’écrire un programme. En Python je fais de l’objet, en shell c’est pas trop ça :)

      Il ne faut pas être de mauvaise foi… quelqu’un qui ne connaîtrait ni le shell ni le Python (mais connaissant au moins un autre langage), il va mettre beaucoup moins de temps à appréhender le script Python que ton script ta boucle en shell…

      • [^] # Re: Python

        Posté par  . Évalué à 3.

        Un des avantages à utiliser un langage comme Python plutôt que du shell Unix c’est dans le cas où on souhaitera faire évoluer le script. En shell, si ce n’est pas prévu dès le départ il faut souvent tout réécrire.

        Euh .. des trucs qu'on ne peut pas fair évoluer en python, j'en vois des masses chaque mois dans le cadre de mon travail. J'en ai un d'identifié comme devant être réécrit pour devenir maintenable dans les choses que je dois faire, mais c'est tellement mal fichu que je ne sais pas du tout par quel bout le prendre. Et ien souvent, les scripts python "qu'on fait évoluer", c'est juste des copier/coller de blocs avec les modifications faites pour que ça marche dans le cas prévu (les blocs sont copiés-collés du même script, ou c'est des snippets de code récupérés sur le net, de ce fait on a un truc bien moche et bien incohérent difficile à faire évoluer, bien souvent sans tests unitaires ou de non régression fournis).

        Il ne faut pas être de mauvaise foi… quelqu’un qui ne connaîtrait ni le shell ni le Python (mais connaissant au moins un autre langage), il va mettre beaucoup moins de temps à appréhender le script Python que ton script ta boucle en shell

        La mauvaise foi n'est pas là ou tu le crois.

      • [^] # Re: Python

        Posté par  . Évalué à 1.

        quelqu’un qui ne connaîtrait ni le shell ni le Python (mais connaissant au moins un autre langage), il va mettre beaucoup moins de temps à appréhender le script Python que ton script ta boucle en shell…

        Quand tu décide d'outiller autour d'une commande, il y a un probabilité non nul que tu ai déjà utilisé cette commande dans ton shell, que tu ai fais la manip' de défragmentation « à la main » et donc tu as déjà presque tous pour faire le script shell. Il faut ajouter find et cut.

  • # on veut de l'info

    Posté par  . Évalué à 1.

    Salut,
    Je crois avoir le même soucis avec des cartes microSD sur un ipod moddé. Je cherche encore l'origine mais l'histoire de la fragmentation me laisse perplexe. Dans mon cas, j'ai remarqué que le phénomène de saccade intervient aléatoirement dans le temps d’exécution et de l'origine du fichier…

    j'attends le retour d'expérience :)

    • [^] # Re: on veut de l'info

      Posté par  (Mastodon) . Évalué à 3. Dernière modification le 09 mai 2018 à 14:50.

      J'irai plutôt aller voir du côté de la classe de la carte mémoire en question. Elles ne sont pas toutes certifiées pour fournir la même bande passante en lecture et écriture.

      Vérifier aussi l'origine. Il y'a pas mal de contrefaçons sur le marché de la carte mémoire, une carte labellée sandisk class 10 peut provenir d'une obscure usine fabriquant des modèles de qualités inférieure et avoir été achetée chez alibaba/express par ton revendeur.

      • [^] # Re: on veut de l'info

        Posté par  . Évalué à 2.

        Merci du rappel. J'avais oublié la base élémentaire, la contrefaçon.

        • [^] # Re: on veut de l'info

          Posté par  . Évalué à 6.

          Autre petit rappel, pour vérifier que les cartes SD ou clés USB ont bien les caractéristiques annoncées il y a l'outil F3

  • # Histoire de buffer ?

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    Mais ma voiture semblait bouder certains morceaux, de manière reproductible, sans que je ne comprenne le problème : on entendait une saccade 3, 4, 10 fois sur certains fichiers

    Est ce que lesdits morceaux ne dépasseraient-ils pas une certaine taille de fichiers ? Et est-ce que la coupure arrive à intervalle régulier ?

    Je verrais bien la lecture interrompue par l'obligation de lire le fichier morceau par morceau quand le fichier ne tiens pas en entier dans un buffer, avec un code de gestion de ce buffer totalement merdique.

  • # j'ai plus simpe ;

    Posté par  . Évalué à 4.

    copie
    suppression (ou reformatage)
    déplacement ;)

    Bon cela nécessite d'avoir de l'espace disponible, mais c'est simple :P

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: j'ai plus simpe ;

      Posté par  (Mastodon) . Évalué à 2.

      Je pense que le reformatage est obligatoire, sinon tu prends sacrément le risque d'augmenter la fragmentation non ?

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: j'ai plus simpe ;

        Posté par  . Évalué à 4.

        Non, si tu as supprimé tous les fichiers, tous l'espace est disponible et le système n'a aucune raison de fragmenter, il écrira séquentiellement dans l'espace qui est disponible.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 2.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: j'ai plus simpe ;

          Posté par  (site web personnel) . Évalué à 5.

          Attention : sur un un système FAT, chaque suppression de fichier réécris la FAT.

          Si on supprime 100 fichiers la FAT est réécrite 100 fois. Ce n'est pas performant et si il n'y a pas d'intelligence dans la clé USB celle ci peut user prématurément au niveau de la FAT.

          Du coup il vaut mieux formater que supprimer les fichiers. La suppression ne se fait qu'une fois.

          C'est peut être maintenant obsolète. C'est conseil sur la FAT date du temps où j'avais des disquettes :D

          • [^] # Re: j'ai plus simpe ;

            Posté par  . Évalué à 2.

            Je vais surement dire une connerie mais il me semble que effacer un fichier ne doit pas changer grand chose (en dehors du fait des infos de la ou sont les morceaux) a ce qu'il y a sur la cle et surement pas re-ecrire vu que sinon il n'y aurait aucune possibilite de recuperation et pourtant photorec fonctionne pas mal sur le coup.

            Effacer n'efface pas vraiment aujour'hui donc ca ne doit avoir a peu pres aucun effet sur la duree de vie de ta cle non?

            • [^] # Re: j'ai plus simpe ;

              Posté par  . Évalué à 6.

              Je vais surement dire une connerie mais il me semble que effacer un fichier ne doit pas changer grand chose (en dehors du fait des infos de la ou sont les morceaux) a ce qu'il y a sur la cle et surement pas re-ecrire vu que sinon il n'y aurait aucune possibilite de recuperation et pourtant photorec fonctionne pas mal sur le coup.

              Relis bien : damonsieur a dit qu'effacer 100 fois nécessitait de réécrire 100 fois la FAT, et juste la FAT : si ma mémoire est bonne, un effacement de fichier en fat signifie positionner un "?" sur le premier caractère du nom de fichier. Donc faire 100 opérations de suppression vont réécrire 100 fois la zone utilisée par la FAT. Comme un disque est un périphérique bloc, tu n'écris pas juste l'octet modifiés, mais tu lis/modifie/écris le bloc entier pour effectuer l'opération.

  • # Un autre...

    Posté par  . Évalué à 5.

    … plus ancien : https://linuxfr.org/news/shake-un-d%C3%A9fragmenteur-pour-gnulinux

  • # J'ai un doute

    Posté par  (site web personnel) . Évalué à 3.

    J'ai un doute aussi sur la fragmentation, j'ai le même problème dans ma voiture mais je n'ai pas rebranché la clé sur un ordinateur depuis 2 ans et j'imagine que ma voiture n'écrit pas dessus.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.