[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [obsdfr-misc] Choisir parmi les *BSD
Ludovic Gele(ludovic POINT gele AT raysa.org)@2007.02.23 10:39:40 +0100 wrote:
> Selon Gil Andre <andre POINT g AT wanadoo.fr>:
>
> >
> > Re-Bonsoir,
> >
> > On Thu, 22 Feb 2007 22:49:00 +0100 "Mattieu Baptiste" <mattieu POINT b AT gmail.com>
> > wrote:
> >
> > > On 2/22/07, Gil Andre <andre POINT g AT wanadoo.fr> wrote:
> > > > Donc, pour en revenir à notre sujet de prédilection (OpenBSD) :
> > > > oui, cette limite peut-être rapidement atteinte. Et c'est une
> > > > limite très embêtante quand on gère des applications
> > > > professionnelles...
> > >
> > > Mais qui est dans l'obligation d'utiliser un volume *unique* si gros ?
> > > Dans la majorité des cas on peut répartir les données intelligemment
> > > sur plusieurs volumes de 1To ou moins.
> > > Sans parler que si la machine plante, je n'imagine même pas la RAM
> > > nécessaire pour faire un fsck sur 1To...
> >
> > Oui, on peut répartir les données sur plusieurs volumes.
> > Sauf dans le cas d'une base de données de 750 Go et des
> > poussières... Je ne plaisante pas, c'est (relativement)
> > fréquent dans ma boîte.
>
> J'avoue que je risque d'avoir cette problématique, étant donné que l'appli que
> je dévelope va faire appel à un serveur postgres et va stocker des BLOB (photo
> dans un premier temps et video par la suite) l'espace disque risque de se faire
> manger rapidement.
>
> J'ai fait alors quelques recherche sur ce qui vient d'être dit, il semble qu'il
> y ait un package e2fsprogs-1.27p4.tgz pour OpenBSD 4.0. Apparemment, il
> permettrait à OpenBSD de bosser sur de l'ext2 et de l'ext3, la journalisation
> limitant les apparemment les fsck. Mais j'ai aussi vu qu'il existait un port
> pour Java, malgrès les soucis de licence.
>
> Ne serait-il pas dès lors possible de faire un package (ou plutot un port, au
> même titre que la jvm de Sun, pour les même problèmes de licence) avec par
> exemple ZFS de chez Sun aussi, qui à des possibilités très évoluées qui lui
> permettrait presque (j'ai bien dit presque) de rivaliser avec le GEOM de
> FreeBSD? Les partitons systèmes pourrait toujours être en FFS, qui dois plutot
> bien fonctionner, sinon les développeurs d'OpenBSD ne l'utiliseraient pas, mais
> avec un support ZFS OpenBSD pourrait vraiment stocker de gros volume de données,
> et ce de manière apparemment très souple.
>
> PS: Je ne veux pas lancer de troll, ni de disputes, juste voir un peu les
> solutions qui s'offrent sous OpenBSD. En outre, si ZFS est une solution, je veux
> bien contribuer au portage, mais je risque de polluer la liste de questions de
> dev, mon niveau en C étant ridicule. N'hésitez pas à me rediriger vers une liste
> plus adéquat.
>
> Encore merci de répondre à mes interrogations :D
Je ne répond pas à tes questions, mais a mon avis, il serait plus
simple de faire un port de UFS2 (depuis Net/FreeBSD qui l'utilisent)
vers OpenBSD: il n'y a plus la limite du To (index de blocs sur 64 bits)
et les soft-updates remplacent la journalisation (pour ceux qui ne sont
pas au courant, soft-updates vs. journalisation est un vieux troll en
matière de systèmes de fichiers).
Bien sur, il n'y a pas les possibilités plus évoluées dont dispose
ZFS, mais a mon avis celles-ci doivent plutôt être une couche
séparée et non intégrées dans le FS. Bien sur, si tu prévois de
stocker des fichiers de l'ordre de l'exaoctet, c'est une autre histoire!
;-)
N.