APFS : plongée dans le nouveau système de fichiers d'Apple

APFS : plongée dans le nouveau système de fichiers d’Apple

Un quoi ?

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

07/09/2017 19 minutes
66

APFS : plongée dans le nouveau système de fichiers d'Apple

Alors que macOS High Sierra se rapproche, certains s’interrogent sur l’arrivée d’un nouveau système de fichiers sur les Mac : APFS, pour Apple File System. Il remplace le bien ancien HFS+ après près de 20 ans de service. Nous faisons le tour de ses fonctionnalités et apports, afin de mieux cerner ce nouveau venu.

Avant d’évoquer les éventuels bénéfices d’APFS, il faut revenir à ce qu’est un système de fichiers (ou FS, pour File System). Il décrit, dans les grandes lignes, comment les données sont stockées et organisées. Chaque système d’exploitation sait en utiliser un ou plusieurs, et les fonctionnalités liées aux fichiers dépendent directement du FS.

Il définit un très grand nombre d’informations comme le découpage de la partition (ou volume), la taille allouée aux blocs, les métadonnées qui les accompagnent, comment sont codés les caractères, la manière de retrouver les informations, les éventuelles protections contre la corruption des données, les mécanismes de réparation, la taille maximale d’un volume, d’un fichier, la gestion des copies, la possibilité de préserver plusieurs versions d’un même fichier, les droits d’accès, etc.

Pour l’immense majorité des utilisateurs, il s'agit d'un concept flou… quand il est connu. Tout ce que l’on voit en effet, c’est un choix au moment du formatage. Pour le reste, cela se résume le plus souvent dans une interface graphique à une fenêtre affichant des dossiers et des fichiers : des documents, des photos, des archives, des images disques… C’est pourtant le FS qui s’occupe du stockage de ces informations et qui indique à l’OS où les récupérer en cas de besoin.

C'est une méthode de classement, et de ses capacités dépendent bien des comportements. C’est d’ailleurs pour ça qu’il en existe un très grand nombre, car leur usage se fait avant tout en fonction du type de produit auxquels ils se destinent.

Un peu d’histoire

Pour les aficionados de l’informatique, la plupart de ces systèmes de fichiers sont très connus. Sous Windows par exemple, la FAT32 avait ainsi pris le relai de la FAT (File Allocation Table), augmentant drastiquement le nombre possible de clusters (unités d’allocation) et permettant généralement d’en réduire la taille. Une évolution qui illustrait l’importance d’un FS.

Bien sûr, les utilisateurs connaissent surtout NTFS (New Technology File System), largement poussé par Microsoft depuis Windows XP. Il est pour l’instant le système de fichiers par défaut, même si la FAT32 est souvent utilisée pour des périphériques amovibles, puisqu'il est aisé d'y lire et écrire depuis tous les systèmes.

Ces périphériques ont eu plus récemment droit à leur propre FS : exFAT. Mais, comme son prédécesseur, son utilisation passe parfois par une licence spécifique hors des produits de Microsoft. C'est notamment pour cela que Synology fait payer son utilisation via un paquet spécifique disponible pour son DSM. Il existe néanmoins des implémentations libres permettant leur utilisation sous Linux par exemple.

La plupart des distributions utilisent toutefois d'autres systèmes de fichiers. On retrouve les plus connus, tels qu'Ext 2/3/4 dérivés de l'Extended file system.  Mais il en existe bien d'autres comme JFS, XFS ou encore ReiserFS. Mais là aussi le paysage évolue avec la montée en puissance de Btrfs, qui offre de nombreux avantages, notamment pour la gestion des instantanés (snapshots). Il est par exemple mis en avant par Synology au sein de ses NAS.

Btrfs Synology

Un petit tour sur la page du Wiki de Debian destinée aux systèmes de fichiers supportés montre que la liste est bien plus longue, mais seuls certains sont destinés au système (R). Il y a une explication simple à cela : un système de fichiers peut aussi prendre la forme d'une implémentation par une application qui vient se rajouter au-dessus d'un FS existant. 

Des outils tels que FUSE (Filesystem in Userspace) ou Dokany ont cet objectif. Ils peuvent être utilisés pour de multiples raisons, mais on les retrouve souvent dans des solutions permettant de « monter » un service de stockage dans le « cloud » (rclone par exemple) et proposant parfois l'ajout d'une couche de chiffrement.

Le cas Apple

Du côté d'Apple, le système de fichiers le plus connu est HFS+. Pour une raison simple : il fêtera l’année prochaine son vingtième anniversaire. Bien entendu, comme pour NTFS et autres, ses capacités se sont étendues avec le temps.

Il est lui-même l’évolution de HFS (Hierarchical File System), lancé par Apple en 1985, qui remplaçait alors MFS (Macintosh File System). Les bénéfices étaient alors importants, avec la prise en charge des disques durs qui posaient de nouvelles contraintes de performances. Les quantités de données à gérer devenaient en effet beaucoup plus importantes que les simples disquettes. Il est aussi connu pour avoir été vertement critiqué par Linus Torvalds il y a quelques années.

HFS+, lorsqu’il apparaît avec Mac OS 8.1, a pour mission principale de faire voler en éclats le nombre maximal de clusters sur un volume, alors limité à 65 535. Les adresses passent ainsi du 16 au 32 bits, et Apple en profite pour basculer sur Unicode. En presque 20 ans, HFS+ a évolué à plusieurs reprises, mais son ajout le plus notable reste la prise en charge de la casse (distinction entre minuscules et majuscules) avec Panther (Mac OS 10.3).

La question de son remplacement a commencé à réellement se poser dès la fin 2006 quand – surprise ! – une bêta du futur Leopard (Mac OS X 10.5) présentait tout à coup un support expérimental de ZFS, système de fichiers créé par Sun. Un feuilleton commence alors, Apple n’expliquant guère ce choix.

En juin 2007, le PDG de Sun (alors Jonathan Schwartz) annonce que Leopard utilisera par défaut ZFS. Il n’en sera finalement rien. Nous nous interrogions alors à l’époque sur un éventuel système de fichiers maison.

C’est ainsi qu’entre en scène APFS.

Pourquoi un nouveau système de fichiers ?

20 ans en informatique représentent évidemment une succession de plusieurs âges géologiques. Les évolutions et les attentes ont largement changé. Tout comme HFS avait remplacé MFS pour des questions de performances, APFS veut accomplir la même opération, notamment parce que les disques durs sont progressivement remplacés par les SSD.

Cette transition n’est pour beaucoup qu’une affaire de performances. Oui, un SSD est beaucoup plus rapide qu’un disque dur et on se surprend encore souvent à regarder un ordinateur démarrer en quelques secondes. Mais les SSD demandent des adaptations. Sur Windows par exemple, depuis la version 8, l’indexation et la défragmentation automatique n’y sont même plus activées quand un tel disque est détecté.

Il fallait donc qu’APFS soit aligné sur des besoins modernes. Tirer ce qu’il y a de mieux dans les SSD sans pour autant rejeter les disques durs (et ne surtout pas les rendre plus lents), faciliter le chiffrement ou encore, si possible, la gestion des versions d’un même fichier, le tout avec une grande précision des dates et heures. Et pourquoi pas utiliser le même système de fichiers pour l’ensemble des produits de l’entreprise ?

Des appareils mobiles aux ordinateurs

APFS est en fait déjà déployé sur une partie des gammes d’Apple. Les premiers à en avoir profité sont les appareils sous iOS, avec l’arrivée de la mise à jour 10.3 (à condition que le SoC soit lui-même 64 bits). Dans la foulée, tvOS 10.2 a également installé APFS dans les dernières générations d’Apple TV.

Il s’agissait pour Apple de déployer son système de fichiers sur des produits grand public, mais avec un impact plus limité. Les utilisateurs n’y ont en effet pas accès puisque la gestion des données passe presque exclusivement par les applications. La situation évoluera prochainement avec iOS 11 puisque l’application Fichiers offrira un semblant d'explorateur de fichiers à la plateforme mobile.

Les avantages liés à APFS ne sont guère visibles sur ces systèmes. Le démarrage est un peu plus rapide et beaucoup ont constaté une petite libération d’espace de stockage, davantage liée en fait à la manière dont APFS calcule l'espace disponible. Sur Mac, avec l’arrivée de High Sierra, les bénéfices devraient cependant être nettement plus importants.

Comme indiqué récemment dans un article, le passage à APFS sera obligatoire sur les Mac disposant d’un SSD, alors que le choix était laissé durant la phase de bêta. Les possesseurs de modèles à disques durs pourront refuser la migration.

APFS : caractéristiques principales

Commençons par un petit tour rapide de ses caractéristiques principales. APFS est un système de fichiers 64 bits, ce qui lui permet de stocker un maximum de 9 milliards de milliards de fichiers au sein d’un même volume.

Il a en outre une manière spécifique de diviser l'espace disque. On ne parle en fait plus de partitions mais de volumes, rassemblés dans un ou plusieurs conteneurs. L'allocation des espaces n'est ainsi plus fixe et ces volumes peuvent changer de taille sans opération lourde sur le disque.

