Dans le message :,
Sergio a pris la peine d'écrire
ce qui suit :Sabrem JORAM a formulé ce mardi :Dans le domaine de la "théorie", dans l'hypothèse d'une partition
consacrée au "swap", verrais-tu un avantage (ou désavantage par
rapport à la FAT16) à utiliser plutôt une FAT32 formatée en 4 Ko
(qui est l'unité de base de la taille des pages chargées par XP) ?
Dans ce cas là, "plus c'est primitif, mieux c'est". LA FAT16 a des
clusters plus grands (d'où des adresses cluster plus petites), ça
va
(un peu) mieux...
Ch'u d'accord avec Cherge !!!!
:-)
Dans ce cas précis, à savoir un seul fichier (pagefile.sys) de taille
presqu'égale à celle de la partition, des clusters de 32 ko (FAT16)
sont préférables à des clusters de 4 ko (FAT32) car les accès seront
plus rapides.
1 accès physique à 32 ko en UNE SEULE fois est plus rapide que 8
accès physiques successifs à 4 ko.
Il ne faut pas confondre :
- l'accès logique
(qui est, en effet, par pages de 4 ko par le Virtual
Memory Manager (VMM))
- l'accès physique
(par clusters de 32 ko - ou de 4 ko - par le contrôleur
de disque)
En principe, statistiquement, le VMM va demander successivement des
pages de 4 ko CONTIGÜES.
Donc avec des clusters de 32 ko, si le VMM demande une page de 4 ko
dans une nouvelle zone de la mémoire virtuelle, on aura dans le cache
disque les 4 ko demandés avec en prime 7 autres pages contigües, qui
seront alors immédiatement disponibles pour une prochaine demande du
VMM.
Disons que çà améliore le processus, mais je ne suis pas "hypnotisé"
par çà!
Voir une partition de swap en FAT32 ne me fera pas hurler au scandale
!!!
Etre un ayatollah de la yoctoseconde n'est pas du tout mon style!
Chercher les perfs à tout prix est valable pour un serveur.
Mais sur une station de travail, à moins d'être un "gamer" ou
développeur acharné, la vitesse a peu d'importance, vu que dans la
majeure partie du temps l'ordi ne fait que "glander" lamentablement,
à cause des délais énormes (à l'échelle du CPU) imposés par
l'utilisateur entre chaque frappe au clavier ! ;-)
Dans le message :mn.1a017d6a8678b6e5.9866@serge.delbono.net.invalid,
Sergio <laposte@serge.delbono.net.invalid> a pris la peine d'écrire
ce qui suit :
Sabrem JORAM a formulé ce mardi :
Dans le domaine de la "théorie", dans l'hypothèse d'une partition
consacrée au "swap", verrais-tu un avantage (ou désavantage par
rapport à la FAT16) à utiliser plutôt une FAT32 formatée en 4 Ko
(qui est l'unité de base de la taille des pages chargées par XP) ?
Dans ce cas là, "plus c'est primitif, mieux c'est". LA FAT16 a des
clusters plus grands (d'où des adresses cluster plus petites), ça
va
(un peu) mieux...
Ch'u d'accord avec Cherge !!!!
:-)
Dans ce cas précis, à savoir un seul fichier (pagefile.sys) de taille
presqu'égale à celle de la partition, des clusters de 32 ko (FAT16)
sont préférables à des clusters de 4 ko (FAT32) car les accès seront
plus rapides.
1 accès physique à 32 ko en UNE SEULE fois est plus rapide que 8
accès physiques successifs à 4 ko.
Il ne faut pas confondre :
- l'accès logique
(qui est, en effet, par pages de 4 ko par le Virtual
Memory Manager (VMM))
- l'accès physique
(par clusters de 32 ko - ou de 4 ko - par le contrôleur
de disque)
En principe, statistiquement, le VMM va demander successivement des
pages de 4 ko CONTIGÜES.
Donc avec des clusters de 32 ko, si le VMM demande une page de 4 ko
dans une nouvelle zone de la mémoire virtuelle, on aura dans le cache
disque les 4 ko demandés avec en prime 7 autres pages contigües, qui
seront alors immédiatement disponibles pour une prochaine demande du
VMM.
Disons que çà améliore le processus, mais je ne suis pas "hypnotisé"
par çà!
Voir une partition de swap en FAT32 ne me fera pas hurler au scandale
!!!
Etre un ayatollah de la yoctoseconde n'est pas du tout mon style!
Chercher les perfs à tout prix est valable pour un serveur.
Mais sur une station de travail, à moins d'être un "gamer" ou
développeur acharné, la vitesse a peu d'importance, vu que dans la
majeure partie du temps l'ordi ne fait que "glander" lamentablement,
à cause des délais énormes (à l'échelle du CPU) imposés par
l'utilisateur entre chaque frappe au clavier ! ;-)
Dans le message :,
Sergio a pris la peine d'écrire
ce qui suit :Sabrem JORAM a formulé ce mardi :Dans le domaine de la "théorie", dans l'hypothèse d'une partition
consacrée au "swap", verrais-tu un avantage (ou désavantage par
rapport à la FAT16) à utiliser plutôt une FAT32 formatée en 4 Ko
(qui est l'unité de base de la taille des pages chargées par XP) ?
Dans ce cas là, "plus c'est primitif, mieux c'est". LA FAT16 a des
clusters plus grands (d'où des adresses cluster plus petites), ça
va
(un peu) mieux...
Ch'u d'accord avec Cherge !!!!
:-)
Dans ce cas précis, à savoir un seul fichier (pagefile.sys) de taille
presqu'égale à celle de la partition, des clusters de 32 ko (FAT16)
sont préférables à des clusters de 4 ko (FAT32) car les accès seront
plus rapides.
1 accès physique à 32 ko en UNE SEULE fois est plus rapide que 8
accès physiques successifs à 4 ko.
Il ne faut pas confondre :
- l'accès logique
(qui est, en effet, par pages de 4 ko par le Virtual
Memory Manager (VMM))
- l'accès physique
(par clusters de 32 ko - ou de 4 ko - par le contrôleur
de disque)
En principe, statistiquement, le VMM va demander successivement des
pages de 4 ko CONTIGÜES.
Donc avec des clusters de 32 ko, si le VMM demande une page de 4 ko
dans une nouvelle zone de la mémoire virtuelle, on aura dans le cache
disque les 4 ko demandés avec en prime 7 autres pages contigües, qui
seront alors immédiatement disponibles pour une prochaine demande du
VMM.
Disons que çà améliore le processus, mais je ne suis pas "hypnotisé"
par çà!
Voir une partition de swap en FAT32 ne me fera pas hurler au scandale
!!!
Etre un ayatollah de la yoctoseconde n'est pas du tout mon style!
Chercher les perfs à tout prix est valable pour un serveur.
Mais sur une station de travail, à moins d'être un "gamer" ou
développeur acharné, la vitesse a peu d'importance, vu que dans la
majeure partie du temps l'ordi ne fait que "glander" lamentablement,
à cause des délais énormes (à l'échelle du CPU) imposés par
l'utilisateur entre chaque frappe au clavier ! ;-)
Dans mes arguments en faveur de FAT (en plus du multiboot), j'ai oublié,
honte sur moi, la partition dédiée au SWAP!
Comme vient de le préciser également Sergio, il est PRÉFÉRABLE qu'elle soit
en FAT (et vu la taille, ce sera en FAT16), à cause justement du coté
"rudimentaire" de FAT.
Car NTFS possèdant une copie de la MFT en plein milieu (environ) de la
partition, cela provoquerait une fragmentation du fichier de swap.
Avec une FAT on n'a pas ce problème.
De plus, comme les clusters sont plus gros (32 ko pour une 2 Go) et vu qu'il
n'y a qu'un seul fichier (pagefile.sys), ils sont donc contigus, donc DANS
CE CAS les transferts sont plus rapides.
Dans mes arguments en faveur de FAT (en plus du multiboot), j'ai oublié,
honte sur moi, la partition dédiée au SWAP!
Comme vient de le préciser également Sergio, il est PRÉFÉRABLE qu'elle soit
en FAT (et vu la taille, ce sera en FAT16), à cause justement du coté
"rudimentaire" de FAT.
Car NTFS possèdant une copie de la MFT en plein milieu (environ) de la
partition, cela provoquerait une fragmentation du fichier de swap.
Avec une FAT on n'a pas ce problème.
De plus, comme les clusters sont plus gros (32 ko pour une 2 Go) et vu qu'il
n'y a qu'un seul fichier (pagefile.sys), ils sont donc contigus, donc DANS
CE CAS les transferts sont plus rapides.
Dans mes arguments en faveur de FAT (en plus du multiboot), j'ai oublié,
honte sur moi, la partition dédiée au SWAP!
Comme vient de le préciser également Sergio, il est PRÉFÉRABLE qu'elle soit
en FAT (et vu la taille, ce sera en FAT16), à cause justement du coté
"rudimentaire" de FAT.
Car NTFS possèdant une copie de la MFT en plein milieu (environ) de la
partition, cela provoquerait une fragmentation du fichier de swap.
Avec une FAT on n'a pas ce problème.
De plus, comme les clusters sont plus gros (32 ko pour une 2 Go) et vu qu'il
n'y a qu'un seul fichier (pagefile.sys), ils sont donc contigus, donc DANS
CE CAS les transferts sont plus rapides.
La lecture ne pose d'ailleurs aucun souci, même si on n'a pas spécialement
d'outils...
toutes mes partitions NTFS chez moi, sont parfaitement lisibles depuis mon
PC win 98.
(et comme de toutes façons, j'ai configuré mon réseau pour
interdire à quiconque d'aller écrire quoi que ce soit sur un PC qui n'est
pas le sien, je peux dire que je ne m'aperçois quasiment pas de la
différence entre NTFS et Fat 32 pour une utilisation habituelle des
fichiers)
La lecture ne pose d'ailleurs aucun souci, même si on n'a pas spécialement
d'outils...
toutes mes partitions NTFS chez moi, sont parfaitement lisibles depuis mon
PC win 98.
(et comme de toutes façons, j'ai configuré mon réseau pour
interdire à quiconque d'aller écrire quoi que ce soit sur un PC qui n'est
pas le sien, je peux dire que je ne m'aperçois quasiment pas de la
différence entre NTFS et Fat 32 pour une utilisation habituelle des
fichiers)
La lecture ne pose d'ailleurs aucun souci, même si on n'a pas spécialement
d'outils...
toutes mes partitions NTFS chez moi, sont parfaitement lisibles depuis mon
PC win 98.
(et comme de toutes façons, j'ai configuré mon réseau pour
interdire à quiconque d'aller écrire quoi que ce soit sur un PC qui n'est
pas le sien, je peux dire que je ne m'aperçois quasiment pas de la
différence entre NTFS et Fat 32 pour une utilisation habituelle des
fichiers)
La Fred a écrit :
La lecture ne pose d'ailleurs aucun souci, même si on n'a pas spécialement
d'outils...
toutes mes partitions NTFS chez moi, sont parfaitement lisibles depuis mon
PC win 98.
Sans outils additionnels (par exemple ntfsdos ou ntfs.sys de Sysinternals),
on ne peut pas accéder à une partition NTFS locale sous Windows 9x.
La Fred a écrit :
La lecture ne pose d'ailleurs aucun souci, même si on n'a pas spécialement
d'outils...
toutes mes partitions NTFS chez moi, sont parfaitement lisibles depuis mon
PC win 98.
Sans outils additionnels (par exemple ntfsdos ou ntfs.sys de Sysinternals),
on ne peut pas accéder à une partition NTFS locale sous Windows 9x.
La Fred a écrit :
La lecture ne pose d'ailleurs aucun souci, même si on n'a pas spécialement
d'outils...
toutes mes partitions NTFS chez moi, sont parfaitement lisibles depuis mon
PC win 98.
Sans outils additionnels (par exemple ntfsdos ou ntfs.sys de Sysinternals),
on ne peut pas accéder à une partition NTFS locale sous Windows 9x.
Jean-Claude BELLAMY a écrit :
Dans mes arguments en faveur de FAT (en plus du multiboot), j'ai
oublié, honte sur moi, la partition dédiée au SWAP!
Comme vient de le préciser également Sergio, il est PRÉFÉRABLE
qu'elle soit en FAT (et vu la taille, ce sera en FAT16), à cause
justement du coté "rudimentaire" de FAT.
Car NTFS possèdant une copie de la MFT en plein milieu (environ) de
la partition, cela provoquerait une fragmentation du fichier de swap.
Avec une FAT on n'a pas ce problème.
Par curiosité, quelle peut être la taille de la MFT d'une partition
NTFS de 2 Gio ne contenant que le fichier de swap ? Ça ne doit pas
être bien gros.
D'autre part, n'y a-t-il pas aussi en FAT une copie de la FAT
quelque part au milieu de la partition ?
De toute façon, la présence d'un petit "trou" pour la copie de la MFT
au milieu du fichier swap est-elle si gênante que ça ? La
fragmentation devient gênante quand elle augmente de façon
significative le temps de lecture/écriture d'un fichier, c'est-à-dire
quand le temps d'accès perdu à sauter d'un cluster à l'autre entre
deux fragments devient non négligeable devant le temps de
lecture/écriture des clusters du fichier. Or ici on aurait *un* saut
pour 2 Gio !
De plus, comme les clusters sont plus gros (32 ko pour une 2 Go) et
vu qu'il n'y a qu'un seul fichier (pagefile.sys), ils sont donc
contigus, donc DANS CE CAS les transferts sont plus rapides.
NTFS permet aussi de définir des clusters de 32 Kio sur une partition
de 2 Gio, ce n'est pas un argument.
En fait, je retiens plutôt qu'il vaut mieux éviter au maximum les
interactions de la gestion du swap avec la gestion d'un système de
fichiers "trop" élaboré comme NTFS : MFT, journalisation,
indexation... L'idéal serait que le swap utilise directement une
partition brute sans système de fichiers. Une partition de swap comme
sous Linux en somme. ;-)
Jean-Claude BELLAMY a écrit :
Dans mes arguments en faveur de FAT (en plus du multiboot), j'ai
oublié, honte sur moi, la partition dédiée au SWAP!
Comme vient de le préciser également Sergio, il est PRÉFÉRABLE
qu'elle soit en FAT (et vu la taille, ce sera en FAT16), à cause
justement du coté "rudimentaire" de FAT.
Car NTFS possèdant une copie de la MFT en plein milieu (environ) de
la partition, cela provoquerait une fragmentation du fichier de swap.
Avec une FAT on n'a pas ce problème.
Par curiosité, quelle peut être la taille de la MFT d'une partition
NTFS de 2 Gio ne contenant que le fichier de swap ? Ça ne doit pas
être bien gros.
D'autre part, n'y a-t-il pas aussi en FAT une copie de la FAT
quelque part au milieu de la partition ?
De toute façon, la présence d'un petit "trou" pour la copie de la MFT
au milieu du fichier swap est-elle si gênante que ça ? La
fragmentation devient gênante quand elle augmente de façon
significative le temps de lecture/écriture d'un fichier, c'est-à-dire
quand le temps d'accès perdu à sauter d'un cluster à l'autre entre
deux fragments devient non négligeable devant le temps de
lecture/écriture des clusters du fichier. Or ici on aurait *un* saut
pour 2 Gio !
De plus, comme les clusters sont plus gros (32 ko pour une 2 Go) et
vu qu'il n'y a qu'un seul fichier (pagefile.sys), ils sont donc
contigus, donc DANS CE CAS les transferts sont plus rapides.
NTFS permet aussi de définir des clusters de 32 Kio sur une partition
de 2 Gio, ce n'est pas un argument.
En fait, je retiens plutôt qu'il vaut mieux éviter au maximum les
interactions de la gestion du swap avec la gestion d'un système de
fichiers "trop" élaboré comme NTFS : MFT, journalisation,
indexation... L'idéal serait que le swap utilise directement une
partition brute sans système de fichiers. Une partition de swap comme
sous Linux en somme. ;-)
Jean-Claude BELLAMY a écrit :
Dans mes arguments en faveur de FAT (en plus du multiboot), j'ai
oublié, honte sur moi, la partition dédiée au SWAP!
Comme vient de le préciser également Sergio, il est PRÉFÉRABLE
qu'elle soit en FAT (et vu la taille, ce sera en FAT16), à cause
justement du coté "rudimentaire" de FAT.
Car NTFS possèdant une copie de la MFT en plein milieu (environ) de
la partition, cela provoquerait une fragmentation du fichier de swap.
Avec une FAT on n'a pas ce problème.
Par curiosité, quelle peut être la taille de la MFT d'une partition
NTFS de 2 Gio ne contenant que le fichier de swap ? Ça ne doit pas
être bien gros.
D'autre part, n'y a-t-il pas aussi en FAT une copie de la FAT
quelque part au milieu de la partition ?
De toute façon, la présence d'un petit "trou" pour la copie de la MFT
au milieu du fichier swap est-elle si gênante que ça ? La
fragmentation devient gênante quand elle augmente de façon
significative le temps de lecture/écriture d'un fichier, c'est-à-dire
quand le temps d'accès perdu à sauter d'un cluster à l'autre entre
deux fragments devient non négligeable devant le temps de
lecture/écriture des clusters du fichier. Or ici on aurait *un* saut
pour 2 Gio !
De plus, comme les clusters sont plus gros (32 ko pour une 2 Go) et
vu qu'il n'y a qu'un seul fichier (pagefile.sys), ils sont donc
contigus, donc DANS CE CAS les transferts sont plus rapides.
NTFS permet aussi de définir des clusters de 32 Kio sur une partition
de 2 Gio, ce n'est pas un argument.
En fait, je retiens plutôt qu'il vaut mieux éviter au maximum les
interactions de la gestion du swap avec la gestion d'un système de
fichiers "trop" élaboré comme NTFS : MFT, journalisation,
indexation... L'idéal serait que le swap utilise directement une
partition brute sans système de fichiers. Une partition de swap comme
sous Linux en somme. ;-)
Pascal Hambourg a exprimé avec précision :La Fred a écrit :
toutes mes partitions NTFS chez moi, sont parfaitement lisibles
depuis mon PC win 98.
Sans outils additionnels (par exemple ntfsdos ou ntfs.sys de
Sysinternals), on ne peut pas accéder à une partition NTFS locale sous
Windows 9x.
Et sous CP/M ? Arrêter d'utiliser des trucs obsolètes !
Pascal Hambourg a exprimé avec précision :
La Fred a écrit :
toutes mes partitions NTFS chez moi, sont parfaitement lisibles
depuis mon PC win 98.
Sans outils additionnels (par exemple ntfsdos ou ntfs.sys de
Sysinternals), on ne peut pas accéder à une partition NTFS locale sous
Windows 9x.
Et sous CP/M ? Arrêter d'utiliser des trucs obsolètes !
Pascal Hambourg a exprimé avec précision :La Fred a écrit :
toutes mes partitions NTFS chez moi, sont parfaitement lisibles
depuis mon PC win 98.
Sans outils additionnels (par exemple ntfsdos ou ntfs.sys de
Sysinternals), on ne peut pas accéder à une partition NTFS locale sous
Windows 9x.
Et sous CP/M ? Arrêter d'utiliser des trucs obsolètes !
Car NTFS possèdant une copie de la MFT en plein milieu (environ) de
la partition, cela provoquerait une fragmentation du fichier de swap.
Par curiosité, quelle peut être la taille de la MFT d'une partition
NTFS de 2 Gio ne contenant que le fichier de swap ? Ça ne doit pas
être bien gros.
Je n'en ai aucune idée, mais même si çà ne faisait qu'un seul octet, donc au
moins 1 cluster (4ko), cela fragmenterait toujours en deux le ficher de
swap, d'où clusters non contigus dans cette zone.
En fait, je retiens plutôt qu'il vaut mieux éviter au maximum les
interactions de la gestion du swap avec la gestion d'un système de
fichiers "trop" élaboré comme NTFS : MFT, journalisation,
indexation... L'idéal serait que le swap utilise directement une
partition brute sans système de fichiers. Une partition de swap comme
sous Linux en somme. ;-)
Entièrement d'accord avec toi !
Et comme le disait Sergio, FAT est justement un système de fichiers
suffisamment rudimentaire pour ne pas créer d'embrouilles avec ce fichier de
swap.
Car NTFS possèdant une copie de la MFT en plein milieu (environ) de
la partition, cela provoquerait une fragmentation du fichier de swap.
Par curiosité, quelle peut être la taille de la MFT d'une partition
NTFS de 2 Gio ne contenant que le fichier de swap ? Ça ne doit pas
être bien gros.
Je n'en ai aucune idée, mais même si çà ne faisait qu'un seul octet, donc au
moins 1 cluster (4ko), cela fragmenterait toujours en deux le ficher de
swap, d'où clusters non contigus dans cette zone.
En fait, je retiens plutôt qu'il vaut mieux éviter au maximum les
interactions de la gestion du swap avec la gestion d'un système de
fichiers "trop" élaboré comme NTFS : MFT, journalisation,
indexation... L'idéal serait que le swap utilise directement une
partition brute sans système de fichiers. Une partition de swap comme
sous Linux en somme. ;-)
Entièrement d'accord avec toi !
Et comme le disait Sergio, FAT est justement un système de fichiers
suffisamment rudimentaire pour ne pas créer d'embrouilles avec ce fichier de
swap.
Car NTFS possèdant une copie de la MFT en plein milieu (environ) de
la partition, cela provoquerait une fragmentation du fichier de swap.
Par curiosité, quelle peut être la taille de la MFT d'une partition
NTFS de 2 Gio ne contenant que le fichier de swap ? Ça ne doit pas
être bien gros.
Je n'en ai aucune idée, mais même si çà ne faisait qu'un seul octet, donc au
moins 1 cluster (4ko), cela fragmenterait toujours en deux le ficher de
swap, d'où clusters non contigus dans cette zone.
En fait, je retiens plutôt qu'il vaut mieux éviter au maximum les
interactions de la gestion du swap avec la gestion d'un système de
fichiers "trop" élaboré comme NTFS : MFT, journalisation,
indexation... L'idéal serait que le swap utilise directement une
partition brute sans système de fichiers. Une partition de swap comme
sous Linux en somme. ;-)
Entièrement d'accord avec toi !
Et comme le disait Sergio, FAT est justement un système de fichiers
suffisamment rudimentaire pour ne pas créer d'embrouilles avec ce fichier de
swap.
Le quidam qui désire crypter, vu qu'il utilise XP PRO, c'est donc un "pro",
sinon XP HOME lui suffirait !
Et la SÉ-CU-RI-TÉ ?
Et la FIA-BI-LI-TÉ ?
Cela compte-t-il pour du beurre ?
Un système de fichier entièrement journalisé, qui s'autorépare dans la
plupart des cas, toi, tu t'en fiches ?
Et la taille de clusters réduite (et constante à 4ko),
Et les flux multiples (méta-données) ?
Et la gestion de fichiers clairsemés de taille énorme (vidéo p.ex.) ?
Et la copie du secteur de boot à la fin de la partition ?
Le quidam qui désire crypter, vu qu'il utilise XP PRO, c'est donc un "pro",
sinon XP HOME lui suffirait !
Et la SÉ-CU-RI-TÉ ?
Et la FIA-BI-LI-TÉ ?
Cela compte-t-il pour du beurre ?
Un système de fichier entièrement journalisé, qui s'autorépare dans la
plupart des cas, toi, tu t'en fiches ?
Et la taille de clusters réduite (et constante à 4ko),
Et les flux multiples (méta-données) ?
Et la gestion de fichiers clairsemés de taille énorme (vidéo p.ex.) ?
Et la copie du secteur de boot à la fin de la partition ?
Le quidam qui désire crypter, vu qu'il utilise XP PRO, c'est donc un "pro",
sinon XP HOME lui suffirait !
Et la SÉ-CU-RI-TÉ ?
Et la FIA-BI-LI-TÉ ?
Cela compte-t-il pour du beurre ?
Un système de fichier entièrement journalisé, qui s'autorépare dans la
plupart des cas, toi, tu t'en fiches ?
Et la taille de clusters réduite (et constante à 4ko),
Et les flux multiples (méta-données) ?
Et la gestion de fichiers clairsemés de taille énorme (vidéo p.ex.) ?
Et la copie du secteur de boot à la fin de la partition ?
Et les flux multiples (méta-données) ?
A part planquer des saletés, je n'ai pas trop vu l'intérêt.
Et les flux multiples (méta-données) ?
A part planquer des saletés, je n'ai pas trop vu l'intérêt.
Et les flux multiples (méta-données) ?
A part planquer des saletés, je n'ai pas trop vu l'intérêt.
L'énorme apport du NTFS (avec donc la journalisation, ce que JCB vient
de rappeler) est la gestion des droits sur les objets en fonction de
l'utilisateur ce qui permet lorsque c'est bien employé une meilleure
sécurisation du système par rapport au FS de type FATxx.
Les autres avantages entre autres :, meilleure gestion des petits
fichiers
(data contenu dans la $MFT), clusters plus petit, taille des fichiers
> 4Gio compression des données, cryptage des données, possibilité de
créer des points de montage, etc ...
L'énorme apport du NTFS (avec donc la journalisation, ce que JCB vient
de rappeler) est la gestion des droits sur les objets en fonction de
l'utilisateur ce qui permet lorsque c'est bien employé une meilleure
sécurisation du système par rapport au FS de type FATxx.
Les autres avantages entre autres :, meilleure gestion des petits
fichiers
(data contenu dans la $MFT), clusters plus petit, taille des fichiers
> 4Gio compression des données, cryptage des données, possibilité de
créer des points de montage, etc ...
L'énorme apport du NTFS (avec donc la journalisation, ce que JCB vient
de rappeler) est la gestion des droits sur les objets en fonction de
l'utilisateur ce qui permet lorsque c'est bien employé une meilleure
sécurisation du système par rapport au FS de type FATxx.
Les autres avantages entre autres :, meilleure gestion des petits
fichiers
(data contenu dans la $MFT), clusters plus petit, taille des fichiers
> 4Gio compression des données, cryptage des données, possibilité de
créer des points de montage, etc ...
