4 votes

D'où viennent les TB supplémentaires de données lorsque je scanne le disque dur?

Je ne suis pas un utilisateur de Mac habituel. Je voulais obtenir un aperçu de l'utilisation du disque sur un Mac, donc ayant installé ncdu via homebrew il y a longtemps, j'ai fait sudo ncdu -x /. En réalisant que cela prendrait une éternité, j'ai installé duc avec brew install duc, je l'ai configuré en mode profil avec sudo duc index -xpH /. (Drapeaux: -x = ne pas traverser les limites du système de fichiers, -H = compter les liens physiques une seule fois, -p = progression). Ce matin, ce Mac de 120 Go avait réussi à scanner jusqu'à 2 To. J'ai arrêté le processus et déconnecté le WiFi, au cas où il aurait monté le lecteur réseau, et j'ai réessayé: même problème. J'ai abandonné et suis revenu à ncdu: même problème. J'ai accepté la défaite et installé une application graphique qui semble faire le travail.

Question: d'où proviennent toutes ces données? Je suis familier avec le double comptage des liens physiques, mais à la fois duc et ncdu peuvent corriger cela. Je n'ai jamais vu un comportement comme celui-ci sur aucun système Linux; clairement, le modèle de système de fichiers Mac est très différent. Que se passe-t-il?

(Je me rends compte qu'une partie de ce qui se passe est que j'essaie naïvement d'utiliser des outils Linux sur un Mac. J'ai corrigé cela. Mais je veux savoir ce qui se passe au niveau du système de fichiers car je n'ai jamais vu ce genre de problème à cette échelle auparavant: si vous oubliez d'exclure des chemins spéciaux sous Linux, vous pourriez obtenir quelques Mo de données inutiles (même si la plupart échouent simplement); les liens physiques peuvent vous donner plus que ce que vous vouliez, mais pas dans cette ordre de grandeur. Clairement, macOS expose un modèle sous-jacent très différent.)

5voto

Oskar Points 1242

Ce qui se passe en résumé, c'est que les "outils de type exploration du système de fichiers" doivent être mis à jour pour APFS en général et les instantanés, notamment les liens fermes. Une fois cela fait, vous aurez une meilleure expérience.

Je les utiliserais à l'intérieur d'un dossier personnel de l'utilisateur et j'utiliserais un outil comme Daisy Disk ou les outils d'espace disque d'Apple pour repérer les fichiers et allocations auxquels vous ne vous attendez pas sur une base "système".

Ou vous pouvez creuser dans les groupes de volumes APFS et apprendre quand et où les outils de recherche du système de fichiers peuvent se retrouver piégés dans des boucles ou des impasses ou des "trous de ver" vers d'autres systèmes de fichiers (y compris les boucles créées par l'utilisateur et les liens fermes synthétiques).

2 votes

Oh la la, ce n'est vraiment pas juste unix ... ta. Certains trucs très sympas ici comme le volume de démarrage superposé/scellé, mais ce n'est pas étonnant que les crawlers restent terriblement coincés dedans. Cela explique aussi pourquoi je ne l'avais jamais remarqué auparavant---j'ai toujours travaillé dans des sous-répertoires de ~.

0 votes

Voilà une bonne manière de le dire @2e0byo et il faut aussi considérer que iOS / iPadOS ne sont pas seulement des systèmes Unix - ce sont des bases d'utilisateurs massives avec des heures de CPU en fonctionnement...

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X