L'espace libre rapporté pour chaque volume devient également celui du conteneur. Si ce dernier dispose de 100 Go et contient deux volumes embarquant respectivement 10 et 20 Go de données, l'espace libre signalé pour chacun sera de 70 Go. On peut en fait considérer les volumes comme de simples signalements symboliques d'organisation des données.

Il se base sur Unicode 9.0 et est donc sensible à la casse. Les noms de fichiers doivent impérativement être en UTF-8. APFS permet également de vérifier l’intégrité des métadonnées, de gérer les clones, facilite la création des snapshots (instantanés), et le chiffrement, calcule rapidement les tailles et donc les espaces disponibles, gère les fichiers creux, autorise le partage des espaces.

La plupart de ces fonctionnalités sont destinées à des usages plus professionnels, mais les bénéfices pour l'ensemble des utilisateurs seront également visibles. APFS est en effet et avant tout mis en avant pour son exploitation des SSD, ce qui inclut évidemment le support de la commande TRIM

L’armée des clones

Lors de tests effectués à la WWDC de 2016, Apple montrait les performances en copie sur un lot de fichiers. Sur le disque utilisant APFS, l’opération était presque instantanée, tandis que la même via HFS+ réclamait une vingtaine de secondes. On s’en doute toutefois, il ne s’agit pas d’un miracle, mais d’une manière très différente de gérer ces opérations.

Dans HFS+, comme dans bien d’autres systèmes de fichiers, la copie de données entraine celles des blocs associés. Dans APFS, ce n’est pas le cas : le Finder peut afficher plusieurs fois le fichier, mais les copies réalisées n'en sont pas vraiment. Ces fichiers ne contiennent en fait que quelques éléments – surtout les métadonnées – qui permettent leur identification, mais pas le contenu. Mais que se passe-t-il si on modifie l’une des copies ?

On entre ici dans l’une des caractéristiques principales d’APFS, qui explique des gains possibles de place sur un disque. Modifier une copie n’entrainera une allocation de blocs que pour les données réellement modifiées. Il s'agit du processus COW, ou copy-on-write, déjà exploité par Btrfs

Attention, on ne parle ici que des copies au sein d’un même volume APFS. Si vous utilisez un disque dur externe par exemple, et quel que soit son système de fichiers, la copie fonctionnera à nouveau de manière classique. Un emplacement distant, donc y compris réseau, aurait sinon à se référer au contenu local du disque de départ.

apfs clonesapfs clones

Ce fonctionnement a ses avantages et ses inconvénients. Si vous avez besoin de dupliquer un dossier de 10 Go, l’opération sera presque instantanée, et pour cause : seules des métadonnées sont copiées.

Par contre, les opérations de ménage sur le disque demanderont une autre gymnastique. Car beaucoup de fichiers risquent d’apparaître pour ce qu’ils ne sont pas. La notion de fichier source a ici toute son importance car supprimer les copies n’aura que très peu d’effet concret sur l'espace disponible. On compte ici sur les nouveaux outils de nettoyage présents dans macOS High Sierra pour épauler l’utilisateur.

Par ailleurs, le fonctionnement des clones sur la sauvegarde est théorique. En clair, APFS offre ces capacités, mais les applications doivent en tirer parti (via des API spécifiques) pour que l’utilisateur en profite. Ce n’est pas le cas pour le moment et des logiciels comme Word et Photoshop enregistrent des documents entiers quand une modification est apportée sur une copie, aussi légère soit-elle.

apfs time machine

Compatibilité : de nombreux points à connaître

Puisque la migration vers APFS est obligatoire pour les SSD, beaucoup auront le nouveau système de fichiers sans qu’on leur demande leur avis. Il est important de connaitre dans ce cas certains points de compatibilité, car il ne s’agit pas d’un changement léger.

Un Mac utilisant APFS pourra donc lire et écrire sur l’ensemble des partitions et volumes en APFS ou HFS+. Un Mac utilisant HFS+ pourra également écrire sur un volume APFS si la mise à jour 10.12.6 de Sierra est installée. Pour démarrer sur un tel volume, il faudra cependant que High Sierra soit présent.

La migration vers APFS pose également certaines questions sur les fonctions de macOS. FileVault ? Aucun problème. Partages réseau ? Idem, à condition qu’ils utilisent NFS ou SMB, AFP n’étant plus pris en charge. Time Machine et ses Time Capsules ? Pas de soucis non plus, si les disques utilisés ne sont pas retouchés. Un point détaillé un peu plus loin.

Les deux seuls vrais cas d’incompatibilité concernent les volumes Boot Camp. Ainsi, s’ils dépassent les 3 To et se trouvent sur un Fusion Drive, la migration vers APFS ne se fera pas. Un cas assez spécifique.

Par contre, et c’est beaucoup plus ennuyeux, un Windows installé via Boot Camp ne pourra ni lire ni écrire dans un volume APFS... en tout cas pour l'instant. Un point qui risque d’avoir de fortes conséquences pour ceux qui récupéraient des données sous Windows depuis leur partition macOS.

Les snapshots à la rescousse

Les instantanés sont une autre fonctionnalité phare d’APFS, que les utilisateurs ne verront pas forcément. Le principe est connu de longue date, particulièrement de ceux qui manipulent régulièrement des machines virtuelles. Le système crée ainsi une capture de son état à un instant « t ». En cas de problème, on peut alors y revenir.

Comme expliqué dans la documentation d’Apple, les snapshots sont des instances en lecture seule correspondant à l’état du système de fichiers à un moment précis. APFS peut alors traquer les modifications depuis le dernier snapshot pour que le suivant ne prenne en compte que celles intervenues entre temps.

apfs snapshot

Le fonctionnement de ce dispositif pose immédiatement la question : cette fonctionnalité d’APFS est-elle compatible avec Time Machine, dédiée justement à la sauvegarde régulière des données utilisateurs et gérant les versions ? On entre ici – et pour l’instant – dans une zone grise.

Nous avons procédé à quelques tests sur la dernière bêta (9) de High Sierra. Une fois branché un disque dur disposant d’une partition formatée en HFS+, le système n’a aucune difficulté pour s’en servir comme destination Time Machine. Puisque l’Utilitaire de disque propose une conversion, nous avons voulu savoir si High Sierra pouvait également utiliser un volume externe en APFS. La conversion a fonctionné, mais Time Machine n’en voulait plus.

En clair, actuellement, la fonction de sauvegarde automatisée n’accepte que des disques externes en HFS+, que l’Utilitaire de disque appelle Mac OS Étendu journalisé. Si la conversion d’un tel disque vers APFS ne pose aucun problème (tant qu’il ne possède pas une autre partition FAT32 ou NTFS, ce qui provoque une erreur), Time Machine ne peut ensuite plus l’utiliser. Formater intégralement le disque externe n’y changera rien.

Un point sur lequel on espère qu’Apple communiquera pour prévenir des risques. Actuellement, si on se fie à la note publiée récemment sur les questions pratiques d’APFS, la société se contente de dire que les sauvegardes existantes continueront d’être exploitables et que Time Machine continuera de fonctionner. Rien n’est indiqué sur l’utilisation d’un volume APFS, sauf de manière détournée : APFS change les liens « en dur » par des liens symboliques et alias.

apfs time machineapfs time machine

Et l’intégrité des données alors ?

Chaque système de fichiers un tant soit peu moderne dispose d’un ou plusieurs mécanismes dédiés à l’intégrité des données. Après tout, c’est une priorité réclamée sans mot dire par l’utilisateur : il compte avant tout sur une récupération de ses documents. APFS n’y fait pas exception.

Il y a encore ici des hauts et des bas. Par exemple, les clones de fichiers évoqués plus haut peuvent se retourner contre l’utilisateur en cas de corruption matérielle du disque. Si un incident touche le fichier source, tous ses clones en seront affectés. Apple compte en fait sur les fameux snapshots pour restaurer les éventuelles données corrompues. On rappellera au passage l'intérêt des sauvegarde et de l'utilisation de volumes RAID avec protection des données.

La société indique également que la mécanique Error Correcting Code (ECC) sera toujours utilisée. Elle permet de vérifier l’intégrité des données pendant leur transfert, avec correction à la volée si nécessaire. Rien de bien nouveau ici. Par contre, la société ajoute l’algorithme Fletcher pour créer des sommes de contrôle (checksum) sur les métadonnées.

La journalisation est pour sa part toujours présente, même si elle change de mécanique puisque c’est le copy-on-write qui est utilisé pour la traçabilité des opérations. Apple promet que l’installation des mises à jour du système est totalement protégée. En fait, c’était – théoriquement bien sûr – déjà le cas avant, mais la journalisation impliquait une copie complète des données. Encore une fois, avec le copy-on-write, seules les modifications réelles sont enregistrées.

Chiffrement : peu d'informations en pratique

Même s’il ne s’agit pas du chapitre le plus étoffé, le chiffrement reste un point crucial d’APFS. L’un de ses objectifs est en effet de le simplifier en supportant de manière « native » deux scénarios, à savoir avec clé unique (par volume) ou clés multiples. Dans ce deuxième cas, il est possible d’affecter une clé différente pour chaque fichier concerné, et encore une autre pour les métadonnées jugées sensibles.

Dans tous les cas, c’est AES-256 qui sera utilisé pour le chiffrement. Dans sa documentation destinée aux développeurs, Apple précise que la variante utilisée (AES-XTS ou AES-CBC) dépendra du matériel.

