J'essaie de convertir un disque HFS+ en APFS, sans succès,
Que ce soit le disque entier ou l'un des deux volumes qu'il contient.
J'obtiens ceci :
i27:~ jpp$ apfs_hfs_convert -v /dev/disk2
Thu Jan 10 17:44:06 2019: apfs_hfs_convert (748.77.8)
Thu Jan 10 17:44:06 2019: Converting device at /dev/disk2
/dev/rdisk2: Cannot open device: Permission denied
Conversion failed!
/BuildRoot/Library/Caches/com.apple.xbs/Sources/apfs_executables/apfs-748
.77.8/hfs/hfs_convert.c:326 slice=-1 phase=1 location=7 error=13
Un sudo n'y fait rien, "Ignore ownership Š" sur un volume , non plus.
Apple a beau clamer que APFS est sécurisé, il me semble que plus l'espace partagé par les partitions est réduit et mieux Š
Je ne comprends pas bien pourquoi tu parles de partitions à propos de APFS. Dans ce système de fichiers, il n'y a plus de partitions sinon une seule. De Utiliiare de disque/bouton Partitioner : "Les volumes APFS partagent l¹espace de stockage dans un conteneur, occupant une seule partition". La notion d'espace partagé "réduit" n'a pas lieu.
Certes, avec APFS il n'y a plus qu'un « container » et les partitions semblent avoir disparu
Elles n'ont pas disparu, vu qu'il est toujours possible de partitionner un disque de façon classique, et ensuite de créer un container APFS dans une partition.
mais il y a à la place des « volumes » qui ont une taille minimum qui leur est réservée et qui n'est jamais partagée (taille de réserve dans Utilitaire de disque). Au delà de cette taille minimum, le système peut aller piocher dynamiquement dans l'espace commun, du moins ce qu'il en reste. Apple parle de "Volume" mais c'est un terme générique, parce que l'approche est théorique.
On dit "abstraite". Le volume logique est une couche d'abstraction.
Derrière tout volume, il y a un disque, une partition, un NAS
Que vient faire un NAS dans cette histoire ?
ou tout ce que tu voudras qui gère concrètement l'espace physique.
Ce qui gère concrètement l'espace physique ce n'est pas "tout ce qu'on voudra", c'est le pilote APFS.
Tu ne pourras jamais sur un disque de 1 Go créer un container APFS qui contient trois volumes de 400 Mo. > L'avantage d'APFS est que tu pourras par contre créer trois volumes de 200 Mo qui pourront partager l'espace restant de 400 Mo sans qu'il soit nécessaire de repartitionner le disque parce qu'il faudrait agrandir un volume. C'est promis, je ne parlerai plus de partition à l'avenir mais de volume pour respecter les nouvelles règles du marketing ;-)
Le marketing n'a rien à voir dans cette histoire : le terme "Volume" ne date pas d'APFS, et est même utilisé par Apple depuis longtemps. N'as-tu pas remarqué que les points de montage des disques sont dans le répertoire /Volumes/ ? Un "volume" est une "zone de stockage munie d'un système de fichiers", selon la définition wikipedia, qui me semble pertinente. Classiquement un volume est associé à une partition (HFS+, FAT32, NTFS, etc...), mais dans APFS (et d'autres systèmes de fichiers avant lui) ce n'est plus nécessairement le cas. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
Le 13/01/2019 à 10:54, Patrick a écrit :
On 2019-01-13 04:37:59 +0000, JPP said:
In article <5c38c308$0$3554$426a74cc@news.free.fr>,
Patrick <patrick@nowhere.invalid> wrote:
Apple a beau clamer que APFS est sécurisé, il me semble que plus
l'espace partagé par les partitions est réduit et mieux Š
Je ne comprends pas bien pourquoi tu parles de partitions à propos de
APFS.
Dans ce système de fichiers, il n'y a plus de partitions sinon une seule.
De Utiliiare de disque/bouton Partitioner :
"Les volumes APFS partagent l¹espace de stockage dans un conteneur,
occupant une seule partition".
La notion d'espace partagé "réduit" n'a pas lieu.
Certes, avec APFS il n'y a plus qu'un « container » et les partitions
semblent avoir disparu
Elles n'ont pas disparu, vu qu'il est toujours possible de partitionner
un disque de façon classique, et ensuite de créer un container APFS dans
une partition.
mais il y a à la place des « volumes » qui ont
une taille minimum qui leur est réservée et qui n'est jamais partagée
(taille de réserve dans Utilitaire de disque). Au delà de cette taille
minimum, le système peut aller piocher dynamiquement dans l'espace
commun, du moins ce qu'il en reste.
Apple parle de "Volume" mais c'est un terme générique, parce que
l'approche est théorique.
On dit "abstraite". Le volume logique est une couche d'abstraction.
Derrière tout volume, il y a un disque, une
partition, un NAS
Que vient faire un NAS dans cette histoire ?
ou tout ce que tu voudras qui gère concrètement
l'espace physique.
Ce qui gère concrètement l'espace physique ce n'est pas "tout ce qu'on
voudra", c'est le pilote APFS.
Tu ne pourras jamais sur un disque de 1 Go créer un
container APFS qui contient trois volumes de 400 Mo. > L'avantage d'APFS est que tu pourras par contre créer trois volumes de
200 Mo qui pourront partager l'espace restant de 400 Mo sans qu'il soit
nécessaire de repartitionner le disque parce qu'il faudrait agrandir un
volume.
C'est promis, je ne parlerai plus de partition à l'avenir mais de volume
pour respecter les nouvelles règles du marketing ;-)
Le marketing n'a rien à voir dans cette histoire : le terme "Volume" ne
date pas d'APFS, et est même utilisé par Apple depuis longtemps. N'as-tu
pas remarqué que les points de montage des disques sont dans le
répertoire /Volumes/ ?
Un "volume" est une "zone de stockage munie d'un système de fichiers",
selon la définition wikipedia, qui me semble pertinente.
Classiquement un volume est associé à une partition (HFS+, FAT32, NTFS,
etc...), mais dans APFS (et d'autres systèmes de fichiers avant lui) ce
n'est plus nécessairement le cas.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
Apple a beau clamer que APFS est sécurisé, il me semble que plus l'espace partagé par les partitions est réduit et mieux Š
Je ne comprends pas bien pourquoi tu parles de partitions à propos de APFS. Dans ce système de fichiers, il n'y a plus de partitions sinon une seule. De Utiliiare de disque/bouton Partitioner : "Les volumes APFS partagent l¹espace de stockage dans un conteneur, occupant une seule partition". La notion d'espace partagé "réduit" n'a pas lieu.
Certes, avec APFS il n'y a plus qu'un « container » et les partitions semblent avoir disparu
Elles n'ont pas disparu, vu qu'il est toujours possible de partitionner un disque de façon classique, et ensuite de créer un container APFS dans une partition.
mais il y a à la place des « volumes » qui ont une taille minimum qui leur est réservée et qui n'est jamais partagée (taille de réserve dans Utilitaire de disque). Au delà de cette taille minimum, le système peut aller piocher dynamiquement dans l'espace commun, du moins ce qu'il en reste. Apple parle de "Volume" mais c'est un terme générique, parce que l'approche est théorique.
On dit "abstraite". Le volume logique est une couche d'abstraction.
Derrière tout volume, il y a un disque, une partition, un NAS
Que vient faire un NAS dans cette histoire ?
ou tout ce que tu voudras qui gère concrètement l'espace physique.
Ce qui gère concrètement l'espace physique ce n'est pas "tout ce qu'on voudra", c'est le pilote APFS.
Tu ne pourras jamais sur un disque de 1 Go créer un container APFS qui contient trois volumes de 400 Mo. > L'avantage d'APFS est que tu pourras par contre créer trois volumes de 200 Mo qui pourront partager l'espace restant de 400 Mo sans qu'il soit nécessaire de repartitionner le disque parce qu'il faudrait agrandir un volume. C'est promis, je ne parlerai plus de partition à l'avenir mais de volume pour respecter les nouvelles règles du marketing ;-)
Le marketing n'a rien à voir dans cette histoire : le terme "Volume" ne date pas d'APFS, et est même utilisé par Apple depuis longtemps. N'as-tu pas remarqué que les points de montage des disques sont dans le répertoire /Volumes/ ? Un "volume" est une "zone de stockage munie d'un système de fichiers", selon la définition wikipedia, qui me semble pertinente. Classiquement un volume est associé à une partition (HFS+, FAT32, NTFS, etc...), mais dans APFS (et d'autres systèmes de fichiers avant lui) ce n'est plus nécessairement le cas. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
pehache
Le 13/01/2019 à 15:36, JPP a écrit :
In article <5c3b0ae5$0$20326$, Patrick wrote:
Certes, avec APFS il n'y a plus qu'un « container » et les partitions semblent avoir disparu mais il y a à la place des « volumes » qui ont une taille minimum qui leur est réservée et qui n'est jamais partagée (taille de réserve dans Utilitaire de disque).
Ceci n'est qu'une option. Par défaut, il n'y a aucune spécification de taille d'un volume. "La taille de réserve FACULTATIVE permet de garantir un espace de stockage minimum pour ce volume" " la taille de quota FACULTATIVE limite quant à elle l'espace de stockage pouvant être allouée par ce volume". Le "par" est intéressant : on n'alloue pas un espace au volume, c'est lui qui se l'alloue tout seul :-) J'ai vérifié le texte original en anglais, et c'est bien une traduction acceptable de "how much storage this volume can allocate".
Moui, mais ce n'est qu'une façon imagée de parler, un volume n'est une entité qui peut entreprendre des actions. C'est le pilote APFS qui gère tout ça en pratique et qui alloue l'espace.
Conclusion : avec APFS, il nous faut oublier tous nos concepts liés aux systèmes de fichiers ancestraux conçus pour les disques à plateaux et ne plus lier nos fichiers à une quelconque représentation/localisation physique.
C'était en fait déjà vrai avec les SSD, même avec les systèmes de fichiers classiques. En dessous du système de fichier tu as le contrôleur du disque qui opère une indirection d'adresses, pour gérer le wear-leveling (et les cellules mortes). Si le pilote du système de fichiers dit "je veux écrire ça à l'adresse 1000", le contrôleur peut l'écrire à n'importe quelle autre adresse physique (en conservant l'association des deux adresses dans une table). Même sur les HDD ça existe en fait, pour réallouer les secteurs défectueux. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
Le 13/01/2019 à 15:36, JPP a écrit :
In article <5c3b0ae5$0$20326$426a34cc@news.free.fr>,
Patrick <patrick@nowhere.invalid> wrote:
Certes, avec APFS il n'y a plus qu'un « container » et les partitions
semblent avoir disparu mais il y a à la place des « volumes » qui ont
une taille minimum qui leur est réservée et qui n'est jamais partagée
(taille de réserve dans Utilitaire de disque).
Ceci n'est qu'une option.
Par défaut, il n'y a aucune spécification de taille d'un volume.
"La taille de réserve FACULTATIVE permet de garantir un espace de
stockage minimum pour ce volume"
" la taille de quota FACULTATIVE limite quant à elle l'espace de
stockage pouvant être allouée par ce volume".
Le "par" est intéressant : on n'alloue pas un espace au volume, c'est
lui qui se l'alloue tout seul :-)
J'ai vérifié le texte original en anglais, et c'est bien une traduction
acceptable de "how much storage this volume can allocate".
Moui, mais ce n'est qu'une façon imagée de parler, un volume n'est une
entité qui peut entreprendre des actions. C'est le pilote APFS qui gère
tout ça en pratique et qui alloue l'espace.
Conclusion : avec APFS, il nous faut oublier tous nos concepts liés aux
systèmes de fichiers ancestraux conçus pour les disques à plateaux et ne
plus lier nos fichiers à une quelconque représentation/localisation
physique.
C'était en fait déjà vrai avec les SSD, même avec les systèmes de
fichiers classiques. En dessous du système de fichier tu as le
contrôleur du disque qui opère une indirection d'adresses, pour gérer le
wear-leveling (et les cellules mortes). Si le pilote du système de
fichiers dit "je veux écrire ça à l'adresse 1000", le contrôleur peut
l'écrire à n'importe quelle autre adresse physique (en conservant
l'association des deux adresses dans une table). Même sur les HDD ça
existe en fait, pour réallouer les secteurs défectueux.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
Certes, avec APFS il n'y a plus qu'un « container » et les partitions semblent avoir disparu mais il y a à la place des « volumes » qui ont une taille minimum qui leur est réservée et qui n'est jamais partagée (taille de réserve dans Utilitaire de disque).
Ceci n'est qu'une option. Par défaut, il n'y a aucune spécification de taille d'un volume. "La taille de réserve FACULTATIVE permet de garantir un espace de stockage minimum pour ce volume" " la taille de quota FACULTATIVE limite quant à elle l'espace de stockage pouvant être allouée par ce volume". Le "par" est intéressant : on n'alloue pas un espace au volume, c'est lui qui se l'alloue tout seul :-) J'ai vérifié le texte original en anglais, et c'est bien une traduction acceptable de "how much storage this volume can allocate".
Moui, mais ce n'est qu'une façon imagée de parler, un volume n'est une entité qui peut entreprendre des actions. C'est le pilote APFS qui gère tout ça en pratique et qui alloue l'espace.
Conclusion : avec APFS, il nous faut oublier tous nos concepts liés aux systèmes de fichiers ancestraux conçus pour les disques à plateaux et ne plus lier nos fichiers à une quelconque représentation/localisation physique.
C'était en fait déjà vrai avec les SSD, même avec les systèmes de fichiers classiques. En dessous du système de fichier tu as le contrôleur du disque qui opère une indirection d'adresses, pour gérer le wear-leveling (et les cellules mortes). Si le pilote du système de fichiers dit "je veux écrire ça à l'adresse 1000", le contrôleur peut l'écrire à n'importe quelle autre adresse physique (en conservant l'association des deux adresses dans une table). Même sur les HDD ça existe en fait, pour réallouer les secteurs défectueux. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
JPP
In article , pehache wrote: Š
Le "par" est intéressant : on n'alloue pas un espace au volume, c'est lui qui se l'alloue tout seul :-) J'ai vérifié le texte original en anglais, et c'est bien une traduction acceptable de "how much storage this volume can allocate".
Moui, mais ce n'est qu'une façon imagée de parler, un volume n'est une entité qui peut entreprendre des actions. C'est le pilote APFS qui gère tout ça en pratique et qui alloue l'espace.
Je ne sais pas si on peut parler de "pilote", mais bon, c'est pareil. Ce filesystem est très civilisé, plein de courtoisie où chacun demande la permission d'utiliser un bloc ou d'étendre son espace. Derrière tout ça, j'ai répéré unSpace Manager qui s'occupe peut-être de tout cela avec un dénommé Reaper qui s'occupe de faire le ménage des blocs "deleted".
Conclusion : avec APFS, il nous faut oublier tous nos concepts liés aux systèmes de fichiers ancestraux conçus pour les disques à plateaux et ne plus lier nos fichiers à une quelconque représentation/localisation physique.
C'était en fait déjà vrai avec les SSD, même avec les systèmes de fichiers classiques. En dessous du système de fichier tu as le contrôleur du disque qui opère une indirection d'adresses, pour gérer le wear-leveling (et les cellules mortes). Si le pilote du système de fichiers dit "je veux écrire ça à l'adresse 1000", le contrôleur peut l'écrire à n'importe quelle autre adresse physique (en conservant l'association des deux adresses dans une table). Même sur les HDD ça existe en fait, pour réallouer les secteurs défectueux.
Oui, mais je doute quand même qu'un contrôleur tienne à jour une table d'indirection complète.
In article <ga188rFpo9fU1@mid.individual.net>,
pehache <pehache.7@gmail.com> wrote:
Š
>
> Le "par" est intéressant : on n'alloue pas un espace au volume, c'est
> lui qui se l'alloue tout seul :-)
> J'ai vérifié le texte original en anglais, et c'est bien une traduction
> acceptable de "how much storage this volume can allocate".
Moui, mais ce n'est qu'une façon imagée de parler, un volume n'est une
entité qui peut entreprendre des actions. C'est le pilote APFS qui gère
tout ça en pratique et qui alloue l'espace.
Je ne sais pas si on peut parler de "pilote", mais bon, c'est pareil.
Ce filesystem est très civilisé, plein de courtoisie où chacun demande
la permission d'utiliser un bloc ou d'étendre son espace.
Derrière tout ça, j'ai répéré unSpace Manager qui s'occupe peut-être de
tout cela avec un dénommé Reaper qui s'occupe de faire le ménage des
blocs "deleted".
>
> Conclusion : avec APFS, il nous faut oublier tous nos concepts liés aux
> systèmes de fichiers ancestraux conçus pour les disques à plateaux et ne
> plus lier nos fichiers à une quelconque représentation/localisation
> physique.
C'était en fait déjà vrai avec les SSD, même avec les systèmes de
fichiers classiques. En dessous du système de fichier tu as le
contrôleur du disque qui opère une indirection d'adresses, pour gérer le
wear-leveling (et les cellules mortes). Si le pilote du système de
fichiers dit "je veux écrire ça à l'adresse 1000", le contrôleur peut
l'écrire à n'importe quelle autre adresse physique (en conservant
l'association des deux adresses dans une table). Même sur les HDD ça
existe en fait, pour réallouer les secteurs défectueux.
Oui, mais je doute quand même qu'un contrôleur tienne à jour une table
d'indirection complète.
Le "par" est intéressant : on n'alloue pas un espace au volume, c'est lui qui se l'alloue tout seul :-) J'ai vérifié le texte original en anglais, et c'est bien une traduction acceptable de "how much storage this volume can allocate".
Moui, mais ce n'est qu'une façon imagée de parler, un volume n'est une entité qui peut entreprendre des actions. C'est le pilote APFS qui gère tout ça en pratique et qui alloue l'espace.
Je ne sais pas si on peut parler de "pilote", mais bon, c'est pareil. Ce filesystem est très civilisé, plein de courtoisie où chacun demande la permission d'utiliser un bloc ou d'étendre son espace. Derrière tout ça, j'ai répéré unSpace Manager qui s'occupe peut-être de tout cela avec un dénommé Reaper qui s'occupe de faire le ménage des blocs "deleted".
Conclusion : avec APFS, il nous faut oublier tous nos concepts liés aux systèmes de fichiers ancestraux conçus pour les disques à plateaux et ne plus lier nos fichiers à une quelconque représentation/localisation physique.
C'était en fait déjà vrai avec les SSD, même avec les systèmes de fichiers classiques. En dessous du système de fichier tu as le contrôleur du disque qui opère une indirection d'adresses, pour gérer le wear-leveling (et les cellules mortes). Si le pilote du système de fichiers dit "je veux écrire ça à l'adresse 1000", le contrôleur peut l'écrire à n'importe quelle autre adresse physique (en conservant l'association des deux adresses dans une table). Même sur les HDD ça existe en fait, pour réallouer les secteurs défectueux.
Oui, mais je doute quand même qu'un contrôleur tienne à jour une table d'indirection complète.
Patrick
On 2019-01-13 16:32:08 +0000, pehache said:
Le 13/01/2019 à 10:54, Patrick a écrit : Elles n'ont pas disparu [...]
Le 13/01/2019 à 10:54, Patrick a écrit : Elles n'ont pas disparu [...]
Plonk !
pehache
Le 13/01/2019 à 23:18, JPP a écrit :
In article , pehache wrote:
Le "par" est intéressant : on n'alloue pas un espace au volume, c'est lui qui se l'alloue tout seul :-) J'ai vérifié le texte original en anglais, et c'est bien une
traduction
acceptable de "how much storage this volume can allocate".
Moui, mais ce n'est qu'une façon imagée de parler, un volume n'est une entité qui peut entreprendre des actions. C'est le pilote APFS qui gère tout ça en pratique et qui alloue l'espace.
Je ne sais pas si on peut parler de "pilote", mais bon, c'est pareil.
Bah, quoi d'autre ? Les systèmes de fichiers se présentent sous la forme de pilotes en règle générale.
Ce filesystem est très civilisé, plein de courtoisie où chacun demande la permission d'utiliser un bloc ou d'étendre son espace.
C'est une vision très "romantique" :-) Mais en pratique c'est sans doute beaucoup plus classique : une appli veut écrire un nouveau fichier sur tel volume, la requête passe au kernel puis au pilote, le pilote vérifie qu'il y a la place sur le volume, si oui il alloue les blocs pour le fichier au sein du volume, si non il alloue au préalable des blocs pour le volume au sein du container.
Derrière tout ça, j'ai répéré unSpace Manager qui s'occupe peut-être de tout cela avec un dénommé Reaper qui s'occupe de faire le ménage des blocs "deleted".
Conclusion : avec APFS, il nous faut oublier tous nos concepts liés aux systèmes de fichiers ancestraux conçus pour les disques à plateaux et
ne
plus lier nos fichiers à une quelconque représentation/localisation physique.
C'était en fait déjà vrai avec les SSD, même avec les systèmes de fichiers classiques. En dessous du système de fichier tu as le contrôleur du disque qui opère une indirection d'adresses, pour gérer le wear-leveling (et les cellules mortes). Si le pilote du système de fichiers dit "je veux écrire ça à l'adresse 1000", le contrôleur peut l'écrire à n'importe quelle autre adresse physique (en conservant l'association des deux adresses dans une table). Même sur les HDD ça existe en fait, pour réallouer les secteurs défectueux.
Oui, mais je doute quand même qu'un contrôleur tienne à jour une table d'indirection complète.
Complète probablement pas, il faudrait autant de mémoire dans le contrôleur que d'espace disposnible sur le SSD... Mais ça peut être par blocs plus ou moins gros (des blocs de 10ko sur un SSD de 1To, ça demanderait une table de 100 millions d'adresses : c'est beaucoup mais gérable). Sur un HDD la table d'indirections est assez limitée, comme le nombre de blocs réallouables.
Le 13/01/2019 à 23:18, JPP a écrit :
In article <ga188rFpo9fU1@mid.individual.net>,
pehache <pehache.7@gmail.com> wrote:
>
> Le "par" est intéressant : on n'alloue pas un espace au volume, c'est
> lui qui se l'alloue tout seul :-)
> J'ai vérifié le texte original en anglais, et c'est bien une
traduction
> acceptable de "how much storage this volume can allocate".
Moui, mais ce n'est qu'une façon imagée de parler, un volume n'est une
entité qui peut entreprendre des actions. C'est le pilote APFS qui gère
tout ça en pratique et qui alloue l'espace.
Je ne sais pas si on peut parler de "pilote", mais bon, c'est pareil.
Bah, quoi d'autre ? Les systèmes de fichiers se présentent sous la forme
de pilotes en règle générale.
Ce filesystem est très civilisé, plein de courtoisie où chacun demande
la permission d'utiliser un bloc ou d'étendre son espace.
C'est une vision très "romantique" :-)
Mais en pratique c'est sans doute beaucoup plus classique : une appli veut
écrire un nouveau fichier sur tel volume, la requête passe au kernel puis
au pilote, le pilote vérifie qu'il y a la place sur le volume, si oui il
alloue les blocs pour le fichier au sein du volume, si non il alloue au
préalable des blocs pour le volume au sein du container.
Derrière tout ça, j'ai répéré unSpace Manager qui s'occupe peut-être
de
tout cela avec un dénommé Reaper qui s'occupe de faire le ménage des
blocs "deleted".
>
> Conclusion : avec APFS, il nous faut oublier tous nos concepts liés aux
> systèmes de fichiers ancestraux conçus pour les disques à plateaux et
ne
> plus lier nos fichiers à une quelconque représentation/localisation
> physique.
C'était en fait déjà vrai avec les SSD, même avec les systèmes de
fichiers classiques. En dessous du système de fichier tu as le
contrôleur du disque qui opère une indirection d'adresses, pour gérer
le
wear-leveling (et les cellules mortes). Si le pilote du système de
fichiers dit "je veux écrire ça à l'adresse 1000", le contrôleur peut
l'écrire à n'importe quelle autre adresse physique (en conservant
l'association des deux adresses dans une table). Même sur les HDD ça
existe en fait, pour réallouer les secteurs défectueux.
Oui, mais je doute quand même qu'un contrôleur tienne à jour une table
d'indirection complète.
Complète probablement pas, il faudrait autant de mémoire dans le
contrôleur que d'espace disposnible sur le SSD... Mais ça peut être par
blocs plus ou moins gros (des blocs de 10ko sur un SSD de 1To, ça
demanderait une table de 100 millions d'adresses : c'est beaucoup mais
gérable).
Sur un HDD la table d'indirections est assez limitée, comme le nombre de
blocs réallouables.
Le "par" est intéressant : on n'alloue pas un espace au volume, c'est lui qui se l'alloue tout seul :-) J'ai vérifié le texte original en anglais, et c'est bien une
traduction
acceptable de "how much storage this volume can allocate".
Moui, mais ce n'est qu'une façon imagée de parler, un volume n'est une entité qui peut entreprendre des actions. C'est le pilote APFS qui gère tout ça en pratique et qui alloue l'espace.
Je ne sais pas si on peut parler de "pilote", mais bon, c'est pareil.
Bah, quoi d'autre ? Les systèmes de fichiers se présentent sous la forme de pilotes en règle générale.
Ce filesystem est très civilisé, plein de courtoisie où chacun demande la permission d'utiliser un bloc ou d'étendre son espace.
C'est une vision très "romantique" :-) Mais en pratique c'est sans doute beaucoup plus classique : une appli veut écrire un nouveau fichier sur tel volume, la requête passe au kernel puis au pilote, le pilote vérifie qu'il y a la place sur le volume, si oui il alloue les blocs pour le fichier au sein du volume, si non il alloue au préalable des blocs pour le volume au sein du container.
Derrière tout ça, j'ai répéré unSpace Manager qui s'occupe peut-être de tout cela avec un dénommé Reaper qui s'occupe de faire le ménage des blocs "deleted".
Conclusion : avec APFS, il nous faut oublier tous nos concepts liés aux systèmes de fichiers ancestraux conçus pour les disques à plateaux et
ne
plus lier nos fichiers à une quelconque représentation/localisation physique.
C'était en fait déjà vrai avec les SSD, même avec les systèmes de fichiers classiques. En dessous du système de fichier tu as le contrôleur du disque qui opère une indirection d'adresses, pour gérer le wear-leveling (et les cellules mortes). Si le pilote du système de fichiers dit "je veux écrire ça à l'adresse 1000", le contrôleur peut l'écrire à n'importe quelle autre adresse physique (en conservant l'association des deux adresses dans une table). Même sur les HDD ça existe en fait, pour réallouer les secteurs défectueux.
Oui, mais je doute quand même qu'un contrôleur tienne à jour une table d'indirection complète.
Complète probablement pas, il faudrait autant de mémoire dans le contrôleur que d'espace disposnible sur le SSD... Mais ça peut être par blocs plus ou moins gros (des blocs de 10ko sur un SSD de 1To, ça demanderait une table de 100 millions d'adresses : c'est beaucoup mais gérable). Sur un HDD la table d'indirections est assez limitée, comme le nombre de blocs réallouables.
gilbert.olivier
Patrick wrote:
On 2019-01-13 16:32:08 +0000, pehache said:
Le 13/01/2019 à 10:54, Patrick a écrit : Elles n'ont pas disparu [...]
Plonk !
Là tu te décridibilises ;-)) Si tu l'avais réellement plonké plus haut dans l'enfilade tu n'aurais pas lu le message qui te fait le replonker :-) -- Gilbert
Patrick <patrick@nowhere.invalid> wrote:
On 2019-01-13 16:32:08 +0000, pehache said:
> Le 13/01/2019 à 10:54, Patrick a écrit :
>
> Elles n'ont pas disparu [...]
Plonk !
Là tu te décridibilises ;-))
Si tu l'avais réellement plonké plus haut dans l'enfilade tu n'aurais
pas lu le message qui te fait le replonker :-)
Le 13/01/2019 à 10:54, Patrick a écrit : Elles n'ont pas disparu [...]
Plonk !
Là tu te décridibilises ;-)) Si tu l'avais réellement plonké plus haut dans l'enfilade tu n'aurais pas lu le message qui te fait le replonker :-) -- Gilbert
Patrick
On 2019-01-14 09:35:38 +0000, Gilbert OLIVIER said:
Patrick wrote:
On 2019-01-13 16:32:08 +0000, pehache said:
Le 13/01/2019 à 10:54, Patrick a écrit : Elles n'ont pas disparu [...]
Plonk !
Là tu te décridibilises ;-)) Si tu l'avais réellement plonké plus haut dans l'enfilade tu n'aurais pas lu le message qui te fait le replonker :-)
C'est ma boîteàcons qui envoie une réponse automatique ;-)
On 2019-01-14 09:35:38 +0000, Gilbert OLIVIER said:
Patrick <patrick@nowhere.invalid> wrote:
On 2019-01-13 16:32:08 +0000, pehache said:
Le 13/01/2019 à 10:54, Patrick a écrit :
Elles n'ont pas disparu [...]
Plonk !
Là tu te décridibilises ;-))
Si tu l'avais réellement plonké plus haut dans l'enfilade tu n'aurais
pas lu le message qui te fait le replonker :-)
C'est ma boîteàcons qui envoie une réponse automatique ;-)
On 2019-01-14 09:35:38 +0000, Gilbert OLIVIER said:
Patrick wrote:
On 2019-01-13 16:32:08 +0000, pehache said:
Le 13/01/2019 à 10:54, Patrick a écrit : Elles n'ont pas disparu [...]
Plonk !
Là tu te décridibilises ;-)) Si tu l'avais réellement plonké plus haut dans l'enfilade tu n'aurais pas lu le message qui te fait le replonker :-)
C'est ma boîteàcons qui envoie une réponse automatique ;-)
gilbert.olivier
Patrick wrote:
On 2019-01-14 09:35:38 +0000, Gilbert OLIVIER said:
Patrick wrote:
On 2019-01-13 16:32:08 +0000, pehache said:
Le 13/01/2019 à 10:54, Patrick a écrit : Elles n'ont pas disparu [...]
Plonk !
Là tu te décridibilises ;-)) Si tu l'avais réellement plonké plus haut dans l'enfilade tu n'aurais pas lu le message qui te fait le replonker :-)
C'est ma boîteàcons qui envoie une réponse automatique ;-)
Et ma marmotte elle met le papier d'alu.... ;-) -- Gilbert
Patrick <patrick@nowhere.invalid> wrote:
On 2019-01-14 09:35:38 +0000, Gilbert OLIVIER said:
> Patrick <patrick@nowhere.invalid> wrote:
>
>> On 2019-01-13 16:32:08 +0000, pehache said:
>>
>>> Le 13/01/2019 à 10:54, Patrick a écrit :
>>>
>>> Elles n'ont pas disparu [...]
>>
>> Plonk !
>
> Là tu te décridibilises ;-))
>
> Si tu l'avais réellement plonké plus haut dans l'enfilade tu n'aurais
> pas lu le message qui te fait le replonker :-)
C'est ma boîteàcons qui envoie une réponse automatique ;-)
On 2019-01-14 10:29:19 +0000, Gilbert OLIVIER said:
Et ma marmotte elle met le papier d'alu.... ;-)
;-)))
JPP
In article , pehache wrote:
Je ne sais pas si on peut parler de "pilote", mais bon, c'est pareil.
Bah, quoi d'autre ? Les systèmes de fichiers se présentent sous la forme de pilotes en règle générale.
Ce filesystem est très civilisé, plein de courtoisie où chacun demande la permission d'utiliser un bloc ou d'étendre son espace.
C'est une vision très "romantique" :-) Mais en pratique c'est sans doute beaucoup plus classique Š
C'est bien ce que je disais : difficile de quitter une vision type anciens filesystems pour HDD . Si tu lis la doc "developer"Apple ou les articles "forensics" sur APFS, cela semble un peu plus sophistiqué que cela.
In article <d1b3b0190fae8d86f7054ddbaa2848a43e230383@news.nemoweb.net>,
pehache <pehache.7@gmail.com> wrote:
> Je ne sais pas si on peut parler de "pilote", mais bon, c'est pareil.
Bah, quoi d'autre ? Les systèmes de fichiers se présentent sous la forme
de pilotes en règle générale.
> Ce filesystem est très civilisé, plein de courtoisie où chacun demande
> la permission d'utiliser un bloc ou d'étendre son espace.
C'est une vision très "romantique" :-)
Mais en pratique c'est sans doute beaucoup plus classique Š
C'est bien ce que je disais : difficile de quitter une vision type
anciens filesystems pour HDD .
Si tu lis la doc "developer"Apple ou les articles "forensics" sur APFS,
cela semble un peu plus sophistiqué que cela.
Je ne sais pas si on peut parler de "pilote", mais bon, c'est pareil.
Bah, quoi d'autre ? Les systèmes de fichiers se présentent sous la forme de pilotes en règle générale.
Ce filesystem est très civilisé, plein de courtoisie où chacun demande la permission d'utiliser un bloc ou d'étendre son espace.
C'est une vision très "romantique" :-) Mais en pratique c'est sans doute beaucoup plus classique Š
C'est bien ce que je disais : difficile de quitter une vision type anciens filesystems pour HDD . Si tu lis la doc "developer"Apple ou les articles "forensics" sur APFS, cela semble un peu plus sophistiqué que cela.
