Des systèmes de fichiers pour périphérique amovible

Posté par  (site web personnel) . Édité par patrick_g, Julien Jorge, Ysabeau 🧶 🧦 et Benoît Sibaud. Modéré par Julien Jorge. Licence CC By‑SA.
68
23
avr.
2021
Administration système

Lorsqu’on formate un périphérique amovible, le choix du système de fichiers est dicté par des contraintes particulières, en particulier la possibilité de le lire depuis des systèmes d’exploitation moins polyvalents que GNU/Linux. Les systèmes de propriétés et de permissions peuvent également être un obstacle dans un tel contexte, puisqu’on peut se retrouver à ne pas pouvoir modifier un fichier créé depuis un autre ordinateur avec un utilisateur différent de celui qu’on utilise.

Voici donc un petit état des lieux.

Sommaire

Résumé

Si vous comptez utiliser votre périphérique uniquement depuis GNU/Linux et que vous aimez jouer en ligne de commande, formatez-le en ext4 s’il s’agit d’un disque dur, ou en F2FS s’il s’agit d’un périphérique flash (clef USB, SSD ou carte SD).

Sinon, s’il s’agit d’une clef USB où vous n’envisagez pas de stocker des fichiers de plus de 4 Gio, formatez-la en FAT32.

Sinon, si vous comptez utiliser votre périphérique amovible depuis d’autres ordinateurs qui ne tournent pas sous GNU/Linux, formatez-le en exFAT.

Voici un tableau récapitulatif des caractéristiques des principaux systèmes de fichiers utilisables sur périphérique amovible. Par « unixeries », j’entends le support de fichiers spéciaux (surtout les liens symboliques, mais également les nœuds de périphérique, les sockets Unix et les tubes nommés) et les notions de propriétaire et de permissions. Je mentionne également la possibilité de créer des fichiers sans propriétaire défini ou d’émuler cela à coup d’ACL, pour éviter des problèmes de permissions entre différents ordinateurs (voir le paragraphe Notes).

Fonctionnalité Ext2/3/4 F2FS FAT32 NTFS exFAT UDF
Lisible sous Linux
Lisible sous MacOS ro ~
Lisible sous Windows
Unixeries
Fichiers sans propriétaire via ACL via ACL
Adapté aux flash
Ouvert ou documenté
Brevets problématiques

Notes

Le scénario est le suivant : sur un premier ordinateur, en tant qu’utilisateur mrobin:1042, vous créez un fichier sur une clef USB ; après l’avoir branchée sur un autre ordinateur, vous essayez de modifier ce même fichier en tant qu’utilisateur roxane:1001, et vous vous prenez une belle erreur parce qu’il n’est modifiable que par l’utilisateur numéro 1042.

Ext2, ext3, ext4

Ces systèmes de fichiers, créés pour Linux, sont également lisibles de façon native sous FreeBSD. Sous MacOS et Windows, il faut installer un pilote spécifique, ce qui est assez rédhibitoire pour un périphérique amovible.

En matière de fonctionnalités, ces systèmes de fichiers implémentent évidemment toutes les notions unixiennes.

Pour les périphériques à base de flash, il est pertinent de créer un système de fichiers sans journal, avec mkfs.ext4 -O ^has_journal.

Création d’un système de fichiers :

mkfs.ext4 -O ^has_journal -L "Clef USB de Cyrano" /dev/sdc1

F2FS

Le Flash-Friendly File System a été créé par Samsung pour les cartes mémoires de leurs téléphones sous Android, donc pour Linux. Il a donc été conçu pour être utilisable sur des périphériques flash, y compris des clefs USB ou des SSD.

S’agissant d’un système de fichier conçu pour Linux, il prend évidemment en charge toutes les subtilités unixiennes.

Création d’un système de fichiers :

mkfs.f2fs -l "Clef USB de Cyrano" /dev/sdc1

FAT32

FAT32 est un système de fichier assez ancien, créé par Microsoft pour Windows 95. Techniquement, ce système de fichiers est utilisé avec une bidouille nommée VFAT, pour permettre d’utiliser des noms de fichiers un peu plus libres que le format 8.3 (huit caractères, puis un point, puis trois caractères) initialement prévu.

Ce système de fichiers est assez ancien pour ne plus être couvert par des brevets encore valides. Il a l’avantage d’être pris en charge partout, c’est pourquoi il est largement utilisé sur les clefs USB et cartes SD.

Il est en revanche franchement déficient, avec des limitations majeures :

  • conçu pour MS-DOS et Windows 95, il ne permet pas de stocker des fichiers spéciaux (liens symboliques, périphériques, sockets et tubes nommés), et n’implémente aucune notion de propriété, bien qu’il fournisse une notion rudimentaire de permissions ;
  • le nom de volume ne peut pas dépasser 11 caractères ;
  • il ne permet pas de stocker de fichiers de plus de 4 Gio.

Création d’un système de fichiers :

mkfs.fat -n "Clef Cyrano"

NTFS

NTFS est un système de fichiers créé par Microsoft pour Windows NT. Il est utilisé comme système natif par les systèmes Windows actuels.

Il est également lisible nativement sous MacOS, mais il faut installer un pilote propriétaire spécifique pour pouvoir le monter lecture-écriture. Sous GNU/Linux, et visiblement sous FreeBSD, il est pris en charge en lecture-écriture par le pilote en espace utilisateur ntfs-3g.

Ce système de fichier n’implémente pas les subtilités unixiennes de fichiers spéciaux, de propriété et de permissions. Il dispose d’un système de propriété et de permissions à la sauce Windows, normalement inutilisés sous Linux.

Création d’un système de fichiers :

mkfs.ntfs -L "Disque dur externe de Cyrano" /dev/sdc1

exFAT

exFAT est le dernier né de la famille de fichiers FAT de Microsoft, qui règle quelques limitations de FAT32, notamment le stockage des gros fichiers.

Ce système de fichier fermé et soumis à des brevets, mais Microsoft en a finalement publié les spécification et a donné ses brevets à l’Open Invention Network en 2019. Il s’agit donc maintenant d’un format ouvert sans brevets qui pourraient poser problème. Cela a notamment permis l’intégration d’un pilote exFAT dans le noyau Linux.

En pratique, ce système de fichier est pris en charge par tous les systèmes d’exploitation relativement récents, et il est d’ailleurs utilisé sur les cartes SD de grande capacité.