Fichiers creux et Space sharing

Les fichiers creux, ou « sparse files » sont intimement liés à la manière dont APFS gère globalement les fichiers et l’espace de stockage. Les poids des données n’est pas toujours représentatif et on entre davantage dans les informations symboliques.

Les fichiers creux (ou troués) sont une manière de déclarer qu’un espace quelconque est réservé. Ils ont plusieurs utilités. Par exemple, réserver une place en prévision du « remplissage » futur du fichier. Ils peuvent également servir à marquer « plus efficacement » – selon Apple – les blocs vides sur un disque.

Il s’agit donc de structures logiques et non physiques. L’espace n’est réellement alloué qu’en cas de besoin. Puisque l’on se trouve encore une fois devant une information devenue symbolique, les API associées permettront aux développeurs de récupérer à la fois les poids physique et logique des fichiers, tout en autorisant des manipulations fines de leurs contenus.

Des détails manquent encore à l'appel

Le potentiel d'APFS est conséquent, ses caractéristiques en faisant très clairement un système de fichiers tourné vers le futur. Signalons quand même quelques points pour tempérer les éventuels effets d'annonce de l'entreprise. Par exemple, la déduplication et la compression des données ne sont pas présentes, même si au vu du fonctionnement global, il n'est pas certain qu'elles soient très utiles.

Ensuite, une bonne partie des fonctionnalités présentées ne sont pas nouvelles. Il suffit d'examiner de plus près Btrfs dans les distributions Linux pour se rendre compte qu'il propose déjà depuis plusieurs années le copy-on-write, les sommes de contrôle ou encore les snapshots. Par ailleurs, ces mêmes fonctionnalités demandent à être exploitées par les développeurs pour en tirer un véritable avantage. Et c'est d'ailleurs ici que l'on entre un peu dans le flou.

APFS n'étant pas open source – et Apple n'ayant aucune intention de l'ouvrir – il faudra se contenter de la documentation mise à disposition des développeurs. Or, celle-ci est pour l'instant assez succincte.  Dans sa FAQ, Apple précise que des spécifications complètes seront publiées. Quand ? L'éditeur ne donne aucune indication précise. En attendant, aux concepteurs d'applications de s'adapter avec les informations à leur disposition.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Un peu d’histoire

Le cas Apple

Pourquoi un nouveau système de fichiers ?

Des appareils mobiles aux ordinateurs

APFS : caractéristiques principales

L’armée des clones

Compatibilité : de nombreux points à connaître

Les snapshots à la rescousse

Et l’intégrité des données alors ?

Chiffrement : peu d'informations en pratique

Fichiers creux et Space sharing

Des détails manquent encore à l'appel

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (66)


Qu’en est il de la compatibilité avec des systèmes tiers ? Existera t’il un driver APFS pour Windows ? Pour Linux ?


Il n’en existe pas pour NTFS de façon “officielle” en écriture alors&nbsp;<img data-src=" />


La réponse est à lire entre les lignes dans l’article.

Le système est fermé et la doc encore très maigre. Apple ne fera sûrement pas de driver pour Linux, et probablement pas pour Windows non plus (actuellement, les drivers HFS+ pour bootcamp sont fait par des tiers il me semble).

La seule possibilité de voir ça arriver sous Linux est donc que la doc soit assez fine ou que des devs motivés passent assez de temps pour comprendre le fonctionnement et pour faire du reverse engineering.




APFS n’étant pas open source – et Apple n’ayant aucune intention de l’ouvrir – il faudra se contenter de la documentation mise à disposition des développeurs.





Tu t’avances un peu sur ce point…

On en sait rien si Apple compte l’ouvrir ou pas. Comme le reste de leur comm’, c’est “on dit rien”.



Apple gère directement un certain nombre de projets opensource fondamentaux pour le fonctionnement de leurs OS (dont notamment CUPS, LLVM, Webkit et d’autres), il intègre aussi beaucoup d’opensource (Apache, java, Python, Tcl/Tk, shells, openssh, etc) et libère (parfois) des technos maison (comme Dispatch ou Swift).



Donc ça me parait assez rapide d’arriver à la conclusion “Apple n’ayant aucune intention de l’ouvrir”…


Boot Camp propose un pilote HFS+ en lecture par Apple (très utile pour lire un disque externe sur un PC, d’ailleurs). Par contre, en écriture, c’est uniquement des pilotes tiers.&nbsp;


En réalité… si. Il a juste jamais été rendu publique. Snow Leopard pouvait écrire sur du NTFS avec le pilote Apple (mais fallait l’activer manuellement). Visiblement une histoire de licence.


Tout à fait, mais ce sont soit des produits existants auxquels ils participent, soit des technos de dev pour suivre le mouvement général dans ce domaine (Facebook, Google et Microsoft font pareil). Dans le cas d’une techno à eux par contre, j’attends vraiment de voir. Cela dit, je serais très heureux de me planter ;)


&gt; Les poids des données n’est pas toujours représentatif et on entre davantage dans les informations symboliques.



Ne le prenez pas mal mais je vous jure, des fois, je ne comprends rien à vos phrases. C’est tellement flou et abstrait. On entre davantage dans les informations symboliques? Qu’est ce que ça peut bien vouloir dire concrètement? J’ai du aller voir ce qu’est un sparse file sur wikipedia pour comprendre tout le paragraphe en fait. Aussi le fait que vous traduisiez logical par symbolique est pas inintéressant en soit (et probablement plus juste que logique), mais vu que c’est pas la pratique (autant que je sache) je trouve que ça ajoute à la confusion plus qu’autre chose. Enfin, c’est titré Fichiers creux et space sharing, mais ça ne parle pas du tout du space sharing, si j’ai tout compris.



&gt; Signalons quand même quelques points pour tempérer les éventuels effets

d’annonce de l’entreprise.&nbsp;Par contre, la déduplication et la

compression des données&nbsp;ne sont pas présentes.



Bon là j’ai compris, mais y a un problème de construction de(s) la phrase je pense.








Vincent_H a écrit :



Tout à fait, mais ce sont soit des produits existants auxquels ils participent, soit des technos de dev pour suivre le mouvement général dans ce domaine (Facebook, Google et Microsoft font pareil). Dans le cas d’une techno à eux par contre, j’attends vraiment de voir. Cela dit, je serais très heureux de me planter ;)







Après, qu’on soit clair, j’y crois moyen aussi. Mais bon, ils peuvent quand même livrer des specs assez détaillées pour permettre des implémentations libres.

Et puis bon, un FS, c’est tellement lié au noyau et aux couches basses d’un OS qu’avoir les sources n’est pas forcément indispensable ni même important à coté des specs.



Mais on verra bien, moi aussi je demande à être étonné :)



Le snapshot/cow est un confort inégalable quand on commence à administrer des gros volumes de données (backup, versioning…).



La contrainte c’est de gérer correctement les snapshots pour éviter d’engorger les disques avec des versions obsolètes des fichiers. C’est si facile de faire un snapshot et d’oublier de le supprimer. <img data-src=" />


Salut .o/

Je ne comprends pas bien cette partie :

&nbsp;« Il a en outre une manière spécifique de diviser l’espace disque. On ne parle en fait plus de partitions mais de volumes, rassemblés dans un ou plusieurs conteneurs. »



Du fait de la formulation de ce passage en particulier, j’aurais tendance à croire que c’est supposé remplacer MBR et GPT… ou que c’est un genre de couche intermédiaire ?_?


Si je lis bien, c’est un système qui gère le disque entier, et non pas une des partitions tells que définies par un MBR ou un GPT ?

Du coup, le système d’amorce de la machine, bios ou autre doit pouvoir lire ça ?



edit: je me suis fait cramer…<img data-src=" />


Ils ont parlé de specs, mais bon il reste quand même une différence nette entre une techno open source avec la licence qui l’accompagne, et des specs suffisamment détaillées pour permettre des implémentations. Bon après comme tu dis, tant que c’est assez détaillé, ça devrait suffire. Et puis ça concerne les devs de produits plus spécifiques, la plupart des applications n’ont pas besoin d’aller trafiquer de manière aussi profonde dans le FS, elles appellent simplement les API système pour faire leur tambouille.&nbsp;


Question benoîte d’un néophyte en la matière: j’ai un compte dropbox, synchronisé entre un PC sous W10, et un MBA. Je n’ai jamais eu de problème jusqu’à maintenant avec la synchro ou avec l’ouverture des fichiers sur l’un ou l’autre. Cela veut-il dire que Dropbox assure le lien entre les deux? Que les fichiers sont convertis pour être compatibles avec chacun des file systems? Comment ça marche, concrètement, pour éviter les problèmes? Parce que j’ai déjà essayé de brancher mon hdd externe avec des fichiers venus de mon PC sur mon Mac, et là j’ai eu des soucis…

merci d’avance de vos réponses! <img data-src=" />


en théorie, si on veut garder HFS+ sur un ssd :

-clone du SSD vers DD externe

-boot sur celui ci, màj du système

-choix de rester en HFS+

-reclone dans l’autre sens



<img data-src=" /><img data-src=" />



Non ? <img data-src=" />


