Essentiellement le passage de certains compteurs de 32 à 64 bits.
Jacques. Hum moi et l'anglais, donc pour un i386 essenciellement sous une
architecture 32bits cette option n'est pas necessaire? merci.
pornin
According to TheFelin :
Hum moi et l'anglais, donc pour un i386 essenciellement sous une architecture 32bits cette option n'est pas necessaire?
Non, c'est une histoire de format des données sur le disque, c'est indépendant de l'architecture ; un i386 peut manipuler des nombres de 64 bits, c'est juste qu'il est un peu moins efficace pour ça que pour les nombres de 32 bits.
UFS2 permet de gérer des filesystems plus gros (plus de 1 tera-octets, c'est-à-dire 1024 Go) et ça a un meilleur support des "extended attributes" qui servent à faire des choses un peu avancées, comme les ACL (des listes de droits d'accès aux fichiers plus fines que les droits Unix de base). Pour un système existant, la conversion a peu d'intérêt.
--Thomas Pornin
According to TheFelin <thefelin@neurozone.ath.cx>:
Hum moi et l'anglais, donc pour un i386 essenciellement sous une
architecture 32bits cette option n'est pas necessaire?
Non, c'est une histoire de format des données sur le disque, c'est
indépendant de l'architecture ; un i386 peut manipuler des nombres de 64
bits, c'est juste qu'il est un peu moins efficace pour ça que pour les
nombres de 32 bits.
UFS2 permet de gérer des filesystems plus gros (plus de 1 tera-octets,
c'est-à-dire 1024 Go) et ça a un meilleur support des "extended
attributes" qui servent à faire des choses un peu avancées, comme les
ACL (des listes de droits d'accès aux fichiers plus fines que les droits
Unix de base). Pour un système existant, la conversion a peu d'intérêt.
Hum moi et l'anglais, donc pour un i386 essenciellement sous une architecture 32bits cette option n'est pas necessaire?
Non, c'est une histoire de format des données sur le disque, c'est indépendant de l'architecture ; un i386 peut manipuler des nombres de 64 bits, c'est juste qu'il est un peu moins efficace pour ça que pour les nombres de 32 bits.
UFS2 permet de gérer des filesystems plus gros (plus de 1 tera-octets, c'est-à-dire 1024 Go) et ça a un meilleur support des "extended attributes" qui servent à faire des choses un peu avancées, comme les ACL (des listes de droits d'accès aux fichiers plus fines que les droits Unix de base). Pour un système existant, la conversion a peu d'intérêt.
--Thomas Pornin
Jacques Caron
On Mon, 04 Oct 2004 16:56:34 +0200, TheFelin wrote:
Hum moi et l'anglais, donc pour un i386 essenciellement sous une architecture 32bits cette option n'est pas necessaire?
Rien à voir. Il s'agit de passer les compteurs genre taille du fichier, position du fichier dans la partition, etc. de 32 à 64 bits dans leur format sur disque (l'OS est capable de les gérer même sur une plate-forme 32 bits). Ca permet d'avoir des fichiers plus grands, des partitions plus grandes, etc. Comme ils disent: ça permet de passer la limite des 1 téra-octets...
Il y a aussi quelques autres avantages comme un newfs plus rapide, et plein de possibilités d'extensions mais elles ne sont à ma connaissance pas encore utilisées.
Mais en gros, à part quelques cas particuliers (très gros volumes constitués de plusieurs disques, par exemple), ça n'a rien d'indispensable. Si tu fais un newfs d'une nouvelle partition, autant la faire en UFS2 (sauf si elle doit pouvoir être lue par un OS qui ne gère pas UFS2), mais les partitions actuelles tu peux les laisser en l'état.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
On Mon, 04 Oct 2004 16:56:34 +0200, TheFelin <thefelin@neurozone.ath.cx>
wrote:
Hum moi et l'anglais, donc pour un i386 essenciellement sous une
architecture 32bits cette option n'est pas necessaire?
Rien à voir. Il s'agit de passer les compteurs genre taille du fichier,
position du fichier dans la partition, etc. de 32 à 64 bits dans leur
format sur disque (l'OS est capable de les gérer même sur une plate-forme
32 bits). Ca permet d'avoir des fichiers plus grands, des partitions plus
grandes, etc. Comme ils disent: ça permet de passer la limite des 1
téra-octets...
Il y a aussi quelques autres avantages comme un newfs plus rapide, et
plein de possibilités d'extensions mais elles ne sont à ma connaissance
pas encore utilisées.
Mais en gros, à part quelques cas particuliers (très gros volumes
constitués de plusieurs disques, par exemple), ça n'a rien
d'indispensable. Si tu fais un newfs d'une nouvelle partition, autant la
faire en UFS2 (sauf si elle doit pouvoir être lue par un OS qui ne gère
pas UFS2), mais les partitions actuelles tu peux les laisser en l'état.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Mon, 04 Oct 2004 16:56:34 +0200, TheFelin wrote:
Hum moi et l'anglais, donc pour un i386 essenciellement sous une architecture 32bits cette option n'est pas necessaire?
Rien à voir. Il s'agit de passer les compteurs genre taille du fichier, position du fichier dans la partition, etc. de 32 à 64 bits dans leur format sur disque (l'OS est capable de les gérer même sur une plate-forme 32 bits). Ca permet d'avoir des fichiers plus grands, des partitions plus grandes, etc. Comme ils disent: ça permet de passer la limite des 1 téra-octets...
Il y a aussi quelques autres avantages comme un newfs plus rapide, et plein de possibilités d'extensions mais elles ne sont à ma connaissance pas encore utilisées.
Mais en gros, à part quelques cas particuliers (très gros volumes constitués de plusieurs disques, par exemple), ça n'a rien d'indispensable. Si tu fais un newfs d'une nouvelle partition, autant la faire en UFS2 (sauf si elle doit pouvoir être lue par un OS qui ne gère pas UFS2), mais les partitions actuelles tu peux les laisser en l'état.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
TheFelin
On Mon, 04 Oct 2004 16:56:34 +0200, TheFelin wrote:
Hum moi et l'anglais, donc pour un i386 essenciellement sous une architecture 32bits cette option n'est pas necessaire?
Rien à voir. Il s'agit de passer les compteurs genre taille du fichier, position du fichier dans la partition, etc. de 32 à 64 bits dans leur format sur disque (l'OS est capable de les gérer même sur une plate-forme 32 bits). Ca permet d'avoir des fichiers plus grands, des partitions plus grandes, etc. Comme ils disent: ça permet de passer la limite des 1 téra-octets...
Il y a aussi quelques autres avantages comme un newfs plus rapide, et plein de possibilités d'extensions mais elles ne sont à ma connaissance pas encore utilisées.
Mais en gros, à part quelques cas particuliers (très gros volumes constitués de plusieurs disques, par exemple), ça n'a rien d'indispensable. Si tu fais un newfs d'une nouvelle partition, autant la faire en UFS2 (sauf si elle doit pouvoir être lue par un OS qui ne gère pas UFS2), mais les partitions actuelles tu peux les laisser en l'état.
Jacques. merci pour ces infos, et puis dépasser 1 téra-octets sur un fichier je
sais pas comment je vais faire ;-)
On Mon, 04 Oct 2004 16:56:34 +0200, TheFelin
<thefelin@neurozone.ath.cx> wrote:
Hum moi et l'anglais, donc pour un i386 essenciellement sous une
architecture 32bits cette option n'est pas necessaire?
Rien à voir. Il s'agit de passer les compteurs genre taille du fichier,
position du fichier dans la partition, etc. de 32 à 64 bits dans leur
format sur disque (l'OS est capable de les gérer même sur une
plate-forme 32 bits). Ca permet d'avoir des fichiers plus grands, des
partitions plus grandes, etc. Comme ils disent: ça permet de passer la
limite des 1 téra-octets...
Il y a aussi quelques autres avantages comme un newfs plus rapide, et
plein de possibilités d'extensions mais elles ne sont à ma connaissance
pas encore utilisées.
Mais en gros, à part quelques cas particuliers (très gros volumes
constitués de plusieurs disques, par exemple), ça n'a rien
d'indispensable. Si tu fais un newfs d'une nouvelle partition, autant
la faire en UFS2 (sauf si elle doit pouvoir être lue par un OS qui ne
gère pas UFS2), mais les partitions actuelles tu peux les laisser en
l'état.
Jacques.
merci pour ces infos, et puis dépasser 1 téra-octets sur un fichier je
On Mon, 04 Oct 2004 16:56:34 +0200, TheFelin wrote:
Hum moi et l'anglais, donc pour un i386 essenciellement sous une architecture 32bits cette option n'est pas necessaire?
Rien à voir. Il s'agit de passer les compteurs genre taille du fichier, position du fichier dans la partition, etc. de 32 à 64 bits dans leur format sur disque (l'OS est capable de les gérer même sur une plate-forme 32 bits). Ca permet d'avoir des fichiers plus grands, des partitions plus grandes, etc. Comme ils disent: ça permet de passer la limite des 1 téra-octets...
Il y a aussi quelques autres avantages comme un newfs plus rapide, et plein de possibilités d'extensions mais elles ne sont à ma connaissance pas encore utilisées.
Mais en gros, à part quelques cas particuliers (très gros volumes constitués de plusieurs disques, par exemple), ça n'a rien d'indispensable. Si tu fais un newfs d'une nouvelle partition, autant la faire en UFS2 (sauf si elle doit pouvoir être lue par un OS qui ne gère pas UFS2), mais les partitions actuelles tu peux les laisser en l'état.
Jacques. merci pour ces infos, et puis dépasser 1 téra-octets sur un fichier je
sais pas comment je vais faire ;-)
Jacques Caron
Salut,
On Mon, 4 Oct 2004 20:31:08 +0200, Xavier wrote:
Les snapshiots, ça n'a rien à voir ? C'est juste une extension de dump ?
J'étais pourtant persudé avoir lui que c'était UFS2 qui permettait les snapshots.
C'est plutôt lié aux soft updates, il me semble bien.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Mon, 4 Oct 2004 20:31:08 +0200, Xavier <xavier@groumpf.org> wrote:
Les snapshiots, ça n'a rien à voir ? C'est juste une extension de dump ?
J'étais pourtant persudé avoir lui que c'était UFS2 qui permettait les
snapshots.
C'est plutôt lié aux soft updates, il me semble bien.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
Les snapshiots, ça n'a rien à voir ? C'est juste une extension de dump ?
J'étais pourtant persudé avoir lui que c'était UFS2 qui permettait les snapshots.
C'est plutôt lié aux soft updates, il me semble bien.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
pornin
According to Jacques Caron :
C'est plutôt lié aux soft updates, il me semble bien.
Oui, c'est juste que ça a été rajouté dans FreeBSD 5 à peu près en même temps. C'est comme l'effacement immédiat : sous FreeBSD 5, contrairement à FreeBSD 4, quand les softupdates sont activées et qu'on efface un fichier, la place est libérée immédiatement, que le filesystem soit en UFS1 ou UFS2.
On recommande néanmoins UFS2 par défaut, malgré la taille d'inode supérieure (256 octets au lieu de 128), parce que ça supportera mieux les ACL quand on commencera à s'en servir sérieusement.
--Thomas Pornin
According to Jacques Caron <jc@imfeurope.com>:
C'est plutôt lié aux soft updates, il me semble bien.
Oui, c'est juste que ça a été rajouté dans FreeBSD 5 à peu près en même
temps. C'est comme l'effacement immédiat : sous FreeBSD 5, contrairement
à FreeBSD 4, quand les softupdates sont activées et qu'on efface un
fichier, la place est libérée immédiatement, que le filesystem soit en
UFS1 ou UFS2.
On recommande néanmoins UFS2 par défaut, malgré la taille d'inode
supérieure (256 octets au lieu de 128), parce que ça supportera mieux
les ACL quand on commencera à s'en servir sérieusement.
C'est plutôt lié aux soft updates, il me semble bien.
Oui, c'est juste que ça a été rajouté dans FreeBSD 5 à peu près en même temps. C'est comme l'effacement immédiat : sous FreeBSD 5, contrairement à FreeBSD 4, quand les softupdates sont activées et qu'on efface un fichier, la place est libérée immédiatement, que le filesystem soit en UFS1 ou UFS2.
On recommande néanmoins UFS2 par défaut, malgré la taille d'inode supérieure (256 octets au lieu de 128), parce que ça supportera mieux les ACL quand on commencera à s'en servir sérieusement.
--Thomas Pornin
Patrick Lamaizière
Thomas Pornin écrivait :
On recommande néanmoins UFS2 par défaut, malgré la taille d'inode supérieure (256 octets au lieu de 128), parce que ça supportera mieux les ACL quand on commencera à s'en servir sérieusement.
D'accord, ça c'est pour FreeBSD, mais pour NetBSD ? Ils sont passés à l'UFS2 sur la version 2. Est-ce qu'il y des prévisions sur le support des snapshots et des ACL (peut-être que ça existe déjà pour les ACL) ?
Thomas Pornin écrivait :
On recommande néanmoins UFS2 par défaut, malgré la taille d'inode
supérieure (256 octets au lieu de 128), parce que ça supportera mieux
les ACL quand on commencera à s'en servir sérieusement.
D'accord, ça c'est pour FreeBSD, mais pour NetBSD ? Ils sont passés à
l'UFS2 sur la version 2. Est-ce qu'il y des prévisions sur le support des
snapshots et des ACL (peut-être que ça existe déjà pour les ACL) ?
On recommande néanmoins UFS2 par défaut, malgré la taille d'inode supérieure (256 octets au lieu de 128), parce que ça supportera mieux les ACL quand on commencera à s'en servir sérieusement.
D'accord, ça c'est pour FreeBSD, mais pour NetBSD ? Ils sont passés à l'UFS2 sur la version 2. Est-ce qu'il y des prévisions sur le support des snapshots et des ACL (peut-être que ça existe déjà pour les ACL) ?
xavier
Patrick Lamaizière wrote:
D'accord, ça c'est pour FreeBSD, mais pour NetBSD ? Ils sont passés à l'UFS2 sur la version 2.
Mhu ?????
Pad aux dernières nouvelles ... Il n'y a que le support, mais le code
cf Revision 1.28 Wed Apr 2 10:39:36 2003 UTC by fvdl
-- Xavier HUMBERT INJEP - NetBSD, parce que je le vaux bien
Miod Vallat
On recommande néanmoins UFS2 par défaut, malgré la taille d'inode supérieure (256 octets au lieu de 128), parce que ça supportera mieux les ACL quand on commencera à s'en servir sérieusement.
D'accord, ça c'est pour FreeBSD, mais pour NetBSD ? Ils sont passés à l'UFS2 sur la version 2. Est-ce qu'il y des prévisions sur le support des snapshots et des ACL (peut-être que ça existe déjà pour les ACL) ?
Pour les ACL, je ne sais pas, mais pour les snapshots, ils ont leur propre implémentation, fss(4), cf fssconfig(8) pour plus de détails.
On recommande néanmoins UFS2 par défaut, malgré la taille d'inode
supérieure (256 octets au lieu de 128), parce que ça supportera mieux
les ACL quand on commencera à s'en servir sérieusement.
D'accord, ça c'est pour FreeBSD, mais pour NetBSD ? Ils sont passés à
l'UFS2 sur la version 2. Est-ce qu'il y des prévisions sur le support des
snapshots et des ACL (peut-être que ça existe déjà pour les ACL) ?
Pour les ACL, je ne sais pas, mais pour les snapshots, ils ont leur
propre implémentation, fss(4), cf fssconfig(8) pour plus de détails.
On recommande néanmoins UFS2 par défaut, malgré la taille d'inode supérieure (256 octets au lieu de 128), parce que ça supportera mieux les ACL quand on commencera à s'en servir sérieusement.
D'accord, ça c'est pour FreeBSD, mais pour NetBSD ? Ils sont passés à l'UFS2 sur la version 2. Est-ce qu'il y des prévisions sur le support des snapshots et des ACL (peut-être que ça existe déjà pour les ACL) ?
Pour les ACL, je ne sais pas, mais pour les snapshots, ils ont leur propre implémentation, fss(4), cf fssconfig(8) pour plus de détails.