Il souffre de limitations héritées de FAT32, à savoir :

  • il ne permet pas de stocker des fichiers spéciaux et n’implémente pas les notions de propriété et de permissions unixiennes ;
  • le nom de volume ne peut pas dépasser 11 caractères.

Création d’un système de fichiers :

mkfs.exfat -L "Clef Cyrano" /dev/sdc1

UDF

L’Universal Disk Format est un système de fichiers normalisé par l’ISO, et est surtout utilisé sur les DVD. Il est, pour cette raison, pris en charge partout, et tout à fait utilisable sur des supports non optiques, à une époque je le recommandais même pour les clefs USB.

Malheureusement, ce n’est pas si parfait :

  • sous MacOS, la dernière fois que j’avais pu l’essayer, on ne pouvait monter une clef USB formatée en UDF que depuis un terminal ;
  • sous Linux, le support UDF est assez rudimentaire : on constate parfois des débits d’écriture pitoyables, et il n’existe pas de fsck.udf par exemple.

C’est dommage, parce que ce système de fichiers a pas mal d’avantages :

  • il prend en charge toutes les subtilités unixiennes ;
  • il dispose d’une notion de fichier au propriétaire non spécifié, qui sous Linux apparaît comme appartenant à celui qui a effectué le montage, ce qui est parfait pour un support amovible.

Création d’un système de fichiers :

mkudffs -l "Clef USB de Cyrano" /dev/sdc1