chaque version de Dropbox (Win ou OSX) s’appuie sur le FS local pour lire et écrire les fichiers, ça ne devrait pas poser de soucis.

Mais si c’est sensible pour toi, attends quelques semaines avant de migrer ;)


Dropbox utilise une application/logiciel sur ton windows ou ton osx. Cette application, download/upload le fichier, dans un format qui lui est propre. Et pour le stocker sur le disque, il demande au système (win/osx) : range moi ces données (le fichier) sous le nom /User/dropbox/monfichier.toto. Le système délègue cette opération au filesystem.



Le système permet ensuite de retrouver le fichier quand tu lui donne le nom. C’est ça le filesystem



Pour ton HDD externe, t’as branché, OSX a vu ton disque, s’est demandé quoi en faire. Il a du se dire, tiens c’est du NTFS, connais pas.


Et on sait où ça en est la relève de NTFS chez Microsoft? Je crois que ça s’appelle WinFS…



Sinon, ReiserFS, ça c’est du filesystem qui tue.








AxelTerizaki a écrit :



Et on sait où ça en est la relève de NTFS chez Microsoft? Je crois que ça s’appelle WinFS…







Non, WinFS était un vague projet de R&D a une epoque mais il est parti a la poubelle depuis longtemps.

NTFS a beaucoup evolué. Il n’a pas grand chose à envier à aux meilleurs FS du moment en terme de fonctionnalités.

Si seulement, il était pas si nul en fragmentation et en perfs…







AxelTerizaki a écrit :



Sinon, ReiserFS, ça c’est du filesystem qui tue.







Mouais bof… il commence à se faire vieux et il lui manque beaucoup de fonctionnalités modernes.

Aujourd’hui, la vraie relève est plutot à voir du coté de ext4 pour l’aspect FS généraliste, ZFS pour le stockage pur et Btrfs pour un FS un peu entre les 2.

Sauf que BtrFS commence à avoir qq hoquets dans son développement et on commence a voir des distribs importantes comme RHEL qui droppent leur support officiel… C’est très ennuyeux pour son avenir.









KP2 a écrit :



Mouais bof… il commence à se faire vieux et il lui manque beaucoup de fonctionnalités modernes.

Aujourd’hui, la vraie relève est plutot à voir du coté de ext4 pour l’aspect FS généraliste, ZFS pour le stockage pur et Btrfs pour un FS un peu entre les 2.

Sauf que BtrFS commence à avoir qq hoquets dans son développement et on commence a voir des distribs importantes comme RHEL qui droppent leur support officiel… C’est très ennuyeux pour son avenir.





A mon avis c’était une référence à l’auteur plutôt qu’au produit :)









ragoutoutou a écrit :



A mon avis c’était une référence à l’auteur plutôt qu’au produit :)







Ah mais oui ! <img data-src=" />

J’avais pas capté



<img data-src=" />



@jb&_V ET @uzak –&gt; OK, merci, c’est très clair comme cela :-)


Bel article :)


Wow super article ! Ce APFS semble assez prometteur <img data-src=" />

&nbsp;







AxelTerizaki a écrit :



Sinon, ReiserFS, ça c’est du filesystem qui tue.





<img data-src=" />









AxelTerizaki a écrit :



Et on sait où ça en est la relève de NTFS chez Microsoft? Je crois que ça s’appelle WinFS…&nbsp;





Il existe ReFS, pour l’instant plus pour les entreprises.

&nbsp;



AxelTerizaki a écrit :



Sinon, ReiserFS, ça c’est du filesystem qui tue.



Normal, vu celui qui l’a conçu…wikiwikiwiki ta peng!



Bon, je ne sais pas encore ça marche avec APFS, mais de ce que je comprends c’est le même principe que pour ZFS. Donc en pratique et dans l’idéal, APFS utilisera tout l’espace du disque (comprendre une seule partition physique).



Si on veut utiliser plusieurs systèmes de fichiers APFS (genre 1 pour /, et un autre pour /home), il ne sera pas nécessaire de créer d’autre partition : APFS les fait cohabiter dans le même espace, ce qui fait que pour un DD de 100Go, les 2 systèmes de fichiers peuvent utiliser la totalité des 100Go sans avoir à se préoccuper de combien donner à l’un ou à l’autre au préalable, et aura pour espace disponible l’espace total restant sur la partition : le premier qui remplit le disque a gagné !



Si on souhaite faire cohabiter une autre type de système de fichiers, comme du NTFS pour faire un Boot Camp, alors on crée 2 partitions sur le disque, une pour NTFS et une autre pour APFS, et les systèmes de fichiers APFS se partageront cette partition.



En fait, je crois que la confusion vient du fait qu’on a tendence à confondre partition et système de fichier, puisque historiquement on trouve en général un seul système de fichiers sur une partition.



Après, ZFS permet d’étendre l’espace (le pool) sur plusieurs disques en fonctionnant un peu comme un RAID logiciel, mais je ne sais pas si APFS a vocation à en faire autant.








uzak a écrit :



Du coup, le système d’amorce de la machine, bios ou autre doit pouvoir lire ça ?







Vu que c’est développé par Apple, je pense que la mise à jour vers High-Sierra s’accompagnera d’une mise à jour de l’UEFI des Macs pour prendre en charge le boot sur APFS.



A quand un dossier similaire sur ReFS de Microsoft ? Merci.


Bel article, merci








Jonath a écrit :



Bon, je ne sais pas encore ça marche avec APFS, mais de ce que je comprends c’est le même principe que pour ZFS. Donc en pratique et dans l’idéal, APFS utilisera tout l’espace du disque (comprendre une seule partition physique).



Si on veut utiliser plusieurs systèmes de fichiers APFS (genre 1 pour /, et un autre pour /home), il ne sera pas nécessaire de créer d’autre partition : APFS les fait cohabiter dans le même espace, ce qui fait que pour un DD de 100Go, les 2 systèmes de fichiers peuvent utiliser la totalité des 100Go sans avoir à se préoccuper de combien donner à l’un ou à l’autre au préalable, et aura pour espace disponible l’espace total restant sur la partition : le premier qui remplit le disque a gagné !





Ça, c’est comme avec les répertoires classiques, ça révolutionne pas la poudre.



On fait (enfin moi au moins) des partitions séparés pour le /home pour pouvoir séparer physiquement le système des données, et pouvoir trasher et remodeler un FS entier sans se préoccuper des données utiles.

C’est aussi bien pratique pour un multiboot, vu que chaque os vient avec son filesystem fétiche





Jonath a écrit :



Si on souhaite faire cohabiter une autre type de système de fichiers, comme du NTFS pour faire un Boot Camp, alors on crée 2 partitions sur le disque, une pour NTFS et une autre pour APFS, et les systèmes de fichiers APFS se partageront cette partition.



En fait, je crois que la confusion vient du fait qu’on a tendence à confondre partition et système de fichier, puisque historiquement on trouve en général un seul système de fichiers sur une partition.



Après, ZFS permet d’étendre l’espace (le pool) sur plusieurs disques en fonctionnant un peu comme un RAID logiciel, mais je ne sais pas si APFS a vocation à en faire autant.





Ça c’est bien, comme LVM, qui rajoute une abstraction entre les disques et les filesystem.



Vu les décisions récentes de MS en la matière, pas sûr que ce soit très utile…&nbsp;


De quelles décisions récentes parlez-vous?








uzak a écrit :



Ça, c’est comme avec les répertoires classiques, ça révolutionne pas la poudre.



On fait (enfin moi au moins) des partitions séparés pour le /home pour pouvoir séparer physiquement le système des données, et pouvoir trasher et remodeler un FS entier sans se préoccuper des données utiles.

C’est aussi bien pratique pour un multiboot, vu que chaque os vient avec son filesystem fétiche



Ça c’est bien, comme LVM, qui rajoute une abstraction entre les disques et les filesystem.







Justement en fait : tu cumules un système à la LVM, mais en plus tes systèmes de fichiers ont une taille dynamique. Ca permet entre autres de pouvoir prendre des snapshots de ces systèmes de fichiers (qui ne prennent aucune place au moment de leur création, mais qui grossissent au fur-et-à-mesure des modifications et effacements de données - énorme avantage du système copy-on-write). Par contre, l’énorme inconvénient des systèmes copy-on-write est la fragmentation des données (mais on s’en fiche un peu sur des SSD).



Bon, vu qu’APFS a l’air de pouvoir prendre des snapshots de fichiers (à ce que j’ai cru comprendre), c’est encore plus intéressant que ZFS pour un ordinateur personnel (sur serveur, on s’en fout, on prend des snapshots de FS complets).









KP2 a écrit :



Aujourd’hui, la vraie relève est plutot à voir du coté de ext4 pour l’aspect FS généraliste, ZFS pour le stockage pur et Btrfs pour un FS un peu entre les 2.

Sauf que BtrFS commence à avoir qq hoquets dans son développement et on commence a voir des distribs importantes comme RHEL qui droppent leur support officiel… C’est très ennuyeux pour son avenir.





Tu pourrais en dire plus sur Btrfs ?

Je commençais justement a regarder pour passer le portable sur Btrfs au lieu de Ext 4 (bon, c’est plus pour tester qu’autre chose) ?

