bonsoir.
j'ai une ch'tite question à propos du SSD que je ne connais absoulement
pas.
Voila: soit un MacBook acheté en "reconditionné" chez Apple, dans une
config avec SSD. Sachant que le SSD est d'une capacité limitée (je ne
sais plus, 120 ou 160 Go, pas plus) n'a-t-on pas intere^t à n'y laisser
que l'OS et à "expatrier" le dossier USER vers un autre disque
externe ?? (d'autant que ce Mac est destiné à un grand ado, qui va
télécharger, télécharger et télécharger, etc, etc)
Si oui, comment doit-on procéder ? est-ce qu'un simple alias suffit,
comme au bon vieux temps, ou bien faut-il spécifier le chemin
quelquepart ?
D'ailleurs, comment fait Time Machine si on choisit une partition de sauvegarde qui n'est pas HFS+ ?
Ca n'est pas possible.
Patrick -- Patrick Stadelmann
patpro ~ patrick proniewski
In article , Patrick Stadelmann wrote:
In article , Paul Gaborit wrote:
> D'ailleurs, comment fait Time Machine si on choisit une partition de > sauvegarde qui n'est pas HFS+ ?
Ca n'est pas possible.
j'en suis pas si sûr. Quid d'un serveur qui exporte en AFP une partition qui n'est pas en HFS+ ? Tu peux faire du Time Machine sur un serveur distant, et dans ce cas une image disque est créée pour le stockage des données. Theoriquement cette image disque devrait pouvoir être stockée sur de l'UFS, par exemple.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
In article
<Patrick.Stadelmann-5BFD00.12335512052012@news.individual.net>,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
In article <wt9pqa9hi4d.fsf@marceau.mines-albi.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
> D'ailleurs, comment fait Time Machine si on choisit une partition de
> sauvegarde qui n'est pas HFS+ ?
Ca n'est pas possible.
j'en suis pas si sûr. Quid d'un serveur qui exporte en AFP une partition
qui n'est pas en HFS+ ? Tu peux faire du Time Machine sur un serveur
distant, et dans ce cas une image disque est créée pour le stockage des
données. Theoriquement cette image disque devrait pouvoir être stockée
sur de l'UFS, par exemple.
patpro
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
> D'ailleurs, comment fait Time Machine si on choisit une partition de > sauvegarde qui n'est pas HFS+ ?
Ca n'est pas possible.
j'en suis pas si sûr. Quid d'un serveur qui exporte en AFP une partition qui n'est pas en HFS+ ? Tu peux faire du Time Machine sur un serveur distant, et dans ce cas une image disque est créée pour le stockage des données. Theoriquement cette image disque devrait pouvoir être stockée sur de l'UFS, par exemple.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
Erwan David
Paul Gaborit écrivait :
À (at) Sat, 12 May 2012 07:51:51 +0200, Éric Lévénez écrivait (wrote):
Le 12/05/12 02:35, Gilles Aurejac a écrit :
Le troisième problème est qu'on ne peut pas faire de lien dur d'un dossier (pour plusieurs raisons)
Sur Mac OS X on peut et c'est le principe de Time Machine, mais effectivement cela ne marche pas entre partitions différentes.
Il faut sans doute préciser que ce n'est pas vraiment Mac OS X qui permet les liens durs entre dossiers mais plutôt HFS+.
D'ailleurs, comment fait Time Machine si on choisit une partition de sauvegarde qui n'est pas HFS+ ? Est-il moins efficace ou performant ?
Il travaille sur une image disque, formattée en HFS+
Notons que tout FS unix permet les liens hard entre répertoires, ne serait-ce que pour . et .. Par contre il va empêcher/interdire la création par un utilisateur de ces liens. Enfin sauf certains, comme SunOS4 qui le permettait à root.
Notons que c'est une très bonne manière de se tirer dans le pied.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait :
À (at) Sat, 12 May 2012 07:51:51 +0200,
Éric Lévénez <usenet@levenez.com> écrivait (wrote):
Le 12/05/12 02:35, Gilles Aurejac a écrit :
Le troisième problème est qu'on ne peut pas faire de lien dur d'un
dossier (pour plusieurs raisons)
Sur Mac OS X on peut et c'est le principe de Time Machine, mais
effectivement cela ne marche pas entre partitions différentes.
Il faut sans doute préciser que ce n'est pas vraiment Mac OS X qui
permet les liens durs entre dossiers mais plutôt HFS+.
D'ailleurs, comment fait Time Machine si on choisit une partition de
sauvegarde qui n'est pas HFS+ ? Est-il moins efficace ou performant ?
Il travaille sur une image disque, formattée en HFS+
Notons que tout FS unix permet les liens hard entre répertoires, ne
serait-ce que pour . et .. Par contre il va empêcher/interdire la
création par un utilisateur de ces liens. Enfin sauf certains, comme
SunOS4 qui le permettait à root.
Notons que c'est une très bonne manière de se tirer dans le pied.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
À (at) Sat, 12 May 2012 07:51:51 +0200, Éric Lévénez écrivait (wrote):
Le 12/05/12 02:35, Gilles Aurejac a écrit :
Le troisième problème est qu'on ne peut pas faire de lien dur d'un dossier (pour plusieurs raisons)
Sur Mac OS X on peut et c'est le principe de Time Machine, mais effectivement cela ne marche pas entre partitions différentes.
Il faut sans doute préciser que ce n'est pas vraiment Mac OS X qui permet les liens durs entre dossiers mais plutôt HFS+.
D'ailleurs, comment fait Time Machine si on choisit une partition de sauvegarde qui n'est pas HFS+ ? Est-il moins efficace ou performant ?
Il travaille sur une image disque, formattée en HFS+
Notons que tout FS unix permet les liens hard entre répertoires, ne serait-ce que pour . et .. Par contre il va empêcher/interdire la création par un utilisateur de ces liens. Enfin sauf certains, comme SunOS4 qui le permettait à root.
Notons que c'est une très bonne manière de se tirer dans le pied.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Patrick Stadelmann
In article <patpro-DFFD92.12594812052012@[192.168.0.1]>, patpro ~ patrick proniewski wrote:
In article , Patrick Stadelmann wrote:
> In article , > Paul Gaborit wrote: > > > D'ailleurs, comment fait Time Machine si on choisit une partition de > > sauvegarde qui n'est pas HFS+ ? > > Ca n'est pas possible.
j'en suis pas si sûr. Quid d'un serveur qui exporte en AFP une partition qui n'est pas en HFS+ ? Tu peux faire du Time Machine sur un serveur distant, et dans ce cas une image disque est créée pour le stockage des données. Theoriquement cette image disque devrait pouvoir être stockée sur de l'UFS, par exemple.
La sauvegarde est bien stockée en HFS+ dans l'image. La manière dont l'image est stockée ne concerne pas TM.
Patrick -- Patrick Stadelmann
In article <patpro-DFFD92.12594812052012@[192.168.0.1]>,
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
In article
<Patrick.Stadelmann-5BFD00.12335512052012@news.individual.net>,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> In article <wt9pqa9hi4d.fsf@marceau.mines-albi.fr>,
> Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
>
> > D'ailleurs, comment fait Time Machine si on choisit une partition de
> > sauvegarde qui n'est pas HFS+ ?
>
> Ca n'est pas possible.
j'en suis pas si sûr. Quid d'un serveur qui exporte en AFP une partition
qui n'est pas en HFS+ ? Tu peux faire du Time Machine sur un serveur
distant, et dans ce cas une image disque est créée pour le stockage des
données. Theoriquement cette image disque devrait pouvoir être stockée
sur de l'UFS, par exemple.
La sauvegarde est bien stockée en HFS+ dans l'image. La manière dont
l'image est stockée ne concerne pas TM.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <patpro-DFFD92.12594812052012@[192.168.0.1]>, patpro ~ patrick proniewski wrote:
In article , Patrick Stadelmann wrote:
> In article , > Paul Gaborit wrote: > > > D'ailleurs, comment fait Time Machine si on choisit une partition de > > sauvegarde qui n'est pas HFS+ ? > > Ca n'est pas possible.
j'en suis pas si sûr. Quid d'un serveur qui exporte en AFP une partition qui n'est pas en HFS+ ? Tu peux faire du Time Machine sur un serveur distant, et dans ce cas une image disque est créée pour le stockage des données. Theoriquement cette image disque devrait pouvoir être stockée sur de l'UFS, par exemple.
La sauvegarde est bien stockée en HFS+ dans l'image. La manière dont l'image est stockée ne concerne pas TM.
Patrick -- Patrick Stadelmann
Patrick Stadelmann
In article , Erwan David wrote:
Notons que tout FS unix permet les liens hard entre répertoires, ne serait-ce que pour . et ..
J'aurais pensé que . et .. sont des "artifices" interprété par les API d'accès au système de fichiers, et non pas des entrées dans le catalogue (ne serait-ce que pour éviter de devoir les mettre à jour quand un dossier est déplacé).
Patrick -- Patrick Stadelmann
In article <m2ehqpbr4w.fsf@rail.eu.org>,
Erwan David <erwan@rail.eu.org> wrote:
Notons que tout FS unix permet les liens hard entre répertoires, ne
serait-ce que pour . et ..
J'aurais pensé que . et .. sont des "artifices" interprété par les API
d'accès au système de fichiers, et non pas des entrées dans le catalogue
(ne serait-ce que pour éviter de devoir les mettre à jour quand un
dossier est déplacé).
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Notons que tout FS unix permet les liens hard entre répertoires, ne serait-ce que pour . et ..
J'aurais pensé que . et .. sont des "artifices" interprété par les API d'accès au système de fichiers, et non pas des entrées dans le catalogue (ne serait-ce que pour éviter de devoir les mettre à jour quand un dossier est déplacé).
Patrick -- Patrick Stadelmann
patpro ~ patrick proniewski
In article , Patrick Stadelmann wrote:
In article <patpro-DFFD92.12594812052012@[192.168.0.1]>, patpro ~ patrick proniewski wrote:
> In article > , > Patrick Stadelmann wrote: > > > In article , > > Paul Gaborit wrote: > > > > > D'ailleurs, comment fait Time Machine si on choisit une partition de > > > sauvegarde qui n'est pas HFS+ ? > > > > Ca n'est pas possible. > > j'en suis pas si sûr. Quid d'un serveur qui exporte en AFP une partition > qui n'est pas en HFS+ ? Tu peux faire du Time Machine sur un serveur > distant, et dans ce cas une image disque est créée pour le stockage des > données. Theoriquement cette image disque devrait pouvoir être stockée > sur de l'UFS, par exemple.
La sauvegarde est bien stockée en HFS+ dans l'image. La manière dont l'image est stockée ne concerne pas TM.
oui, mais la partition n'est pas en HFS+ ;p
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
In article
<Patrick.Stadelmann-FFFAC8.13324812052012@news.individual.net>,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
In article <patpro-DFFD92.12594812052012@[192.168.0.1]>,
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
> In article
> <Patrick.Stadelmann-5BFD00.12335512052012@news.individual.net>,
> Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
>
> > In article <wt9pqa9hi4d.fsf@marceau.mines-albi.fr>,
> > Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
> >
> > > D'ailleurs, comment fait Time Machine si on choisit une partition de
> > > sauvegarde qui n'est pas HFS+ ?
> >
> > Ca n'est pas possible.
>
> j'en suis pas si sûr. Quid d'un serveur qui exporte en AFP une partition
> qui n'est pas en HFS+ ? Tu peux faire du Time Machine sur un serveur
> distant, et dans ce cas une image disque est créée pour le stockage des
> données. Theoriquement cette image disque devrait pouvoir être stockée
> sur de l'UFS, par exemple.
La sauvegarde est bien stockée en HFS+ dans l'image. La manière dont
l'image est stockée ne concerne pas TM.
oui, mais la partition n'est pas en HFS+ ;p
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
In article <patpro-DFFD92.12594812052012@[192.168.0.1]>, patpro ~ patrick proniewski wrote:
> In article > , > Patrick Stadelmann wrote: > > > In article , > > Paul Gaborit wrote: > > > > > D'ailleurs, comment fait Time Machine si on choisit une partition de > > > sauvegarde qui n'est pas HFS+ ? > > > > Ca n'est pas possible. > > j'en suis pas si sûr. Quid d'un serveur qui exporte en AFP une partition > qui n'est pas en HFS+ ? Tu peux faire du Time Machine sur un serveur > distant, et dans ce cas une image disque est créée pour le stockage des > données. Theoriquement cette image disque devrait pouvoir être stockée > sur de l'UFS, par exemple.
La sauvegarde est bien stockée en HFS+ dans l'image. La manière dont l'image est stockée ne concerne pas TM.
oui, mais la partition n'est pas en HFS+ ;p
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
Patrick Stadelmann
In article <patpro-3660FB.14030512052012@[192.168.0.1]>, patpro ~ patrick proniewski wrote:
oui, mais la partition n'est pas en HFS+ ;p
La partition vue par TM est en HFS+.
Patrick -- Patrick Stadelmann
In article <patpro-3660FB.14030512052012@[192.168.0.1]>,
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
oui, mais la partition n'est pas en HFS+ ;p
La partition vue par TM est en HFS+.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <patpro-3660FB.14030512052012@[192.168.0.1]>, patpro ~ patrick proniewski wrote:
oui, mais la partition n'est pas en HFS+ ;p
La partition vue par TM est en HFS+.
Patrick -- Patrick Stadelmann
Éric Lévénez
Le 12/05/12 13:00, Erwan David a écrit :
Notons que tout FS unix permet les liens hard entre répertoires, ne serait-ce que pour . et .. Par contre il va empêcher/interdire la création par un utilisateur de ces liens. Enfin sauf certains, comme SunOS4 qui le permettait à root.
Oui. À l'origine d'Unix, le mkdir était une fonction C qui faisait les deux liens (appel système link) qui constituent un répertoire. On pouvait, sans contrôle faire des liens en durs entre répertoire. Comme les deux liens étaient fait l'un après l'autre, il pouvait arriver que la création d'un autre lien, entre les deux, fasse tout partir en vrille. Les fsck qui trouvaient des problèmes de liens sur les répertoires étaient nombreux. Tous les unixiens ont connus le "ref count 3 should be 2".
Pour corriger cela, le mkdir est devenu un appel système monolithique et non plus une fonction C. Cela a corriger les problèmes d'accès concurrent. Et pour aller plus loin, les liens en durs ont été interdits (ou fortement limités), même si rien dans la structure des systèmes de fichier ne l'interdit.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 12/05/12 13:00, Erwan David a écrit :
Notons que tout FS unix permet les liens hard entre répertoires, ne
serait-ce que pour . et .. Par contre il va empêcher/interdire la
création par un utilisateur de ces liens. Enfin sauf certains, comme
SunOS4 qui le permettait à root.
Oui. À l'origine d'Unix, le mkdir était une fonction C qui faisait les
deux liens (appel système link) qui constituent un répertoire. On
pouvait, sans contrôle faire des liens en durs entre répertoire. Comme
les deux liens étaient fait l'un après l'autre, il pouvait arriver que
la création d'un autre lien, entre les deux, fasse tout partir en
vrille. Les fsck qui trouvaient des problèmes de liens sur les
répertoires étaient nombreux. Tous les unixiens ont connus le "ref count
3 should be 2".
Pour corriger cela, le mkdir est devenu un appel système monolithique et
non plus une fonction C. Cela a corriger les problèmes d'accès
concurrent. Et pour aller plus loin, les liens en durs ont été interdits
(ou fortement limités), même si rien dans la structure des systèmes de
fichier ne l'interdit.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Notons que tout FS unix permet les liens hard entre répertoires, ne serait-ce que pour . et .. Par contre il va empêcher/interdire la création par un utilisateur de ces liens. Enfin sauf certains, comme SunOS4 qui le permettait à root.
Oui. À l'origine d'Unix, le mkdir était une fonction C qui faisait les deux liens (appel système link) qui constituent un répertoire. On pouvait, sans contrôle faire des liens en durs entre répertoire. Comme les deux liens étaient fait l'un après l'autre, il pouvait arriver que la création d'un autre lien, entre les deux, fasse tout partir en vrille. Les fsck qui trouvaient des problèmes de liens sur les répertoires étaient nombreux. Tous les unixiens ont connus le "ref count 3 should be 2".
Pour corriger cela, le mkdir est devenu un appel système monolithique et non plus une fonction C. Cela a corriger les problèmes d'accès concurrent. Et pour aller plus loin, les liens en durs ont été interdits (ou fortement limités), même si rien dans la structure des systèmes de fichier ne l'interdit.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Paul Gaborit
À (at) Sat, 12 May 2012 13:00:47 +0200, Erwan David écrivait (wrote):
Paul Gaborit écrivait :
D'ailleurs, comment fait Time Machine si on choisit une partition de sauvegarde qui n'est pas HFS+ ? Est-il moins efficace ou performant ?
Il travaille sur une image disque, formattée en HFS+
Simple, élégant... et ça ne doit pas être très pénalisant en terme de performance.
Notons que tout FS unix permet les liens hard entre répertoires, ne serait-ce que pour . et .. Par contre il va empêcher/interdire la création par un utilisateur de ces liens. Enfin sauf certains, comme SunOS4 qui le permettait à root.
. et .. sont toujours gérés de manière particulière. En revanche, même si la création de autres liens durs entre répertoires est effectivement possible dans certaines conditions, sur la plupart des FS, ils sont gérés sans aucune précaution : par exemple, si on détache un cycle, au mieux, l'espace disque occupé est perdu jusqu'au prochain reformatage et, au pire, sa simple présence peut faire planter les outils de gestion du FS.
Notons que c'est une très bonne manière de se tirer dans le pied.
On peut le dire comme ça. ;-)
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Sat, 12 May 2012 13:00:47 +0200,
Erwan David <erwan@rail.eu.org> écrivait (wrote):
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait :
D'ailleurs, comment fait Time Machine si on choisit une partition de
sauvegarde qui n'est pas HFS+ ? Est-il moins efficace ou performant ?
Il travaille sur une image disque, formattée en HFS+
Simple, élégant... et ça ne doit pas être très pénalisant en terme de
performance.
Notons que tout FS unix permet les liens hard entre répertoires, ne
serait-ce que pour . et .. Par contre il va empêcher/interdire la
création par un utilisateur de ces liens. Enfin sauf certains, comme
SunOS4 qui le permettait à root.
. et .. sont toujours gérés de manière particulière. En revanche, même
si la création de autres liens durs entre répertoires est effectivement
possible dans certaines conditions, sur la plupart des FS, ils sont
gérés sans aucune précaution : par exemple, si on détache un cycle, au
mieux, l'espace disque occupé est perdu jusqu'au prochain reformatage
et, au pire, sa simple présence peut faire planter les outils de gestion
du FS.
Notons que c'est une très bonne manière de se tirer dans le pied.
On peut le dire comme ça. ;-)
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Sat, 12 May 2012 13:00:47 +0200, Erwan David écrivait (wrote):
Paul Gaborit écrivait :
D'ailleurs, comment fait Time Machine si on choisit une partition de sauvegarde qui n'est pas HFS+ ? Est-il moins efficace ou performant ?
Il travaille sur une image disque, formattée en HFS+
Simple, élégant... et ça ne doit pas être très pénalisant en terme de performance.
Notons que tout FS unix permet les liens hard entre répertoires, ne serait-ce que pour . et .. Par contre il va empêcher/interdire la création par un utilisateur de ces liens. Enfin sauf certains, comme SunOS4 qui le permettait à root.
. et .. sont toujours gérés de manière particulière. En revanche, même si la création de autres liens durs entre répertoires est effectivement possible dans certaines conditions, sur la plupart des FS, ils sont gérés sans aucune précaution : par exemple, si on détache un cycle, au mieux, l'espace disque occupé est perdu jusqu'au prochain reformatage et, au pire, sa simple présence peut faire planter les outils de gestion du FS.
Notons que c'est une très bonne manière de se tirer dans le pied.
On peut le dire comme ça. ;-)
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