Aller plus loin

  • # Correction pour NTFS

    Posté par  . Évalué à 10. Dernière modification le 23 avril 2021 à 18:57.

    Un pilote NTFS complet avec lecture/écriture est en cours d'intégration dans le noyau.
    Il n'a pas passé la fenêtre du 5.12, peut-être en 5.13.
    La série de patch en est à la version 27 : https://lore.kernel.org/lkml/20210402155347.64594-1-almaz.alexandrovich@paragon-software.com/

    • [^] # Re: Correction pour NTFS

      Posté par  . Évalué à 2.

      Ntfs est possible en écriture sous macOS. Même principe que Linux il faut utiliser ntfs-3g

      • [^] # Re: Correction pour NTFS

        Posté par  . Évalué à 3.

        Oui mais est-ce-que ntfs-3g est installé sur la majorité des MacOS ? Alors que la majorité des distributions Linux Desktop vont l'intégrer.
        Si on compte l'installation de logiciels tiers, non intégrés de base, il faut changer les résultats pour Windows aussi puisque des pilotes pour ext sont disponibles…

        • [^] # Re: Correction pour NTFS

          Posté par  . Évalué à 3.

          Alors la présence de ntfs-3g sur mac… Honnêtement je ne sais pas si il est très répandu ou pas.
          Apres je suis d'accord si on prend ce qui est natif dans les OS… Le tableau est correct.
          Mais pour linux, ntfs-3g n'est pas présent par défaut dans toutes les distributions également.
          Quant à windows effectivement on peut ajouter du ext, mais je n'ai jamais trouvé ces solutions propres. Quand on a l'écriture d'ext sous windows on peut faire de gros dégâts dans le système Linux contenu.

          • [^] # Re: Correction pour NTFS

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

            Quant à windows effectivement on peut ajouter du ext, mais je n'ai jamais trouvé ces solutions propres. Quand on a l'écriture d'ext sous windows on peut faire de gros dégâts dans le système Linux contenu.

            J'avais utilisé il y a plus de 20 ans ce logiciel Windows qui permettait d'aller dans le disque ext. C'est très risqué en cas de fausse manœuvre et pire, c'est un gigantesque trou de sécurité.
            Depuis 2000, je n'ai plus de Windows installé, je m'en porte fort bien ! Je n'ai donc plus aucun besoin de ce logiciel.

      • [^] # Re: Correction pour NTFS

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

        Petite correction, il n'est pas nécessaire d'ajouter quoi que ce soit pour que macOS puisse écrire sur du NTFS, il suffit de modifier le fichier /etc/fstab.

        Voir ce lien : https://gist.github.com/CharlesThierry/7305166b208d6f6cdd37962761d5ac23

        L'étape UUID, il est tout à fait possible de passer par le LABEL=nom et tout se passe correctement.

        La petite subtilité, est que l'option nobrowse (qui semble nécessaire par expérience) fait que le Finder n'affiche plus le périphérique, mais il "suffit" d'aller dans /Volumes et on trouve notre périphérique, monté en écriture, et qui fonctionne très bien.

    • [^] # Re: Correction pour NTFS

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

      Très bonne nouvelle !

      Pour info, mais vous l'aurez déjà deviné, mon tableau indique ce qui est faisable directement, ou du moins très facilement, avec les différents systèmes d'exploitation. Autant que je sache, ntfs-3g est déjà installé, ou très facile à installer, sur les distributions GNU/Linux majeures, mais n'est pas préinstallé sous MacOS.

  • # Et quand ce n’est pas un ordinateur ?

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

    Bonne information à la quelle il manque pour moi une catégorie de nos vies courantes numériques : Les appareils qui ne sont pas les ordinateurs.

    Ces matériels, qui reviennent à de l’informatique embarqué n’implémentent, suivant le soin des fabricants, qu’une partie des protocoles de gestion de ces périphériques. Ce qui pose parfois quelques problémes.

    Pour ceux qui enregistrent des données, tel que les appareils photos numériques, ils proposent souvent une option de formatage pour utiliser le format qui leur va bien, et je leur dédie une ou plusieurs carte mémoire suivant les usages.
    L’ordinateur ne les utilisant finalement qu’en lecture quand l’appareil le permet, ce qui évite de le perturber.

    L’usage ou cela est plus flou est les appareils qui vont lire les données écrite par un ordinateur : Un lecteur de musique qui va lire les morceaux à partir d’une clef USB (Autoradio, chaine HiFi, lecteur portable, …).
    Ici c’est bien l’ordinateur qui va fournir les informations, en toute connaissance des protocoles, et le périphériques qui va les lire, avec parfois ces particularités.

    Je prendrais l’exemple de l’autoradio qui équipe ma voiture (que dans un soucis d’écologie j’utilise de façon de plus en plus raisonnée - Mais c’est un autre débat).
    Pour éviter les problèmes de lecture j’ai du appliquer les principes suivants :
    - Preparer et écrire en une seule fois linéaire les morceaux. Un espace de stockage qui est fragmenté pose des soucis de lecture des morceaux.
    - Utiliser un format de fichier le plus passe partout possible : Fat32 je crois …
    - Bloquer le périphérique en lecture seul. Probablement un bug de ce matériel spécifique, mais au bout d’un certain nombre d’heure d’utilisation le système se bloque. Restaurer une image identique sur le même périphérique de stockage résous le probléme.
    Sur ce point un lecteur de carte SD USB, avec une carte SD bloqué en lecture seul as résolu le problème.
    Je suppose que le système doit d’une façon ou d’une écrire sur le périphérique au point de se perturber lui même.
    Hors astuce de la carte SD … je ne saurais comment faire.

    Mais ce sujet mériterais probablement bien plus que mes bafouilles matinales.

    • [^] # Re: Et quand ce n’est pas un ordinateur ?

      Posté par  . Évalué à 6.

      Ça me fait penser que moi qui ai l'habitude d'utiliser UDF sur mes clefs, j'ai fais crasher violemment une imprimante pro en lui branchant ma clef USB.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Et quand ce n’est pas un ordinateur ?

      Posté par  . Évalué à 7.

      que dans un soucis d’écologie j’utilise de façon de plus en plus raisonnée

      OK c'est un autre débat mais je ne comprends pas le lien entre l'utilisation de l'autoradio et l'écologie. C'est pour ne pas utiliser la batterie (mais sauf erreur elle est rechargée par l'alternateur quand on roule, sauf peut-être sur les modèles électriques) ?

      • [^] # Re: Et quand ce n’est pas un ordinateur ?

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

        M’est avis que ce n’est pas de l’autoradio dont il est question ici, mais de la voiture qui est autour ;)

        • [^] # Re: Et quand ce n’est pas un ordinateur ?

          Posté par  . Évalué à 5.

          OK, j'ai honte… Je relis la phrase et je ne sais pas trop comment j'ai fait pour comprendre de travers. Vais utiliser la pirouette imbattable : "je sais, c'était de l'humour".

        • [^] # Re: Et quand ce n’est pas un ordinateur ?

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

          Je confirme que c’est bien le véhicule dont je limite l’utilisation :)

          Dans l’absolu utiliser l’autoradio impliquera plus de consommation de carburant, via les multiples jeux de conversion d’énergies.
          Je ne sais pas quel est l’impact sur la consommation, mais je doute qu’il soit élevé, et qu’il doit y avoir d’autres méthodes plus performantes que de couper la musique, pour limiter sa consommation au volant.

          • [^] # Re: Et quand ce n’est pas un ordinateur ?

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

            Dans un véhicule à moteur thermique, en effet, le moindre watt électrique utilisé provient de la combustion du carburant, via l'alternateur, dont la résistance à la rotation augmente d'autant lorsqu'on consomme du courant. :-)

            Le seul accessoire qui n'augmente pas la consommation, c'est le chauffage !

            • [^] # Re: Et quand ce n’est pas un ordinateur ?

              Posté par  . Évalué à 3.

              la rotation augmente d'autant lorsqu'on consomme du courant

              Hum ? Il y a une augmentation de la fréquence de rotation pour aligner la production à la consommation, mais je suis surpris que ça ai une influence directe sur le champ magnétique de la bibine.

              De plus je ne serais pas aussi catégorique parce que je ne sais pas si le couplage consommation/production et si bien aligné que ça. Est-ce qu'il n'y a pas une surconsommation générale qui est diminuée lors de l'utilisation de l'autoradio ? Est-ce que l'autoradio ne consomme pas simplement une légère partie de l'énergie habituellement envoyée à la batterie ?

              Je suis très loin d'avoir le niveau en électricité et dans le fonctionnement d'une voiture pour vérifier.

              Par contre c'est un épiphénomène, la consommation lié aux phares, autoradio, etc doit être minime face à l'énergie nécessaire pour déplacer 1t sur des dizaines de km. Ce n'est qu'une démarche intellectuelle et pas une démarche écologique.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: Et quand ce n’est pas un ordinateur ?

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

                Ah, je ne sais pas, en tout cas, la notice de ma voiture, une Twingo 2, indique ceci :

                CONSEILS : antipollution, économies de carburant, conduite

                [Des trucs sur l'entretien du moteur et la conduite économique]

                Conseils d’utilisation

                L’électricité « c’est du pétrole », éteignez tout appareil électrique lorsqu’il n’est plus vraiment utile. Mais (sécurité d’abord), gardez vos feux allumés dès que la visibilité l’exige (voir et être vu).

                […]

                Pour les véhicules équipés du conditionnement d’air, il est normal de constater une augmentation de la consommation de carburant (surtout en milieu urbain) durant son utilisation. Pour les véhicules équipés d’un conditionnement d’air sans mode automatique, arrêtez le système lorsque vous n’en avez plus l’utilité.

                Si l'usage de l'autoradio entraîne une surconsommation, je suis d'accord sur le fait qu'elle est évidemment minime, comparée à la consommation de base pour rouler, et à celle des feux ou du climatiseur.

                Sur une bicyclette équipée d'une dynamo de moyeu, je peux vous confirmer qu'allumer les feux entraîne une résistance à la rotation de la roue concernée. Avec les feux éteints, la dynamo crée simplement un effet de crantage de la rotation, mais pas de résistance notable.

              • [^] # Re: Et quand ce n’est pas un ordinateur ?

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

                Oui, dans un véhicule thermique, plus on demande d’électricité, plus cela consomme du carburant.
                De façon générale l'électricité est produite est consommé sur le même instant (d'autant plus à l'échelle d'une voiture)

                Une génératrice électrique (ici notre alternateur, mais c’est aussi le cas d’une dynamo) va transformer une vitesse de rotation et un «couple» qui constitue une puissance mécanique en une puissance électrique décomposé en tension et courant.

                La tension dépend de la vitesse de rotation de la génératrice.
                Les voitures modernes ayant des régulateurs qui stabilisent cette tension autour de 13,6 volts (même si on parle souvent de « 12 volts » dans les voitures).

                Si la tension est fixée par le générateur, le courant est lui consommé par les appareils (plus ou moins gourmands).
                Le courant va agir sur le couple. Plus on demande de courant à une génératrice, plus il va y avoir une résistance à la rotation.
                Le moteur, ici thermique (mais c’est la même chose avec un cycliste et sa dynamo), ayant besoin de fournir plus de puissance pour maintenir la vitesse, et donc la tension électrique.

                --
                Moteur tournant, on peut se passer de batterie dans une voiture thermique.
                Elle n’est à ce moment-là qu’un consommateur comme un autre, tant qu’elle n’a pas fait le plein. L’alternateur est suffisant pour fournir l’ensemble de la consommation électrique du véhicule.

                Pourquoi avoir une batterie alors ?
                Pour démarrer le moteur !

                Un moteur thermique n’est pas autonome pour se lancer, il faut un autre système pour lui faire faire ces premiers tours.
                C’est le Kick-Starter sur les motos, le cordon à tirer sur les tondeuses ou la manivelle sur les voitures, remplacé par le bien plus pratique moteur électrique… qui as besoin d’électricité qu’il va puiser dans la batterie.

                Accessoirement cette batterie peux servir à alimenter du matériel électronique à bord quand le moteur est arrête.

                • [^] # Re: Et quand ce n’est pas un ordinateur ?

                  Posté par  . Évalué à 5.

                  Pourquoi avoir une batterie alors ?
                  Pour démarrer le moteur !

                  Pas que.
                  La voiture est remplie d'accessoires et de moins-accessoires dépendant de l'électrique : essuie-glace (niveau élec c'est minable), phares (déjà un peu moins), vitres électriques, direction assistée (selon les modèles, mais ça c'est pas accessoire)…
                  Et du coup, petit vécu sur une voiture tchutchutpademarque : de nuit, en prenant un virage, la direction assistée s'est soudain coupée et je me suis en plein virage retrouvé en direction insistée. Après 2 aller-retour au garage où diverses pièces ont été changées, j'ai fini par trouver une solution pour qu'ils puissent reproduire le problème à l'arrêt, et donc je leur ai déposé le véhicule avec comme mission "vous me rendez la voiture sans ce comportement" : à l'arrêt, moteur allumé (mais pas au ralenti, il fallait un certain nombre de tours/min de mémoire), autoradio allumé, mettre le volant en butée, et avec les fenêtres fermées actionner la fermeture des fenêtres. C'est le chemin le plus court pour maximiser la consommation électrique, et ça faisait sauter immédiatement la direction assistée.
                  Et le coupable était la batterie qui ne faisait plus son taf correctement dans ces conditions.

                  Depuis, plus de tchutchutpademarque…

                • [^] # Pollueur

                  Posté par  (site web personnel) . Évalué à 2. Dernière modification le 26 mai 2021 à 18:33.

                  « Moteur tournant, on peut se passer de batterie dans une voiture thermique.
                  Elle n’est à ce moment-là qu’un consommateur comme un autre, tant qu’elle n’a pas fait le plein. L’alternateur est suffisant pour fournir l’ensemble de la consommation électrique du véhicule. »

                  Ça n'est vrai que pour les moteurs à auto ignition du mélange carburant/comburant ; en pratique les moteurs à cycle ~Diesel où c'est la pression engendrée par la remontée du piston qui déclenche la combustion. Les moteurs à cycle ~Beau de Rochas eux utilisent des bougies qui ne s'allument généralement que si la batterie leur fournie la tension nécessaire. D'où le titre pollueur, bien dans l'esprit du temps, stigmatisant, mais pas très sérieux : d'un point de vue strictement énergétique, il semblerait que les moteurs au gazole soient plus efficaces que leurs homologues au sans plomb pour nos véhicules automobiles.

                  PS : Pour avoir expérimenter les deux, je recommande la panne électrique sur véhicule Diesel. Détectée en cours de trajet elle permet de se rendre chez le garagiste de son choix sans passer par l'onéreuse case dépanneuse. Alors que le moteur qui se coupe subitement sur l'autoroute…

                  « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

            • [^] # Re: Et quand ce n’est pas un ordinateur ?

              Posté par  . Évalué à 2.

              Dans un véhicule à moteur thermique, …
              Le seul accessoire qui n'augmente pas la consommation, c'est le chauffage !

              Après un hiver avec une Toyota, je m'aperçois que c'est faux sur une hybride. Il est nécessaire de faire tourner le moteur thermique pour chauffer la voiture en début de trajet … (ça se calme par la suite).
              d'où une certaine surconsommation bien sensible sur les trajets courts.

              • [^] # Re: Et quand ce n’est pas un ordinateur ?

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

                Et d'une façon générale, je ne suis quand même pas sûr que le chauffage ne consomme vraiment rien.

                Pour les alternateurs de moyeu de vélos, la différence est nette avec une Son, réputée celle qui en a le moins, mais j'observe aussi des écarts d'un modèle à l'autre(ou j'ai plutôt l'impression que c'est lié au montage sur la roue/le vélo)

                Par contre bizarrement, il parait qu'un des modèles phares de chez Shimano est plus fluide avec la lampe allumée qu'éteinte !

                • [^] # Re: Et quand ce n’est pas un ordinateur ?

                  Posté par  (site web personnel) . Évalué à 7. Dernière modification le 26 avril 2021 à 17:41.

                  Et d'une façon générale, je ne suis quand même pas sûr que le chauffage ne consomme vraiment rien.

                  Sur un véhicule à moteur purement thermique, le chauffage est gratuit. En fait, le moteur chauffe naturellement et a toujours besoin d'être refroidi. Il y a pour cela un circuit de refroidissement, dans lequel circule de l'eau, qui devient brûlant après avoir refroidi le moteur, puis passe dans un radiateur, où elle est refroidie par l'air ambiant qui circule naturellement lorsqu'on roule, et qui circule de force avec l'aide d'un ventilateur si ça ne suffit pas.

                  Lorsqu'on allume le chauffage, l'air qui a servi à refroidir l'eau du circuit de refroidissement est simplement envoyé dans l'habitacle. C'est gratuit, en revanche ça ne fonctionne pas immédiatement après démarrage, il faut que le moteur ait déjà chauffé un peu.

                  • [^] # Re: Et quand ce n’est pas un ordinateur ?

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

                    Si on veut être puriste, c’est la production de chaleur sur un véhicule thermique qui ne coûte rien. La chaleur étant un déchet de fonctionnement que l’on peut recycler pour faire du chauffage de l’habitacle (et c’est même un problème dans les voitures électriques, dont le moteur crée moins de déchets en chaleur).

                    Mais même si on reste sur un chauffage simple sans électronique de contrôle (et de régulation), il reste malgré tout la consommation électrique de la ventilation pour diffuser la chaleur dans l’habitacle.

  • # Résumé

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

    Sinon, s’il s’agit d’une clef USB où vous n’envisagez pas de stocker des fichiers de plus de 4 Gio, formatez-la en FAT32.

    Pourquoi pas exFAT dans ce cas aussi? Je ne vois pas l'avantage de FAT32 par rapport a exFAT

    • [^] # Re: Résumé

      Posté par  . Évalué à 10. Dernière modification le 24 avril 2021 à 11:01.

      Je ne vois pas l'avantage de FAT32 par rapport a exFAT

      C'est parce que le tableau tente de rendre binaire ce qui ne l'est pas.
      exFAT n'est supporté sous Linux sans FUSE que depuis le noyau 5.4, novembre 2019, donc dans les distributions de 2020 et ultérieur. Avant, il fallait installer un paquet supplémentaire, donc le support n'était pas garanti.
      De plus, il ne faut pas oublier tout le matériel à la con qui existe : auto-radios ou lecteurs de musique, imprimantes, appareils divers et variés acceptant des clés USB fonctionnant avec des OS inconnus… Eux ne supporteront en général que le FAT32.

    • [^] # Re: Résumé

      Posté par  . Évalué à 9.

      Alors sous linux je trouve fsck.vfat beaucoup plus robuste que celui de exfat.
      En FAT32 le driver est super éprouvé, celui de exfat semble encore un peu jeune. Par exemple il m'est arrivé de devoir faire un scandisk sous windows pour récupérer des fichiers sur une sdcard là ou linux ne relevait aucun problème.

    • [^] # Re: Résumé

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

      Parce que FAT32 est lisible absolument partout, même sur des trucs conçus il y a trente ans. ExFAT est lisible sur à peu près tout les trucs pas trop anciens, ça peut faire une différence.

  • # Commentaire supprimé

    Posté par  . Évalué à 5.

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

  • # ext4 vs f2fs sur flash / ssd

    Posté par  . Évalué à 6. Dernière modification le 24 avril 2021 à 12:53.

    Il me semble que beaucoup de téléphones Android viennent avec leur mémoire interne / carte mémoire formatée en ext4. C'est aussi le format utilisé sous Mobian pour la mémoire interne du PinePhone.

    J'avais vaguement regardé des comparaisons entre ext4 et f2fs il y a quelques temps pour un usage sur téléphone Android et je n'ai jamais réussi à arriver à une conclusion claire sur lequel est le mieux. D'ailleurs, j'ai l'impression que si c'était si claire, les téléphones Android viendraient quasi systématiquement avec un formatage f2fs, non ?

    Mon dernier téléphone Android était vendu avec sa partition data formatée en f2fs, mais un bug dans son pilote f2fs a donné du fil à retordre aux gens qui faisaient des ROMs custom pour ce téléphone (bug impliquant des problèmes de compatibilité, pas de stabilité de perf, de mémoire). J'ai utilisé LineageOS avec ext4 sur ce téléphone et n'ai pas perçu de différence de performance à l'utilisation. Quant à l'usure, je n'ai aucune donnée.

    D'après des choses écrites en 2017, ext4 était plus stable à cette époque que f2fs, dans le sens où plus de patches changeaient des grosses parties du fonctionnement de f2fs comparé à ext4, est-ce que ce ça a évolué, 4 ans plus tard ?

    D'après un article de Phoronix en mars 2020 pour une utilisation qui a l'air orientée serveur, f2fs bat ext4 sur pas mal de benchmarks mais globalement ext4 sort très légèrement gagnant côté performances sur SSD.

    Du coup, je ne sais toujours pas.

    Dans tous les cas, ça ne mange pas de pain de rajouter noatime et nodiratime aux options de montage du système de fichier pour éviter des écritures à chaque accès.

    • [^] # Re: ext4 vs f2fs sur flash / ssd

      Posté par  . Évalué à 2.

      D'après un article de Phoronix en mars 2020 pour une utilisation qui a l'air orientée serveur, f2fs bat ext4 sur pas mal de benchmarks mais globalement ext4 sort très légèrement gagnant côté performances sur SSD.

      Dans l'article mis en lien, ext4 remporte tous les comparatifs.

      • [^] # Re: ext4 vs f2fs sur flash / ssd

        Posté par  . Évalué à 3.

        Pas vraiment (pages 2 et 3) :

        when moving to buffered indirect 4K random writes, F2FS was about 5% faster than EXT4

        Random write performance was also performing slightly better with F2FS over EXT4

        F2FS did also perform slightly better for sequential reads.

        F2FS was tending to deliver slightly better performance out of FS-Mark on Clear Linux

        F2FS did have a higher score for PostMark that mostly stresses fsync performance of the file-system

        • [^] # Re: ext4 vs f2fs sur flash / ssd

          Posté par  . Évalué à 2. Dernière modification le 25 mai 2021 à 20:41.

          Ah, quelle buse je fais, comme le lien était sur la page 4, j'ai pas vu les pages d'avant :-o .

          Bon, la conclusion de l'article reste : "At the end of the day […] EXT4 came out to being just 2% faster than F2FS".

  • # Remarques

    Posté par  . Évalué à 4.

    J'ai quelques remarques :)

    unixeries

    Par « unixeries », j’entends le support de fichiers spéciaux (surtout les liens symboliques, mais également les nœuds de périphérique, les sockets Unix et les tubes nommés) et les notions de propriétaire et de permissions.

    Autant les liens symboliques je peux voir l'intérêt autant tout le reste je ne pense pas que ça ai du sens dans le cadre d'un périphérique amovible que tu cherche à passer d'un système à un autre, mais tu as oublié une unixerie qui peut être très importante : les propriétés étendues (xattrs dans la langue de molière) et pour le coup je sais qu'il y a eu des évolutions récentes qui ne sont pas arrivées immédiatement dans tous les fs (je crois que c'est une augmentation de la taille limite).

    UDF

    sous MacOS, la dernière fois que j’avais pu l’essayer, on ne pouvait monter une clef USB formatée en UDF que depuis un terminal ;

    La dernière fois que j'ai formaté une clef usb en UDF (c'est le format que j'utilise de base), il m'a était notifié par l'outil que MacOS n'aime pas avoir un périphérique UDF avec une table de partition. Je ne sais pas ce qu'il en ai (j'utilise une debian stable ça a peut être évolué ces 2 dernières années).

    fsck

    Tu reproche à udf de ne pas avoir de fsck, mais est-ce que le fsck d'ext4 est opérant si on a désactivé le journal ? Autre point ext* aime bien avoir un fsck régulier ce qui n'est pas forcément pratique pour un périphérique amovible.

    btrfs

    Quitte à partir sur de l'ext4 sans journal peut être que btrfs peut être une bonne idée ? Il aura globalement les même problèmes, mais il n'a de base pas de journal.

    fscrypt

    Une fonctionnalité qui peut par contre faire sortir du lot ext4 et f2fs c'est le support de fscrypt. Ça permet de chiffrer les données, mais contrairement à un chiffrement au niveau bloc device (ce que fais dm-crypt) ici il va être possible de chiffrer des dossiers. C'est intéressant pour pouvoir ne chiffrer qu'un dossier et ne pas avoir à créer différentes partitions pour ça (ce qui fait perdre en souplesse pour la gestion de l'espace).

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Remarques

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

      btrfs

      Quitte à partir sur de l'ext4 sans journal peut être que btrfs peut être une bonne idée ? Il aura globalement les même problèmes, mais il n'a de base pas de journal.

      En effet, je l'oublie tout le temps, parce que je ne l'utilise pas, et je ne l'utilise pas parce que je n'ai jamais vu d'annonce que ce système de fichier était finalisé et officiellement prêt pour la prod. Je ne suis pas du genre à utiliser des FS expérimentaux pour stocker mes données.

      • [^] # Re: Remarques

        Posté par  . Évalué à 3.

        Je fais nettement plus confiance à btrfs qu'à ntfs3g pour le coup. Entre un format qui est maitrisé et dont le développement est assuré directement au sein de la LKML et l'accès à une format géré par divers microsofteries potentiellement avec chacune leurs petites bizarreries hors de la LKML mon choix est vite fais. De la même manière utiliser ext4 sans journalisation qui est un usage non conventionnel du fs et qui va réduire de je ne sais pas sa fiabilité alors qu'une partie de l'outillage s'attend à avoir un journal me paraît tout aussi dangereux.

        Je ne suis pas du genre à utiliser des FS expérimentaux pour stocker mes données.

        Je ne suis pas du genre à faire confiance en un élément physique pour stocker mes données (surtout une clef usb ou carte mémoire). Une clef usb c'est la même chose qu'un câble ethernet. Ça permet d'échanger entre 2 machines ou entre 2 OS d'une même machine, mais ça ne va pas plus loin. Pour un disque usb qui servirait de sauvegarde, ça ne se discute pas : fat, exfat et ntfs sont exclus, ils vont te flinguer les droits (je parle bien des droits et pas des propriétaires) et sur disque que ce soit à plateau ou sdd F2FS n'est pas fait pour et je ne vois pas pourquoi désactiver la journalisation dessus.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: Remarques

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

          Je fais nettement plus confiance à btrfs qu'à ntfs3g pour le coup.

          Oui, moi aussi. Mais ce n'est pas le même usage. Pour échanger des données, ntfs-3g fait partie des choses que j'envisage. Pour le stockage interne de mes ordinateurs, je n'ai jamais considéré l'usage de btrfs.

          Je ne suis pas du genre à faire confiance en un élément physique pour stocker mes données (surtout une clef usb ou carte mémoire). Une clef usb c'est la même chose qu'un câble ethernet. Ça permet d'échanger entre 2 machines ou entre 2 OS d'une même machine, mais ça ne va pas plus loin. Pour un disque usb qui servirait de sauvegarde, ça ne se discute pas : fat, exfat et ntfs sont exclus, ils vont te flinguer les droits (je parle bien des droits et pas des propriétaires) et sur disque que ce soit à plateau ou sdd F2FS n'est pas fait pour

          Si si : https://lwn.net/Articles/518718/

          et je ne vois pas pourquoi désactiver la journalisation dessus.

          Pour éviter de doubler les écritures, sur des supports dont la durée de vie dépend directement du nombre d'écriture. Il faut aussi être conscient que quand on écrit ne serait-ce qu'un octet, on cause en réalité la remise à zéro d'un bloc d'effacement de l'ordre du mébioctet, et la réécriture des blocs qu'il contenait à des emplacements libres.

          • [^] # Re: Remarques

            Posté par  . Évalué à 4. Dernière modification le 26 avril 2021 à 12:44.

            Pour le stockage interne de mes ordinateurs, je n'ai jamais considéré l'usage de btrfs.

            Même debian le propose sans warning maintenant.

            Si si : https://lwn.net/Articles/518718/

            Ils ont revu la journalisation pour qu'elle soit mieux adaptée, mais leur algorithme d'allocation basé sur la géométrie interne ne sert à rien quand tu as un firmware qui est là pour te cacher la géométrie interne et créer une indirection.

            et je ne vois pas pourquoi désactiver la journalisation dessus.

            Pour éviter de doubler les écritures, sur des supports dont la durée de vie dépend directement du nombre d'écriture. Il faut aussi être conscient que quand on écrit ne serait-ce qu'un octet, on cause en réalité la remise à zéro d'un bloc d'effacement de l'ordre du mébioctet, et la réécriture des blocs qu'il contenait à des emplacements libres.

            Les durées de vies des ssd ont explosées depuis l'époque en question. Si c'était si nécessaire il serait urgent de passer à des fs comme zfs, btrfs ou hammerfs pour supprimer la journalisation sur les disques internes et il serait à propos que les distributions par défaut sur ssd t'installent un fs sans journal donc, mais avec aussi quelques options comme noatime, te mettent un gros warning pour l'usage du swap, etc. Aucune distribution le fait.

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Remarques

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

      Ce qui me pourrit le plus la vie avec la FAT32, c'est le non-support de certains caractères comme ":"
      Je voudrais faire un script enveloppant "mv" ayant au moins deux fonctions:
      - vérifier que la place libre est suffisante sur la destination avant de commencer;
      - Supprimer ce genre de caractères;
      Je n'ai jamais le courage de m'y mettre, ayant une idée des gigantesques problèmes qui seront à résoudre, ne serait-ce que la présence d'espaces dans les noms de fichiers, pour n'en citer qu'un. Alors si quelqu'un a déjà fait ça, ça m'interresse au plus haut point! "File Renamer" de Stefan Frost semble faire le second point mais c'est un outil graphique trop lourd à mon goût.

      L'UDF pourrait théoriquement convenir pour des cartouches Gigamo, mais je n'ai pas confiance dans ce format qui m'a valu des pertes de données immenses sur CD-RW(avec cette daube de DirectCD). Savez-vous s'il existe un "Undelete" pour UDF? Et un pour vfat avec secteurs de 2 Ko? Je ne comprends d'ailleurs pas pourquoi faire une restauration de fichiers supprimés sur FAT est devenu si compliqué alors que sous M$-DO$, le primitif "UNDELETE" fonctionnait parfaitement.

      Ce n'est pas un gage de qualité si Ext2 nécessite un fsck régulier… dans ce cas, l'automatiser avant montage?

      J'ai vu BTRFS en standard récemment sur une distribution, je ne sais plus laquelle…

      • [^] # Re: Remarques

        Posté par  . Évalué à 4.

        Savez-vous s'il existe un "Undelete" pour UDF?

        Quelque soit le système de fichiers j'utilise photorec pour ça.

        Ce n'est pas un gage de qualité si Ext2 nécessite un fsck régulier

        Tous les fs de MS ont besoin de faire des défragmentation régulières. En soit les fs doivent faire de la correction régulière soit c'est fait offline via un fsck soit une defrag soit en ligne comme le font zfs, btrfs ou hammerfs. Je vois pas où est la question de qualité là dedans.

        dans ce cas, l'automatiser avant montage?

        Si je ne me trompe pas les ext ont un compteur de montages qui indique le nombre de montage sans fsck et indique quand il faut le faire (c'est configurable via tune2fs). C'est fait au démarrage, je n'utilise plus assez ce genre de fs pour savoir si c'est le cas avec des montages manuels.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Et vous, quel format utilisez vous?

    Posté par  . Évalué à 2.

    Perso, je tourne en xfs et une partition partagé entre windows et ma fedora en NTFS. Pour la gestion des droits sur ntfs j'utilise le fichier "UserMapping" avec ntfs-3g.
    Pour les clefs USB, ntfs! L'écriture passe bien sûr Linux et je suis sur de passer partout sur les autres machines a l'extérieur de chez moi.

    • [^] # Re: Et vous, quel format utilisez vous?

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

      ext4 pour tous les supports de stockage internes de mes machines, que ce soit pour les disques durs ou pour les SSD. Souvent sans partitionnement.

      UDF pour tous mes supports de stockage amovibles, sans partitionnement.

    • [^] # Re: Et vous, quel format utilisez vous?

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

      Ext4 pour le stockage interne de mes ordinateurs, mais je pourrais considérer l'usage de F2FS à la place, lorsque c'est sur SSD.

      XFS pour un disque dur externe qui me sert à stocker des sauvegardes, l'idée étant de ne pas utiliser le même système de fichiers que la source, au cas où j'aie à faire face à un bug grave de pilote de FS.

      F2FS pour le stockage interne de mon téléphone.

      FAT32 pour mes clefs USB, ExFAT pour les disques durs externes que je pourrais vouloir prêter à des gens.

  • # Support

    Posté par  . Évalué à 7.

    en F2FS s’il s’agit d’un périphérique flash (clef USB, SSD ou carte SD)

    Je n'ai pas suivi l'actualité récente mais mais le dernier écho que j'avais eu sur le sujet, c'était que F2FS présentait un intérêt sur les dispositifs où la mémoire flash était directement accessible par le système (les clefs USB, les cartes flash ou les mémoires internes d'appareils mobiles comme les smartphones), mais pas sur les dispositifs dotés d'un firmware rajoutant une couche d'abstraction entre la mémoire flash et le FS, comme les SSD. En gros les SSD feraient croire au système qu'ils sont des disques durs classiques, et le firmware se charge d'optimiser la lecture et l'écriture du FS sur la mémoire flash. F2FS serait contre-productif dans ce cas-là et il faudrait utiliser un FS traditionnel comme ext4.

    Fonctionnalité Ext2/3/4 F2FS FAT32 NTFS exFAT UDF

    Tu as parlé du support sur les *Linux/Windows/MacOS, mais qu'en est-il pour les autres OS ?

    Après une petite recherche concernant ext2/3/4 il semblerait que le dénominateur commun soit ext2 (aka ext3 sans journalisation) sur les *BSD. Visiblement FreeBSD et DragonflyBSD peuvent lire ext2/3/4 et écrire sur du ext2/3, sans journalisation. NetBSD et OpenBSD semblent pouvoir lire et écrire ext2/3, mais pas ext4.

    Haiku est dans la même situation que NetBSD et OpenBSD. Minix a une page man pour ext2/3/4 donc je suppose qu'il gère les trois. GNU Hurd sait lire et écrire ext2 mais pas ext4 (je ne sais pas quel est le support de ext3).

    Les UNIX les plus exotiques (Illumos, Plan9…) sont concentrés sur leurs FS maison (ZFS, 9P…) donc ça m'étonnerait qu'ils sachent utiliser autre chose (mais de toute façon ils sont surtout utilisés dans des environnements où on transfère des fichiers via le réseau).

    Pour les clones des OS Microsoft il y a des trucs surprenants : FreeDOS n'a pas de support pour ext2, NTFS ou exFAT mais il a un outil rudimentaire pour copier des fichiers sur et depuis un FS ext2. ReactOS gère FAT32, UDF, Btrfs et ReiserFS, mais ext2 et NTFS ne sont pas encore utilisables.

    Et finalement, Rockbox, bien que basé sur Linux, ne gère que le FAT32.

    Il faut aussi noter que le cas de figure mentionné ici, c'est celui d'un dispositif de stockage formaté directement. Si on rajoute une couche de sous-partitionnement (comme LVM) ou du chiffrement (LUKS, GELI), ça se complique. Même le simple choix de la table de partition (msdos ou GPT) peut être un problème : rockbox par exemple ne gère pas GPT.

    Avec rockbox il peut y avoir d'autres cafouillages : par exemple si par mégarde j'ai créé une partition FAT32 sur ma carte au lieu de la formater directement, rockbox ne pourra pas la reconnaître à l'insertion et devra rebooter pour pouvoir la lire.

    Enfin tant qu'on en est à parler d'ordinateurs qui lisent des données depuis un disque amovible, c'est dommage de faire l'impasse sur tous les ordinateurs disposant d'un kernel maison sur lequel on n'a généralement zéro contrôle : baladeurs, appareil photos, téléphones mobiles, imprimantes…

    Typiquement mon APN prend des cartes SD jusqu'à 32GB et SDXC au-delà de 32GB. Il peut lire une SD de 32GB formatée en FAT32 mais refuse de lire une SDXC de 64GB si elle n'est pas formatée en exFAT. Et j'ai toujours eu des problèmes pour utiliser exFAT sous Linux (pourtant je suis en 5.10) : udevil ne veut pas monter la carte, je suis obligé d'utiliser mount, et une fois la carte montée tout est en root:root et je ne peux pas changer les permissions des fichiers déjà existants (chown renvoie une erreur et chmod échoue silencieusement).

    *splash!*

    • [^] # Re: Support & performances

      Posté par  . Évalué à 2.

      Je rejoins sur certains problèmes comme GPT et exFAT.
      J'ai arrêté de mettre GPT en table de partition, on m'envoi souvent balader.
      Exfat pourrait être bien, si et seulement si les Windows acceptaient les clés formatés en exfat depuis ma Debian, j'ai pas encore saisi ou ça coince, assez aléatoire.
      Mais surtout la catastrophe en écriture avec le driver ntfs-3G, comme si on atteignait le maximum d'un tampon quelque part. Je m'étais amusé à faire bench d'un disque dur sur 2 OS avec différents formatages et transferts différents chunks, c'est sans appel, ntfs-3G ne décolle pas.
      Merci pour F2FS et UDF, je ne pensais pas utilisable sur des clés.

    • [^] # Re: Support

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

      Je n'ai pas suivi l'actualité récente mais mais le dernier écho que j'avais eu sur le sujet, c'était que F2FS présentait un intérêt sur les dispositifs où la mémoire flash était directement accessible par le système (les clefs USB, les cartes flash ou les mémoires internes d'appareils mobiles comme les smartphones), mais pas sur les dispositifs dotés d'un firmware rajoutant une couche d'abstraction entre la mémoire flash et le FS, comme les SSD. En gros les SSD feraient croire au système qu'ils sont des disques durs classiques, et le firmware se charge d'optimiser la lecture et l'écriture du FS sur la mémoire flash. F2FS serait contre-productif dans ce cas-là et il faudrait utiliser un FS traditionnel comme ext4.

      Les clefs USB et autres mémoires flash ont une couche d'abstraction, même si elle est peut-être plus rudimentaire. Sans couche d'abstraction, une mémoire flash se comporte d'une façon trop différente d'un périphérique bloc normal : elle est constituée de blocs qu'on peut écrire, mais pas modifier ensuite, et de blocs d'effacement, qui regroupent plusieurs blocs, qu'on peut effacer ensemble.

      • [^] # Re: Support

        Posté par  . Évalué à 0.

        Je préfère distinguer les besoins suivants et choisir ensuite le format en fonction :

        1. Faire les sauvegardes sur un support formaté dans un format identique à celui des fichiers sauvegardés, si possible dans le format le mieux pris en charge possible par le SE qui fait la sauvegarde.

        2. Pour faciliter les échanges, par défaut utiliser exFAT. exFAT a de très nombreux avantages sur FAT32, comme la taille de fichier, la fiabilité, les performances, et tous les équipements modernes l'utilisent en général pour SDCard rapides.

        3. Pour les besoins spécifiques, ajuster selon le cas, toujours en privilégiant exFAT chaque fois que possible. Par exemple une USBKey à mettre sur Autoradio => FAT32 si l'autoradio ne lit rien d'autre, mais essayer exFAT d'abord.

        Enfin, pour limiter les problèmes, formater le plus possible sous le SE le plus naturel pour le format : Formater en NTFS, FAT32, exFAT sous Windows, même si ça marche sous Linux par exemple, et même le support est ensuite uniquement utilisé sous Linux.

  • # Concernant le ID-mapping

    Posté par  (site web personnel) . Évalué à 4. Dernière modification le 26 avril 2021 à 00:40.

    Je viens de voir passer https://lwn.net/Articles/837566/ qui permet de résoudre des cas de mappings d'ID.

  • # ZFS ?

    Posté par  . Évalué à 2.

    OpenZFS a l'air de supporter de base Linux, et il existe des ports pour MacOS et Windows. Est-ce que ça serait une autre piste possible pour partager des fichiers ?

    Avoir à installer un driver ne me parait pas rédhibitoire, tant que ça permet d'accéder aux fichiers. Et ZFS a plein d'avantages, comme l'encryption ou la compression.

  • # Je veux pas dire, mais Windows lit tous les FS :)

    Posté par  . Évalué à 5. Dernière modification le 25 mai 2021 à 20:09.

  • # en même temps...

    Posté par  . Évalué à 4.

    l'intérêt de la gestion des droits (autre que exécution) sur un périphérique externe me laisse dubitatif. Je peux très bien le brancher sur un pc perso avec le login d'un autre, ou en tant qu'administrateur et paf!

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

  • # exFAT et UDF

    Posté par  . Évalué à 6.

    mkfs.exfat-L "Clef Cyrano" /dev/sdc1

    La commande ne marche pas. Sur Linux Mint c'est, sous root ou sudo :

    mkfs.exfat -n "Clef Cyrano" /dev/sdc

    Pour UDF c'est :

    mkudffs --media-type=hd -l "Clef Cyrano" --blocksize=512 /dev/sdc

    Si l'on ne précise pas blocksize la clé n'est pas lue sous Windows (mais ça marche sous Linux).

    Habituellement je formate mes clés et disques USB avec UDF, mais récemment un ordi Windows 10 a refusé d'en lire un. J'essaierais avec exFAT maintenant que les spécifications sont ouvertes.

Suivre le flux des commentaires

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