Des raisons au fait que certaines distrib ne le supportent plus ? Des problèmes de fiabilité ?



Edit : J’ai bien trouvé ça :&nbsphttps://www.phoronix.com/scan.php?page=news_item&px=RHEL-6.8-Deprecates-…

Mais ça ne m’en dit guère plus.



&nbsp;





Vincent_H a écrit :



Tout à fait, mais ce sont soit des produits existants auxquels ils participent, soit des technos de dev pour suivre le mouvement général dans ce domaine (Facebook, Google et Microsoft font pareil). Dans le cas d’une techno à eux par contre, j’attends vraiment de voir. Cela dit, je serais très heureux de me planter ;)





En techno à “eux” il y a par exemple &nbsp;:&nbsp;Apple Lossless Audio Codec (ALAC)&nbsp;

https://macosforge.github.io/alac/

ou le serveur de calendrier :

https://www.calendarserver.org



Un peu de lecture, en français en plus (sur linuxfr) : BTRFS ne serait plus le futur



Ce que j’en avais retenu c’est que RHEL (distrib orientée professionnels) a retiré le support car elle propose un support sur une très longue période de temps (5 à 10 ans) sur la même version du noyau, ce qui l’oblige à rétroporter toutes les modifications. Elle n’a pas les moyens/l’expertise de le faire pour Btrfs.



C’est en revanche le FS par défaut sous OpenSUSE. Tu peux consulter une série d’article sur ses fonctionnalités en consultant les journaux écrits par AR7 sur linuxfr.








Omnisilver a écrit :



Un peu de lecture, en français en plus (sur linuxfr) : BTRFS ne serait plus le futur



Ce que j’en avais retenu c’est que RHEL (distrib orientée professionnels) a retiré le support car elle propose un support sur une très longue période de temps (5 à 10 ans) sur la même version du noyau, ce qui l’oblige à rétroporter toutes les modifications. Elle n’a pas les moyens/l’expertise de le faire pour Btrfs.



C’est en revanche le FS par défaut sous OpenSUSE. Tu peux consulter une série d’article sur ses fonctionnalités en consultant les journaux écrits par AR7 sur linuxfr.







L’ennui est que red hat est tres prescripteur sur les orientations techno du monde Linux en général. Je pense pas que systemd aurait le même niveau de support si red hat n’avait pas été un de ses 1er support.

Cette histoire avec btrfs ne va peut-être pas aller plus loin mais quand même, c’est un coup pas très agréable…



Bon, après, je m’aperçois que peu de gens semblent connaître VSS sous Windows.



Ce VSS sert surtout à figer le système de fichier pendant des copies pour éviter de faire des copies “partiellement correctes”&nbsp;de fichiers en cours d’écriture. C’est notamment utilisé pour les sauvegarde sur d’autres supports.



Mais c’est aussi utilisable en interne (clichés instantanés)



Vous pouvez prendre des snapshots “volume” (si vous avez un disque dur pour les données et un SSD pour le système, c’est parfait). On peut le déclencher tout les X temps. Vous avez alors un historique qui coûte peu de place (copy on write).


Moi je fais un snapshot VSS tous les soirs.

vshadow -p -scsf e:



Comme ça je peux revenir jusqu’à max 64 jours en arrière (nombre max de snasphots, et ça dépend de l’espace max qu’on a alloué pour les snaphots sur le disque) sur n’importe que répertoire ou n’importe quel fichier.&nbsp;

&nbsp;

Et depuis W10 on y accède facilement via l’item de&nbsp; menu “Restaurer les versions précédentes”. Avant MS avait plus ou moins planqué le truc..








KP2 a écrit :



NTFS a beaucoup evolué. Il n’a pas grand chose à envier à aux meilleurs FS du moment en terme de fonctionnalités.

Si seulement, il était pas si nul en fragmentation et en perfs…





En fragmentation je ne sais pas et je m’en fiche un peu, mais j’ai remarqué que sous Linux quand j’y copiais de gros fichiers un disque externe en NTFS prenait beaucoup plus de CPU que du ext4, même ce dernier en interne donc sur un disque aux débits plus rapides.

Je garde le disque en NTFS en me disant que je peux l’apporter chez quelqu’un et il sera forcément lisible, mais en pratique je ne le fais jamais et je vais finir par le mettre en ext4.







KP2 a écrit :



Aujourd’hui, la vraie relève est plutot à voir du coté de ext4 pour l’aspect FS généraliste, ZFS pour le stockage pur et Btrfs pour un FS un peu entre les 2.

Sauf que BtrFS commence à avoir qq hoquets dans son développement et on commence a voir des distribs importantes comme RHEL qui droppent leur support officiel… C’est très ennuyeux pour son avenir.





D’après mes retours d’utilisateurs avisés et compétents, et les forums spécialisés, Btrfs n’est toujours pas très fiable, malgré tout ce temps, ce qui explique son abandon par RHEL par exemple.



J’aimerais bien savoir ce qui a retenu Apple d’utiliser ZFS, qui est le meilleur filesystem existant, aux possibilités nombreuses et avancées. Si on devait noter un inconvénient par rapport à ext4, il ralentit beaucoup quand on dépasse 80 et 90 % d’occupation, à un point étonnant (j’ai déjà testé sur un disque externe, en fait 2 vieux disques en RAID miroir ZFS, comme ça avec les checksums partout je saurai si le contenu est corrompu).

Sous Linux concernant les fonctions avancées il n’est pas aussi mûr que sous Solaris et FreeBSD, mais il est proposé en standard sous Ubuntu et pour moi jusqu’à présent il est très stable, il me sert à faire du RAID (miroir ou 5) sur des disques dans un bête boîtier de type JBOD. J’en fais juste une utilisation basique, même pas encore de snapshots.







uzak a écrit :



On fait (enfin moi au moins) des partitions séparés pour le /home pour pouvoir séparer physiquement le système des données, et pouvoir trasher et remodeler un FS entier sans se préoccuper des données utiles.





Pour ma part j’ai le système sur une partition, et un “/home” séparé, comme ça je garde toutes mes données en cas de changement de système. En fait j’ai 2 partitions systèmes (une active et une inactive, l’ancien système) et une partition pour mes données, et en pratique ma partition de données est montée sous “/home2”, et je fais quelques liens symboliques depuis “/home” (comme pour “Téléchargements”, ou “~/.cache” sous Ubuntu, qui peut prendre des centaines de Mo), histoire d’avoir des partitions systèmes pas trop grosses (6 G actuellement).







Jonath a écrit :



Ca permet entre autres de pouvoir prendre des snapshots de ces systèmes de fichiers (qui ne prennent aucune place au moment de leur création, mais qui grossissent au fur-et-à-mesure des modifications et effacements de données - énorme avantage du système copy-on-write). Par contre, l’énorme inconvénient des systèmes copy-on-write est la fragmentation des données (mais on s’en fiche un peu sur des SSD).





Même sur un disque dur magnétique en fait. C’est là-dessus que ZFS est utilisé en production et certains font beaucoup de snapshots, et ça tient le coup apparemment (chapeau).







Jonath a écrit :



Bon, vu qu’APFS a l’air de pouvoir prendre des snapshots de fichiers (à ce que j’ai cru comprendre), c’est encore plus intéressant que ZFS pour un ordinateur personnel (sur serveur, on s’en fout, on prend des snapshots de FS complets).





Ce n’est pas plus simple de faire des snapshots d’arborescence en tous cas (plutôt que de fichiers individuels), genre ton répertoire (ou point de montage) où tu mets tous tes documents (bureautique, code) ?



Je coince lors de la copie par clonage. Je vois l’intéret mais ça me fait franchement peur. Admettons que je fasse un clone B et qu’après je change le fichier A, est-ce que B qui est donc un clone partiel en souffre ? Par exemple sous Windows et Office, je fais des doubles de mes documents importants car il arrive (très rarement, mais ça choque) qu’Office demande une réparation d’un fichier alors qu’aucune erreur n’avait pourtant eu lieu… Et bien sûr, ça échoue parfois. Je n’ose pas imaginer ce que ça donnerait pour B si A est réparé de je ne sais quelle maladie imaginaire.



Après, ça a l’air pas mal pour des SSDs mais pas pour des disques traditionnels, car partitionner à l’ancienne permet (indirectement) aussi de lutter contre la fragmentation.


Espérons que ce FS ne consomme pas trop de ressources. Pour la comparaison, BTRFS est hélas connu pour sa forte utilisation CPU. C’est peut être pour cela qu’on ne le trouve pas activé par défaut sur les distros grand public (ex : Ubuntu, OpenSuse), souvent installées sur des laptops. Sur des distros pro et à destination de serveurs (ex : Suse Enterprise), ça peut s’envisager plus sereinement.

Bref, APFS va t-il faire des trous dans nos batteries ou affoler nos ventilos ? <img data-src=" /> (à priori non, je vois mal Apple faire cette bêtise)








OlivierJ a écrit :



En fragmentation je ne sais pas et je m’en fiche un peu, mais j’ai remarqué que sous Linux quand j’y copiais de gros fichiers un disque externe en NTFS prenait beaucoup plus de CPU que du ext4, même ce dernier en interne donc sur un disque aux débits plus rapides.







