Je pense utiliser NTFS compressé sur mon disque dur externe USB. Il devrait être utilisé uniquement pour les sauvegardes.
1) Oui, il est possible d'y accéder depuis Liunx. Comme d'autres l'ont expliqué, ntfs-3g est capable de gérer les ntfs compressés.
2) fiabilité : la compression est présente dans ntfs depuis longtemps (depuis Windows NT, cf. http://www.ntfs.com/ntfs-compressed.htm ). Je ne vois pas de problèmes de fiabilité sous Windows. Je ne suis pas aussi sûr des implémentations non-Windows (par exemple linux). Si votre seule préoccupation est de lire les données sous linux, cela ne pose aucun problème de fiabilité (le montage en lecture seule est de toute façon une bonne idée lors de la restauration de sauvegardes).
Les données sont également compressées au niveau de la grappe qui est généralement de 4 ko. Une corruption physique du disque n'affecte que les clusters individuels, pas les fichiers entiers. À cet égard, les fichiers NTFS compressés devraient être tout aussi fiables que les fichiers non compressés.
3) Performance : L'article de la KB que vous citez indique que les performances peuvent être affectées sur une période de trois ans. serveur où l'unité centrale est déjà saturée. Sur un système de bureau avec un CPU actuel tel que vous le décrivez, l'utilisation de ntfs compressés pour les sauvegardes, ne devrait pas avoir d'impact significatif sur les performances. Au contraire, si vous stockez des données compressibles, vous pouvez en fait gagner en performance car vous avez moins d'entrées/sorties. Cela est particulièrement vrai si l'interface (USB 2.0) est lente par rapport au CPU. Je suppose que votre CPU devrait facilement être capable de saturer une liaison USB 2.0 en écrivant ou en lisant des fichiers ntfs compressés.
4) Si vous définissez l'indicateur de compression pour l'ensemble du système de fichiers, vous ne devriez pas avoir le problème des fichiers déplacés non compressés.
NTFS ne transfère jamais de fichiers compressés, que ce soit dans le pilote Windows ou Linux. Cette optimisation n'existe pas, malheureusement. Il faudrait aller à un niveau extrêmement bas pour y parvenir : Créer le fichier et les métadonnées, pré-allouer l'espace, puis écrire de manière brute les données compressées sur le MFT et les clusters alloués. Donc, dans une utilisation normale, vous ne gagnerez rien en termes d'E/S.
Je pense qu'il est accessible depuis Linux, mais je n'en suis pas sûr.
Fiable dans quel sens ? Il est plus facile pour vos données d'être corrompues, mais je ne suis pas sûr que ce soit ce que vous voulez dire.
C'est plus lent au niveau du processeur, mais plus rapide au niveau des E/S. Si votre processeur est beaucoup plus rapide que votre disque, il peut être intéressant de lire moins de données mais d'effectuer un certain traitement, plutôt que de lire d'énormes fichiers mais d'éviter le post-traitement.
Vous ne pouvez pas éviter cela, cela dépend de la façon dont les applications ont été programmées. Je me souviens avoir vu un paramètre dans Windows qui devait faire quelque chose avec ça, mais je ne pense pas qu'il fasse ce dont vous avez besoin -- je mettrai à jour ce message si c'est le cas.
Ad 2 : Je veux dire s'il n'y a pas de bogues dans le système de fichiers ou autre. Ad 4 : En fait, je vais copier des fichiers depuis un autre disque non compressé, probablement en utilisant rsync. Je ne vois vraiment pas pourquoi une application devrait se soucier des éléments internes du système de fichiers, IMHO c'est le travail du FS de faire tout le travail.
@maartinus : #2 : Eh bien, je n'ai pas de données concrètes à ce sujet, mais personnellement, je ferais confiance à la version Windows mais pas à la version Linux. #4 : C'est simplement une question de conserver les paramètres par défaut, pas une question de l'application qui se soucie. Lorsqu'un fichier de 2 Go passe d'un dossier non compressé à un dossier compressé, il n'y a aucune raison pour que le système de fichiers passe beaucoup de temps à le compresser - il le laisse simplement non compressé, d'où le problème. Je ne pense pas que vous puissiez faire grand-chose à ce sujet. @Sathya : Ah merci.
Le site ntfs-3g prend en charge la lecture, l'ajout et (depuis peu) la modification des fichiers compressés.
Actuellement, la lecture des fichiers compressés est supportée par toutes les versions de ntfs-3g. La création de nouveaux fichiers compressés, l'effacement du contenu et l'ajout de données aux fichiers compressés existants sont pris en charge depuis ntfs-3g-2009.11.14. La modification de fichiers compressés existants en écrasant les données existantes (ou les trous existants) est supportée depuis ntfs-3g-2010.8.8.
Le système de fichiers est aussi fiable que ses homologues habituels sous Linux, ext3/ext4.
Le site ntfs-3g Le conducteur gère tout très bien. (Il pourrait ont encore quelques bogues dans la modification des fichiers compressés ; comme le dit la citation ci-dessus, cela n'a été ajouté que dans la version 2010.8.8).
(pas de réponse)
Lorsque ce problème est causé par des programmes créant un fichier non compressé ailleurs et le déplaçant ultérieurement vers son emplacement prévu, la solution de contournement est simple : Réactivez la compression sur ces fichiers.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