Certainement le fait que l’implémentation ntfs passe par fuse et n’est certainement pas aussi optimisée qu’un FS natif.







OlivierJ a écrit :



Je garde le disque en NTFS en me disant que je peux l’apporter chez quelqu’un et il sera forcément lisible, mais en pratique je ne le fais jamais et je vais finir par le mettre en ext4.







Moi, je l’aurais fait depuis un bail à ta place :)







OlivierJ a écrit :



D’après mes retours d’utilisateurs avisés et compétents, et les forums spécialisés, Btrfs n’est toujours pas très fiable, malgré tout ce temps, ce qui explique son abandon par RHEL par exemple.







Oui, le dev de btrfs connait qq hoquets depuis qq temps…







OlivierJ a écrit :



J’aimerais bien savoir ce qui a retenu Apple d’utiliser ZFS, qui est le meilleur filesystem existant, aux possibilités nombreuses et avancées.







A mon avis, il doit y avoir 2 raisons principales :




  • techniquement, c’est un excellent FS mais c’est une grosse vache en terme de conso de ressources. Notamment RAM. Perso, je ne l’utilise QUE sur des serveurs et uniquement quand j’ai besoin d’un système de stockage spécifiquement pointu. Voire même QUE pour monter un cluster de stockage dédié à cette tache.

    Alors pour l’utiliser sur des machines qui vont de l’ultrabook au téléphone en passant par une montre ou un petit lecteur multimédia de salon, c’est même pas la peine…



  • au niveau légal, ZFS appartient à Oracle et sa licence est particulièrement tordue. C’est une espèce de GPL mais spécifiquement taillée pour être incompatible avec la GPL (d’ou l’obligation de ré-implémenter le fs sous linux et non réaliser un simple portage).

    A mon avis, Apple doit être un peu coincé a cause de ça. Et généralement, les relations commerciales avec Oracle sont notoirement compliquées quand il s’agit de partager de la techno. Donc bon, je ne serais pas étonné que ce soit un des écueils qui a bloqué son intégration.









grsbdl a écrit :



Espérons que ce FS ne consomme pas trop de ressources. Pour la comparaison, BTRFS est hélas connu pour sa forte utilisation CPU. C’est peut être pour cela qu’on ne le trouve pas activé par défaut sur les distros grand public (ex : Ubuntu, OpenSuse), souvent installées sur des laptops. Sur des distros pro et à destination de serveurs (ex : Suse Enterprise), ça peut s’envisager plus sereinement.

Bref, APFS va t-il faire des trous dans nos batteries ou affoler nos ventilos ? <img data-src=" /> (à priori non, je vois mal Apple faire cette bêtise)







Je suis absolument certain que la conso de ressources a été la contrainte n°1 pour l’élaboration de ce FS. Ca ne fait aucun doute la dessus…



Complètement d’accord, d’autant que l’on va retrouver ce FS sur des systèmes critiques.

Mais ça ne serait pas la première gaffe des ingénieurs fous d’Apple hein <img data-src=" />








grsbdl a écrit :



Complètement d’accord, d’autant que l’on va retrouver ce FS sur des systèmes critiques.

Mais ça ne serait pas la première gaffe des ingénieurs fous d’Apple hein <img data-src=" />







Après, c’est pas dit qu’il obtiendront des résultats égaux ou meilleurs qu’avec HFS+. Si il y a une perte quand meme, c’est peut-être un choix assumé après un arbitrage entre fonctionnalités et performances…



Ou sinon tu utilises snapper.


Je pense qu’il faut voir ça comme un lvm


Le client dropbox de chaque machine interagit avec le fichier en utilisant l’abstraction fournie et n’a même pas à connaître le système de fichier en dessous.








TheKillerOfComputer a écrit :



Je coince lors de la copie par clonage. Je vois l’intéret mais ça me fait franchement peur. Admettons que je fasse un clone B et qu’après je change le fichier A, est-ce que B qui est donc un clone partiel en souffre ?

&nbsp;



Non.&nbsp;Dès que tu vas modifier A, A sera réenregistré ailleurs. Le risque, c’est si tu as un secteur (une cellule) défectueuse et que tu perds les infos de A, tu perds aussi les infos des clones.



Le problème par contre, c’est le comptage d’espace disque libre. Ca peut être confus pour un utilisateur lambda si c’est mal fait.



&nbsp;









gomi a écrit :



Moi je fais un snapshot VSS tous les soirs.

vshadow -p -scsf e:&nbsp;



<img data-src=" />

Sans&nbsp;vshadow, j’utilise PowerShell depuis … longtemps …

&nbsp;([wmiclass]‘Win32_ShadowCopy’).Create(‘c:\’, ‘ClientAccessible’)



Pour enfoncer le clou: les snapshots sont&nbsp;dispos sous Windows depuis XP. Simplement, pour pourvoir les utiliser confortablement, il faut séparer le stockage des données utilisateur du système. Et c’est facile “seulement” depuis Vista avec la réduction de la partition depuis le système.









TheKillerOfComputer a écrit :



Je coince lors de la copie par clonage. Je vois l’intéret mais ça me fait franchement peur. Admettons que je fasse un clone B et qu’après je change le fichier A, est-ce que B qui est donc un clone partiel en souffre ?





Le filesystem gère ça comme il est supposé le faire, tu n’as même pas besoin de savoir qu’il fonctionne en COW, c’est transparent pour l’utilisateur.







TheKillerOfComputer a écrit :



Après, ça a l’air pas mal pour des SSDs mais pas pour des disques traditionnels, car partitionner à l’ancienne permet (indirectement) aussi de lutter contre la fragmentation.





Je ne comprends toujours pas cette obsession pour la fragmentation des Windowsien. On n’est plus en FAT les gars, mais en NTFS, qui est mieux conçu et n’a plus besoin de défragmentation (à supposer que c’était toujours très utile en FAT, c’était surtout pour faire joli quand le mec du service info débarquait sur ton PC).









KP2 a écrit :



Certainement le fait que l’implémentation ntfs passe par fuse et n’est certainement pas aussi optimisée qu’un FS natif.





Oui ça joue, mais tout de même :-) . Il faudrait comparer sur la même machine avec Windows en natif, mais je n’ai pas cet OS.

NB : j’ai changé le fstab pour ajouter l’option “big_writes” pour NTFS (non activée par défaut, bizarre), ce qui descend un bon coup l’occupation CPU ; c’est censé permettre l’écriture par blocs de 128k au lieu de 4k (à je ne sais quel point de la chaîne logique/matérielle).







KP2 a écrit :



Moi, je l’aurais fait depuis un bail à ta place :)





Bon maintenant c’est un peu difficile, j’ai déjà rempli 95 % du disque externe de 2 To en NTFS. <img data-src=" />

Quand j’achèterai mon prochain disque externe (qui sera a priori plus gros), je le ferai avant d’y transférer l’ancien.







KP2 a écrit :



A mon avis, il doit y avoir 2 raisons principales :

Voire même QUE pour monter un cluster de stockage dédié à cette tache.

[…]

Donc bon, je ne serais pas étonné que ce soit un des écueils qui a bloqué son intégration.





<img data-src=" />

Sinon je souscris à ton commentaire éclairé :-) .









OlivierJ a écrit :



Je ne comprends toujours pas cette obsession pour la fragmentation des Windowsien. On n’est plus en FAT les gars, mais en NTFS, qui est mieux conçu et n’a plus besoin de défragmentation (à supposer que c’était toujours très utile en FAT, c’était surtout pour faire joli quand le mec du service info débarquait sur ton PC).







Ouais mais NTFS fragmente quand même beaucoup plus que les autres FS (hormis FAT évidemment).









OlivierJ a écrit :



Le filesystem gère ça comme il est supposé le faire, tu n’as même pas besoin de savoir qu’il fonctionne en COW, c’est transparent pour l’utilisateur.



&nbsp;

J’ai appris à me méfier de la technologie, donc je veux être sûr que tous les cas de figures (tordus) que j’applique seront vraiment supportés. En plus souvent si je fais un double, ce n’est pas sans raison donc avoir un faux double ne me rassure pas vraiment.





Je ne comprends toujours pas cette obsession pour la fragmentation des Windowsien. On n’est plus en FAT les gars, mais en NTFS, qui est mieux conçu et n’a plus besoin de défragmentation (à supposer que c’était toujours très utile en FAT, c’était surtout pour faire joli quand le mec du service info débarquait sur ton PC).





Ça dépend de l’usage aussi <img data-src=" /> mais à dire que ça n’a plus besoin de défragmentation, c’est faux. Mon D:\ est à 29% fragmenté, mon I:\ à 39%… Bon, j’admet que je fais subir BEAUCOUP de choses à mon disque de stockage, et surtout que j’ai coupé la défragmentation automatique car elle avait tendance à s’activer quand il ne fallait pas. Ça n’aide pas <img data-src=" /> Je vais faire une passe tiens…

&nbsp;









OlivierJ a écrit :



Je ne comprends toujours pas cette obsession pour la fragmentation des Windowsien. On n’est plus en FAT les gars, mais en NTFS, qui est mieux conçu et n’a plus besoin de défragmentation (à supposer que c’était toujours très utile en FAT, c’était surtout pour faire joli quand le mec du service info débarquait sur ton PC).&nbsp;



C’est toujours utile.



&nbsp;&nbsp;Si je désactive mon&nbsp;cache SSD, je me&nbsp;retrouve sur un disque dur totalement fragmenté (Windows de défragmente plus un disque dur s’il est derrière un cache SSD).

Au premier démarrage, je peux prendre plus d’une minute pour démarrer, et TOUT rame. Je défragmente, tout devient plus “souple” le démarrage prend 30-40s, et le bruit du disque est bien moins désagréable.



Par ailleurs, sur un répertoire de 800000 fichiers,&nbsp;sans défragmentation c’est 3minutes pour lister les fichiers. Après défragmentation de la MFT (vive contig.exe), 15s.



Maintenant soyons clairs: NTFS fragmente, tout comme ext2, ext3, ext4, …&nbsp;



Sur un serveur, que ce soit du Windows ou du Linux, il y a souvent peu de changements sur la structure du disque –&gt; peu de fragmentation.

Sur un PC de particulier, beaucoup de fichier sont créés, supprimés, agrandis, … La fragmentation arrive.

Faites le test sur un Linux:

&nbsp;* déposez 10000 fichiers images, rebootez.

&nbsp;*Testez les perfs de lecture des fichiers images. Créez des répertoires, compilez un peu, utilisez l’ordi, relevez les mails, allez sur Youtube, facebook pour remplir le cache internet, puis&nbsp;changez les méta données des 10000 fichiers image (ajoutez un mot-clé).

&nbsp;* Rebootez. Testez les perfs de lecture des&nbsp;fichiers images et voyez si&nbsp;elles n’ont pas changé.

–&gt; je doute que rien n’ai changé (même si ce n’est pas&nbsp;énorme,&nbsp;si c’est reproductible ça existe) (PS: sous Windows ce n’est pas énorme non plus)



Bref, je ne vois pas pourquoi on casse du sucre sur NTFS qui a son âge et ses défauts, mais qui&nbsp;a aussi des avantages comme la compression depuis des années, les snapshots depuis des années, les&nbsp;flux de métadonnées depuis des années, la défragmentation en ligne alors que ext4 ne semble pas l’avoir, le fsck partiel en&nbsp;ligne aussi, et la possibilité de limiter la défragmentation (certains outils permettent de réserver de l’espace libre à la suite d’un répertoire pour qu’il ne se fragmente pas lors de l’ajout de fichiers)



Quand à la fiabilité, je n’ai jamais eu de problème avec NTFS, ext2 ou UFS (alors que j’ai perdu des données il y a longtemps avec Reiser)









KP2 a écrit :



Ouais mais NTFS fragmente quand même beaucoup plus que les autres FS (hormis FAT évidemment).





OK, mais quelle conséquence pratique ?

Sur mon portable XP (oui oui) que j’ai eu entre 2014 et 2016, je ne défragmentais jamais, et il fonctionnait pareil du début à la fin.







brice.wernet a écrit :



C’est toujours utile.

Si je désactive mon cache SSD, je me retrouve sur un disque dur totalement fragmenté (Windows de défragmente plus un disque dur s’il est derrière un cache SSD).

Au premier démarrage, je peux prendre plus d’une minute pour démarrer, et TOUT rame. Je défragmente, tout devient plus “souple” le démarrage prend 30-40s, et le bruit du disque est bien moins désagréable.





J’imagine que ce ralentissement très sensible ne se produit qu’après des semaines d’activité, au moins. Ton cas a l’air un peu “violent” quand même. C’est même difficile à comprendre, étant donné que les exécutables de Windows (ou des applications qui se lancent au démarrage) ne bougent pas au cours du temps, en tous cas n’ont aucune raison de fragmenter.







brice.wernet a écrit :



Par ailleurs, sur un répertoire de 800000 fichiers, sans défragmentation c’est 3minutes pour lister les fichiers. Après défragmentation de la MFT (vive contig.exe), 15s.





800 000 fichiers ? <img data-src=" />

Quelque soit le FS, ce n’est pas recommandé, enfin je ne t’apprends rien je suppose. Même 15 s ça me paraît lent d’ailleurs, après cette mythique défragmentation.



Au boulot sur une baie EMC, sur disques magnétiques (des 10 krpm quand même, peut-être des 15 k), j’avais quelques répertoires avec 240 000 fichiers (des images pour une appli de VOD), sur lesquels il y avait un peu de mouvement, effectivement le “ls” prenait quelques secondes, mais moins de 10, pas mal. Les specs EMC disaient de ne pas dépasser 20 000 à 40 000 fichiers, la baie s’en sortait encore pas mal sur les temps d’accès aux fichiers (un nginx piochait dedans en NFS).







brice.wernet a écrit :



Sur un serveur, que ce soit du Windows ou du Linux, il y a souvent peu de changements sur la structure du disque –&gt; peu de fragmentation.[/Quote]

Ça dépend vraiment de ce que fait le serveur. Normalement il écrit régulièrement, sinon il ne sert pas à grand chose :-) .



[quote:5933689:brice.wernet]Faites le test sur un Linux:

 * déposez 10000 fichiers images, rebootez.

 *Testez les perfs de lecture des fichiers images. Créez des répertoires, compilez un peu, utilisez l’ordi, relevez les mails, allez sur Youtube, facebook pour remplir le cache internet, puis changez les méta données des 10000 fichiers image (ajoutez un mot-clé).

 * Rebootez. Testez les perfs de lecture des fichiers images et voyez si elles n’ont pas changé.

–&gt; je doute que rien n’ai changé (même si ce n’est pas énorme, si c’est reproductible ça existe)





Possible que ça ralentisse un peu, mais pour moi ça a toujours été comme invisible, j’ai des “vieilles” partitions sur mon PC fixe depuis plusieurs années, où j’ai plein de fichiers en tous genres, dont mes photos personnelles (de reflex et mobile, des Go), des vidéos, des images téléchargées, etc.







brice.wernet a écrit :



Bref, je ne vois pas pourquoi on casse du sucre sur NTFS qui a son âge et ses défauts, mais qui a aussi des avantages […] la défragmentation en ligne alors que ext4 ne semble pas l’avoir





Je n’ai pas d’avis particulier sur NTFS, mais la défragmentation, je suis à peu près sûr que la toute jeune génération qui s’est mise à l’informatique Windows ces dernières années, pour peu qu’elle ait échappé à des “vieux” qui leur parlent de défragmenter, ignore assez tranquillement cette histoire.



Pour moi, NTFS s’est révélé fiable, tout comme les ext2/3/4.



Juste pour mémoire, je me rappelle que les gars du service informatique, quand ils étaient appelés au chevet d’un PC un peu malade dans les années 2000 (quelque soit la boîte), avaient souvent le réflexe de défragmenter au passage, ce qui m’avait toujours un peu halluciné (parce que le plus souvent ça ne servait à rien à part empêcher l’utilisateur de se servir de son PC pendant tout ce temps) ; ce que j’ai fini par supposer ou comprendre c’est que l’application de défragmentation a un côté magique, ça range tout pour toi avec de jolies couleurs pendant que tu as les bras croisés (le truc dont tu rêves pour chez toi ou la chambre des enfants ;-) ), t’as l’impression que ça va super améliorer la machine ensuite, donc le même du service info a l’impression d’avoir fait son boulot.









TheKillerOfComputer a écrit :



J’ai appris à me méfier de la technologie, donc je veux être sûr que tous les cas de figures (tordus) que j’applique seront vraiment supportés. En plus souvent si je fais un double, ce n’est pas sans raison donc avoir un faux double ne me rassure pas vraiment.





Si tu crois qu’on met sur le marché un filesystem comme ça, sans tests intensifs, internes et via des beta-testeurs… Développer un filesystem est une tâche complexe (on le voit avec btrfs qui a des problèmes, malgré des développeurs payés par Oracle par exemple), surtout avec les fonctionnalités un peu avancées ; et les développeurs et testeurs ne sont pas plus bêtes que nous :-) .







TheKillerOfComputer a écrit :



Ça dépend de l’usage aussi <img data-src=" /> mais à dire que ça n’a plus besoin de défragmentation, c’est faux. Mon D:\ est à 29% fragmenté, mon I:\ à 39%…





Sais-tu réellement ce que signifient ces chiffres ? Et les conséquences pratiques sur l’utilisation de l’ordinateur ?

Encore une fois, sur mon vieil XP, je n’ai jamais défragmenté (ou rarement), le taux affiché était peut-être élevé, mais la machine marchait raisonnablement. C’est plutôt en ajoutant de la mémoire que le PC a retrouvé une 2e jeunesse, et en désactivant ce fichu swap si mal géré (avec 3 Go sur XP ça marche bien).







TheKillerOfComputer a écrit :



Bon, j’admet que je fais subir BEAUCOUP de choses à mon disque de stockage, et surtout que j’ai coupé la défragmentation automatique car elle avait tendance à s’activer quand il ne fallait pas. Ça n’aide pas <img data-src=" /> Je vais faire une passe tiens…





Faudrait commercialiser des patches anti-defrag, faut vous désintoxiquer de ce trucs les gars, les carrés de couleur qui bougent… <img data-src=" />

J’utilise un disque externe de 2 To en NTFS, j’y copie et efface tous les jours des fichiers (plutôt gros, des enregistrements TNT en général), et en plus il est souvent plein entre 95 et 97 %, ce qui doit favoriser la fragmentation technique, mais le disque a l’air toujours aussi performant en copie dans les 2 sens.









OlivierJ a écrit :



OK, mais quelle conséquence pratique ?

Sur mon portable XP (oui oui) que j’ai eu entre 2014 et 2016, je ne défragmentais jamais, et il fonctionnait pareil du début à la fin.







Pour les particuliers, aucune. Ils ne sollicitent pas assez leur matériel pour ressentir des effets même avec NTFS.

Mais pour les pros, dans certains cas, ça peut être un problème. Mais évidemment, on parle de cas plus ou moins extrêmes.

C’est juste qu’avec NTFS dans un cadre pro, tu es beaucoup plus vite concerné par les problèmes de fragmentation qu’avec un autre FS sous linux dès que tu as un peu de volume ou de nombreux fichiers.



Dans le genre “cas limite”, il m’est déjà arrivé de remplacer un serveur de fichiers windows par un serveur samba sous reiserfs (alors que je déteste samba) car la maintenance lié à la défrag était infernale avec windows.

Mais c’était un cas particulier d’une vieille appli dégueulasse qui produisait des centaines de milliers de petits fichiers texte qui devaient être accessibles sur le réseau en SMB.









OlivierJ a écrit :



J’imagine que ce ralentissement très sensible ne se produit qu’après des semaines d’activité, au moins. Ton cas a l’air un peu “violent” quand même. C’est même difficile à comprendre, étant donné que les exécutables de Windows (ou des applications qui se lancent au démarrage) ne bougent pas au cours du temps, en tous cas n’ont aucune raison de fragmenter.&nbsp;



C’est après plusieurs mois (années…) -&gt; oui c’est extrême.

&nbsp;Fait un test avec contig: les mises à jour Windows fragmentent c:\windows et c:\windows\system32. Le problème de Windows n’est pas NTFS, mais le défragmenteur Windows qui ne laisse jamais de place&nbsp;à la fin de c:\windows et c:\windows\system32 (entre autre). Tout est contigu, donc le moindre nouveau fichier&nbsp;se retrouve à la fin du disque.

&nbsp;

Une fois que tu as commencé&nbsp;à défragmenter, tu ne peux plus t’en passer, non pas parce que tu es accro, mais parce que le défragmenteur à tout tassé -&gt; le moindre fichier/répertoire sera fragmenté.

C’est surtout un problème quand on modifie des gros fichiers, quand on a des répertoires compressés (la compression est championne de la fragmentation)&nbsp;ou quand on recompile&nbsp;de gros programmes. Mais c’est&nbsp;d’habitude peu visible sur les perfs, notamment avec de gros disques qui ne sont pas pleins ou des raids, et c’est sans conséquence sur un SSD.

&nbsp;

Les 800000 fichiers, malheureusement, ils n’étaient pas sur un belle baie, mais un&nbsp;vieux truc donc le cache était très limité, et la batterie défaillante.



&nbsp;









KP2 a écrit :



Pour les particuliers, aucune. Ils ne sollicitent pas assez leur matériel pour ressentir des effets même avec NTFS.

Mais pour les pros, dans certains cas, ça peut être un problème. Mais évidemment, on parle de cas plus ou moins extrêmes.

C’est juste qu’avec NTFS dans un cadre pro, tu es beaucoup plus vite concerné par les problèmes de fragmentation qu’avec un autre FS sous linux dès que tu as un peu de volume ou de nombreux fichiers.





Si j’ai eu un portable sous XP entre 2014 et 2016, c’était bien dans un cadre pro ! (tu peux relire mon commentaire à cette lumière)

A titre personnel, je n’ai jamais eu Windows.







KP2 a écrit :



Dans le genre “cas limite”, il m’est déjà arrivé de remplacer un serveur de fichiers windows par un serveur samba sous reiserfs (alors que je déteste samba) car la maintenance lié à la défrag était infernale avec windows.





Sacré Windows, même pour ça on a meilleur compte à du Linux + Samba :-) .

Perso je préférerai toujours du Linux + Samba à du Windows, ce cancer de l’informatique (OK on n’est pas vendredi, je la garde pour plus tard).









brice.wernet a écrit :



Une fois que tu as commencé à défragmenter, tu ne peux plus t’en passer, non pas parce que tu es accro, mais parce que le défragmenteur à tout tassé -&gt; le moindre fichier/répertoire sera fragmenté.





Haha c’est bien ce que je disais, faut vous désintoxiquer les gars. <img data-src=" />



Marrant ces problématiques Windows qu’on n’a pas du tout ailleurs. Du coup pas étonnant qu’en particulier les unixiens (et linuxiens) aient un regard condescendant sur cet écosystème.

(pour moi qui suis moins jeune que la moyenne, j’ai connu Amiga dans les années 80 et Unix au début des 90, forcément Microsoft (avant XP) c’était vraiment vu comme des guignols au niveau technique (et même après pour certains).









OlivierJ a écrit :



Si j’ai eu un portable sous XP entre 2014 et 2016, c’était bien dans un cadre pro ! (tu peux relire mon commentaire à cette lumière)

A titre personnel, je n’ai jamais eu Windows.









Quand je dis “pro”, j’entends sur des serveurs.



Un portable pour un péquin, même si il travaille avec, ça reste un usage de particulier (et encore, les usages domestiques (jeux, video, photo) sont parfois bien plus exigeants matériellement que la plupart des usages “dans le cadre professionnel”).









OlivierJ a écrit :



et les développeurs et testeurs ne sont pas plus bêtes que nous :-) .



&nbsp;

Sincèrement, entre Windows 10 et les pépins qu’il me fait subir sans compter le manque d’options pourtant présents sur les versions précédentes, en passant par les jeux dont notamment Eve Online extrémement mal suivi, les choix de Mozilla et compagnie sur Firefox qui en disent long sur le niveau de stupidité interne, etc…




Désolé d'avoir de GROS doutes sur l'intelligence des développeurs en ce moment. Eux et les chefs de projets. J'ai l'impression qu'on a en service en ce moment une génération de glandeurs et d'incompétents.     





Ce qui renforce ma méfiance.



Donc oui, les nouveaux FS pour les autres, moi je reste sur ce qui marche à coup sûr <img data-src=" />





Sais-tu réellement ce que signifient ces chiffres ? Et les conséquences pratiques sur l’utilisation de l’ordinateur ?





Ça veut dire que certains de mes fichiers secondaires seront plus pénibles à lire pour mon disque. Mais vu que j’ai partitionné de façon à réduire la charge (musiques par ci, gros fichiers par là, et softwares sur un autre), l’impact est faible sinon nul. Sur un ordinateur de Mme Michu, à un moment ça doit forcément conduire à plus de latence en lecture, et vu que leur ordinateur est de base une [Censuré] infâme avec en plus du Norton/Bitdefender et autres usines à gaz, ça ne doit pas aider.

&nbsp;



Faudrait commercialiser des patches anti-defrag, faut vous désintoxiquer de ce trucs les gars, les carrés de couleur qui bougent… <img data-src=" />





J’adore les carrés rouges qui bougent <img data-src=" /> Enfin ça c’était Windows 95. J’ai appris à partitionner depuis et donc à ranger mes données. Je ne m’en soucie plus vraiment vu que je “défrag” en changeant de disque dur <img data-src=" /> en quelque sorte.









TheKillerOfComputer a écrit :



Sincèrement, entre Windows 10 et les pépins qu’il me fait subir sans compter le manque d’options pourtant présents sur les versions précédentes[/Quote]

OK, à part Windows et MS alors <img data-src=" />



[quote:5933839:TheKillerOfComputer]les choix de Mozilla et compagnie sur Firefox qui en disent long sur le niveau de stupidité interne





Affirmation qui me semble osée et qui demanderait à être justifiée.



Quant aux développeurs côté Apple, ils ont tendance à fournir des choses qui marchent plutôt bien.







TheKillerOfComputer a écrit :



Ça veut dire que certains de mes fichiers secondaires seront plus pénibles à lire pour mon disque. Mais vu que j’ai partitionné de façon à réduire la charge (musiques par ci, gros fichiers par là, et softwares sur un autre), l’impact est faible sinon nul.





Je vois mal comment ça pourrait changer quelque chose à la fragmentation (réelle ou théorique) de tes systèmes de fichiers, elle existe toujours indépendamment.







TheKillerOfComputer a écrit :



Sur un ordinateur de Mme Michu, à un moment ça doit forcément conduire à plus de latence en lecture, et vu que leur ordinateur est de base une [Censuré] infâme avec en plus du Norton/Bitdefender et autres usines à gaz, ça ne doit pas aider.





C’est clair que virer toutes les béquilles qu’on met sur du MS, à commencer par les anti-virus gourmands, ça booste la machine :-) .

 





TheKillerOfComputer a écrit :



Je ne m’en soucie plus vraiment vu que je “défrag” en changeant de disque dur <img data-src=" /> en quelque sorte.





Effectivement c’est une méthode radicale pour retrouver un disque ordonné, encore que NTFS a l’air de fragmenter rapidement dès qu’on fait des mises à jour.