Gestion de très gros FS

Le
Pierre Malard
--Apple-Mail=_FEC0AADF-056B-45E3-93A8-019DE8DC76B7
Content-Type: multipart/alternative;
boundary="Apple-Mail=_E8386464-6ECE-440E-846B-F4DACDCD4D16"


--Apple-Mail=_E8386464-6ECE-440E-846B-F4DACDCD4D16
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8

Bonjour,

J’ai repris un lourd dossier de l’administration de =
serveurs géographiques pour notre UMR. Ce projet n’a pas de =
buts lucratifs et est principalement ouvert à la recherche et aux =
collectivités.
Le système repose sur un SAN Dell de 250 To pour l’instant =
(PowerVault MD3860f) raccordé à une lame Dell (PowerEdge R620) =
pour offrir un service NAS (NFS, FTP, SMB, …). Le serveur tourne =
sur Debian Wheezy et la gestion NAS est couverte par « =
openMediaVault ». Les systèmes de fichiers sont situés =
sur des volumes logiques (LVM) et formatés en Ext4 dont la limité=
de volume affichée en taille est de 1 Eio (1024 Tio) =
(https://fr.wikipedia.org/wiki/Ext4).
Nous avons des volumes de 50 To et j’ai eu besoin d’agrand=
ir l’un de ceux-ci. Malheur à moi car autant il semble que =
les commandes de création de volume physique (pv…), de =
volumes logiques (lv…) et de création de système de =
fichiers fonctionne, autant la commande d’agrandissement du =
système de fichiers (« resize2fs ») ne fonctionne pas et =
me sort un « resize2fs: New size too large to be expressed in 32 =
bits » très désagréable.

En cherchant, en suivant le post =
(http://permalink.gmane.org/gmane.comp.file-systems.ext4/19565), j’=
ai pu constater que mon fichier « /etc/mke2fs.conf » contenait =
bien la référence « auto_64-bit_support = 1 » qui =
semble limiter les commandes « e2fsprogs ». Mais selon le blog =
de Ronny Egners « =
http://blog.ronnyegner-consulting.de/2011/08/18/ext4-and-the-16-tb-limit-n=
ow-solved/« il est clairement écrit que l’agrandissemen=
t au delà des fatidiques 16 To est impossible.

Tous ces échanges datant de 2013 et aucune modification n’aya=
nt été apportée depuis sur nos distributions j’en =
déduis que le problème est peut être inhérent au =
système et difficilement solvable. Ayant besoin de cet espace, de =
beaucoup plus d’espace à l’avenir (on pense au Po), =
je me dis qu’il faudrait peut-être changer notre fusil =
d’épaule et rechercher des solutions de systèmes de =
fichiers autres; ou même de méta-systèmes de fichiers =
regroupant plusieurs FS.

J’ai lu que BtrFS semblait se présenter comme le « =
successeur » de ext4 et proposait un redimensionnement à chaud =
en complément du gestionnaire de volumes logiques de Linux. Il =
permettrait également l’agrégat de préiférique=
s et la gestion de « snapshots » =
(https://fr.wikipedia.org/wiki/Btrfs). Avez-vous une expérience =
dans ce domaine et est-ce que cela répondrait à notre besoin =
de gros volumes extensibles ?

J’ai également lu un truc sur le stockage distribué =
avec le projet « GlusterFS » =
(https://www.synergeek.fr/glusterfs-3-1-stockage-distribue-redondant-pour-=
linux =
<https://www.synergeek.fr/glusterfs-3-1-stockage-distribue-redondant-pour-=
linux>, =
http://www.supinfo.com/articles/single/171-mise-place-stockage-partage-ave=
c-glusterfs =
<http://www.supinfo.com/articles/single/171-mise-place-stockage-partage-av=
ec-glusterfs>, https://fr.wikipedia.org/wiki/GlusterFS =
<https://fr.wikipedia.org/wiki/GlusterFS>) qui pourrait nous permettre =
de distribuer notre stockage. Idem, avez-vous de l’expérience=
dans ce domaine ?

Merci d'avance

--
Pierre Malard

« L'émancipation politique doit marcher de pair avec =
l'émancipation
sociale ou les résultats sont désastreux »
Romain Gary - "Les racines du ciel"
| _,,,,,_
/,`.-'`' -. ;-;;,_
|,4- ) )-,_. , ( `'-'
'''(_/--' `-'_) πr

perl -e '$_=q#: 3| 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) =
)-,_. , ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'_): =
24πr::#;y#:##;s#(D)(d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--


--Apple-Mail=_E8386464-6ECE-440E-846B-F4DACDCD4D16
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8

<html><head><meta http-equiv="Content-Type" content="text/html =
charset=utf-8"></head><body style="word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class="">Bonjour,<div class=""><br class=""></div><div =
class="">J’ai repris un lourd dossier de l’administratio=
n de serveurs géographiques pour notre UMR. Ce projet n’a =
pas de buts lucratifs et est principalement ouvert à la recherche =
et aux collectivités.</div><div class="">Le système repose =
sur un SAN Dell de 250 To pour l’instant (PowerVault MD3860f) =
raccordé à une lame Dell (PowerEdge R620) pour offrir un =
service NAS (NFS, FTP, SMB, …). Le serveur tourne sur Debian =
Wheezy et la gestion NAS est couverte par =
«&nbsp;openMediaVault&nbsp;». Les systèmes de fichiers =
sont situés sur des volumes logiques (LVM) et formatés en Ext4 =
dont la limité de volume affichée en taille est de 1 Eio (1024 =
Tio) (<a href="https://fr.wikipedia.org/wiki/Ext4" =
class="">https://fr.wikipedia.org/wiki/Ext4</a>).</div><div =
class="">Nous avons des volumes de 50 To et j’ai eu besoin =
d’agrandir l’un de ceux-ci. Malheur à moi car =
autant il semble que les commandes de création de volume physique =
(pv…), de volumes logiques (lv…) et de création de =
système de fichiers fonctionne, autant la commande =
d’agrandissement du système de fichiers =
(«&nbsp;resize2fs&nbsp;») ne fonctionne pas et me sort un =
«&nbsp;<font color="rgba(0, 0, 0, 0)" face="Consolas, Monaco, =
Andale Mono, monospace" class=""><span style="white-space: =
pre-wrap;" class="">resize2fs: New size too large to be expressed in =
32 bits</span></font><span style="white-space: pre-wrap;" =
class=""><font face="Consolas, Monaco, Andale Mono, monospace" =
class="">&nbsp;</font>» très désagréable.</span></di=
v><div class=""><span style="white-space: pre-wrap;" class=""><br =
class=""></span></div><div class=""><span style="white-space: =
pre-wrap;" class="">En cherchant, en suivant le post (<a =
href="http://permalink.gmane.org/gmane.comp.file-systems.ext4/19565" =
class="">http://permalink.gmane.org/gmane.comp.file-systems.ext4/19565</=
a>), j’ai pu constater que mon fichier «&nbsp;</span><span =
style="background-color: rgb(255, 255, 255);" =
class="">/etc/mke2fs.conf&nbsp;» contenait bien la =
référence&nbsp;«&nbsp;</span><span =
style="background-color: rgb(255, 255, 255);" =
class="">auto_64-bit_support = 1&nbsp;» qui semble limiter les =
commandes&nbsp;«&nbsp;e2fsprogs&nbsp;». Mais selon le blog de =
Ronny Egners&nbsp;«&nbsp;</span><a =
href="http://blog.ronnyegner-consulting.de/2011/08/18/ext4-and-the-16-tb=
-limit-now-solved" =
class="">http://blog.ronnyegner-consulting.de/2011/08/18/ext4-and-the-16=
-tb-limit-now-solved</a>/« &nbsp;il est clairement écrit que =
l’agrandissement au delà des fatidiques 16 To est =
impossible.</div><div class=""><br class=""></div><div class="">Tous=
ces échanges datant de 2013 et aucune modification n’ayant =
été apportée depuis sur nos distributions j’en =
déduis que le problème est peut être inhérent au =
système et difficilement solvable. Ayant besoin de cet espace, de =
beaucoup plus d’espace à l’avenir (on pense au Po), =
je me dis qu’il faudrait peut-être changer notre fusil =
d’épaule et rechercher des solutions de systèmes de =
fichiers autres; ou même de méta-systèmes de fichiers =
regroupant plusieurs FS.&nbsp;</div><div class=""><br =
class=""></div><div class="">J’ai lu que BtrFS semblait se =
présenter comme le «&nbsp;successeur&nbsp;» de ext4 et =
proposait un redimensionnement à chaud en complément du =
gestionnaire de volumes logiques de Linux. Il permettrait également =
l’agrégat de préifériques et la gestion de =
«&nbsp;snapshots&nbsp;» (<a =
href="https://fr.wikipedia.org/wiki/Btrfs" =
class="">https://fr.wikipedia.org/wiki/Btrfs</a>). Avez-vous une =
expérience dans ce domaine et est-ce que cela répondrait à =
notre besoin de gros volumes extensibles ?</div><div class=""><br =
class=""></div><div class="">J’ai également lu un truc =
sur le stockage distribué avec le projet «&nbsp;GlusterFS&nbsp;=
(<a =
href="https://www.synergeek.fr/glusterfs-3-1-stockage-distribue-redondan=
t-pour-linux" =
class="">https://www.synergeek.fr/glusterfs-3-1-stockage-distribue-redon=
dant-pour-linux</a>,&nbsp;<a =
href="http://www.supinfo.com/articles/single/171-mise-place-stockage-par=
tage-avec-glusterfs" =
class="">http://www.supinfo.com/articles/single/171-mise-place-stockage-=
partage-avec-glusterfs</a>,&nbsp;<a =
href="https://fr.wikipedia.org/wiki/GlusterFS" =
class="">https://fr.wikipedia.org/wiki/GlusterFS</a>) qui pourrait =
nous permettre de distribuer notre stockage. Idem, avez-vous de =
l’expérience dans ce domaine ?</div><div class=""><br =
class=""></div><div class="">Merci d'avance</div><div class=""><br =
class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: =
auto; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=""><div style="margin: 0px; font-size: 10px; font-family: =
'Courier New';" class=""><div style="margin: 0px;" =
class="">--&nbsp;</div><div style="margin: 0px;" class="">Pierre =
Malard</div><div style="margin: 0px; min-height: 11px;" class=""><br =
class=""></div><div style="font-size: 12px; margin: 0px; =
font-family: Times;" class="">&nbsp; &nbsp;«&nbsp;<i =
class="">L'émancipation politique doit marcher de pair avec =
l'émancipation</i></div><div style="font-size: 12px; margin: 0px; =
font-family: Times;" class=""><i class="">&nbsp; &nbsp;&nbsp;sociale =
ou les résultats sont désastreux&nbsp;</i>»</div><div =
style="font-size: 12px; margin: 0px; font-family: Times;" =
class=""><span class="Apple-tab-span" style="white-space: pre;"> =
</span>&nbsp; &nbsp;&nbsp;Romain Gary - "Les racines du =
ciel"</div><div style="margin: 0px;" class="">&nbsp; &nbsp;|&nbsp; =
&nbsp; &nbsp;&nbsp;_,,,,,_</div><div style="margin: 0px;" =
class="">&nbsp;&nbsp;&nbsp;/,`.-'`'&nbsp; =
&nbsp;&nbsp;-.&nbsp;&nbsp;;-;;,_</div><div style="margin: 0px;" =
class="">&nbsp;&nbsp;|,4-&nbsp;&nbsp;) )-,_. , =
(&nbsp;&nbsp;`'-'</div><div style="margin: 0px;" =
class="">&nbsp;'''(_/--'&nbsp;&nbsp;`-'_) &nbsp; πr</div><div =
style="font-size: 12px; margin: 0px; font-family: Times; min-height: =
14px;" class=""><br class=""></div><div style="margin: 0px;" =
class="">perl -e '$_=q#: 3| 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. =
&nbsp;;-;;,_: &nbsp;|,A- &nbsp;) )-,_. , ( &nbsp;`'"'"'-'"'"': =
'"'"'-3'"'"'2(_/--'"'"' &nbsp;`-'"'"'_): =
24πr::#;y#:##;s#(D)(d+)#$1x$2#ge;print'</div><div =
style="margin: 0px;" class="">- --&gt; Ce message n’engage =
que son auteur &lt;--</div></div></div>
</div>
<br class=""></div></body></html>=

--Apple-Mail=_E8386464-6ECE-440E-846B-F4DACDCD4D16--

--Apple-Mail=_FEC0AADF-056B-45E3-93A8-019DE8DC76B7
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP

--BEGIN PGP SIGNATURE--

iQIcBAEBCgAGBQJY0QOgAAoJEP6Ulh7mnfwYM4EQAIR15csRFM8xUsLUhOmPUBC6
OSzBSdsNlzm6/nWYTVeAJ+Ygmh3ZkrtC2pjpKnqr3uyzIBOGynB3SdVClvjO01KJ
Be5QVtebs/VblQKBxh4xUOvNxM3KHwFhm6pGC2vXzBgHV1bqkEQ6XdFrK8mMpNt/
6I+EH0uTnC4gcXNnkW1ILjfiUnNukX4U/6713iSkLMHRQcx8qDAvcxvhP8BzQ84J
EJ5GsIgY8HKLkBdl9yVEsufICQQAn3iQB+XO1cR5lIdthgNlDUn3AWLciiYwEEgi
cblBk0+h5oP1Si517VYdEOccGDERtxSnK89w8IN2jojdXMxoxX+q8oasH+JVhpaq
OR/OyYfiUfp+PJVPU+7CgYhTQi7m0Bo6AKjx4fBPVUTbMjYKWOwTCKduZp1564+j
2cQxeMbcnQ1UknL1kKiI3qpZLQ6+rkydMvVk/2BCGyGdjNSLICYkWczS4kXe7bQl
AMShpwEed8q843h4e8YJQ78H93gbJaz2VHVRachwnZ/sp/nuMjCf0UV4sjMKMMyl
xk2C+SboGZA1fCv7eZ2CN7uM6x6HODw1Yoy0/bh0uetCKJIk8Kev1a9fL0qOsn+H
V6BvNSsi46RZEbhv2tqLYwaD9TKBmjoPjzEvOmBNf0m0Z5V8qlz7+wuLoovBkHoJ
1V5ue4sBgsWEB0FfMQqn
=ZtTl
--END PGP SIGNATURE--

--Apple-Mail=_FEC0AADF-056B-45E3-93A8-019DE8DC76B7--
Vos réponses Page 2 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Gabriel Moreau
Le #26429777
Également, et depuis des années. Seul /boot est en ext3. Il devait y avoir
une raison, dont je ne me rappelle pas !

Il faut / fallait que grub connaisse le système de fichier de /boot.
gaby
--
Gabriel Moreau - IR CNRS http://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France
mailto: tel:+33.476.825.015
maderios
Le #26429782
On 03/23/2017 11:13 AM, Gabriel Moreau wrote:
Également, et depuis des années. Seul /boot est en ext3. Il devait y
avoir
une raison, dont je ne me rappelle pas !

Il faut / fallait que grub connaisse le système de fichier de /boot.

Il semble que grub supporte xfs depuis la version 0.97
http://xfs.org/index.php/XFS_FAQ#Q:_Does_GRUB_work_with_XFS.3F
--
Maderios
Thierry Bugier Pineau
Le #26432893
------4X3LYFIGGAK8MY4BRFU6774D0UUAVS
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
Bonjour
Ce n'est pas tordre le système de snapshot que de les garder longtemp s ?
Pour lvm les snapshots sont en copy on write. Apparemment btrfs ferait p areil vu la description du comportement.
Tout ce que j'ai lu dit que les snapshot sont des instantanés qui ser vent le temps d'un backup. Autrement dit :
- on fige le FS sur le disque
- on met à part les écritures (une sorte de tampon, et lvm ou le FS le gère selon le cas)
-jusqu'à ce que le FS figé soit pleinement exploité pour un e tâche de sauvegarde.
- la tâche terminée, on détruit le snapshot en y incorporan t les écritures précédemment mises à part (là enco re lvm ou le FS gère cela)
On peut tout aussi bien historiser les sauvegardes et laisser le backup le s gérer (backuppc par exemple mais guère pour un usage pro sur gr osse quantités de données)
Le 2 mai 2017 17:46:40 GMT+02:00, Daniel Caillibaud
Le 21/03/17 à 11:42, Pierre Malard PM> J’ai lu que BtrFS semblait se présenter comme le « successeur » de
ext4 et proposait un
PM> redimensionnement à chaud en complément du gestionnaire de volumes
logiques de Linux. Il
PM> permettrait également l’agrégat de préifé riques et la gestion de «
snapshots
PM> » (https://fr.wikipedia.org/wiki/Btrfs). Avez-vous une exp érience
dans ce domaine et est-ce
PM> que cela répondrait à notre besoin de gros volumes extensib les ?
J'arrive longtemps après la question, au cas où ça serve à d'autres…
Je n'ai pas d'expérience de btrfs sur de tels volumes, mais sur 3~4T o
de datas avec bcp de
snapshots, il faut faire attention à l'ordre des snaphots pour garde r
une "filiation la plus
linéaire possible".
C'était pour du backup, je faisais
- rsync de pleins de vm dans last (un subvolume)
- delete Monday && snapshot de last sur Monday le lundi
- … idem les autres jours, avec en plus le dimanche un
- delete week_XX && snapshot de last sur week_XX
mais de temps en temps, et de plus en plus souvent avec l'augmentation
du nb de snapshots, le
delete faisait complètement exploser le système, à retarde ment (lorsque
btrfs nettoie ses
metadatas, un peu plus tard, si le rsync démarre avant que tout soit
nettoyé).
L'explosion se traduisait par un système qui fige, avec ou sans oomk ill
tous azimuts.
Un expert btrfs m'a confirmé avoir déjà vu la RAM exploser dans ce
genre de cas, sans vraiment
savoir pourquoi… (que le load explose parce que le fs devient tr ès lent
ça peut s'expliquer,
mais pas qu'il consomme énormément de RAM).
C'est visiblement lié au fait du nb de snapshots qui dépendaien t du
volume dans lequel
j'écrivais, chaque écriture sur un fichier déclenchant une cascade
d'opérations pour que tous
les subvolumes retrouvent leurs petits (tous ses snapshots doivent se
mettre à jour sur
l'ancienne version du fichier, trouver lequel la détient, etc.)
En modifiant la rotation pour faire
mv Monday avirer
mv last Monday
snapshot Monday last
rsync vers last
ça va bcp mieux (chaque écriture ne déclenche qu'un seul c opy on write
sur le dernier snapshot
sans que les autres n'aient à faire qqchose, la suppression d'un
subvolume n'entraînant de
modif que chez son unique "fils").
Tout ça pour dire que btrfs reste chatouilleux et peut partir en vri lle
(machine HS mais pas
perdu d'octet), même si la gestion des snapshots reste un avantage t rès
appréciable.
Et je n'ai pas encore osé passer au btrfs send/receive pour
synchroniser deux volumes, mais
chez d'autres ça marche vraiment très bien (10~100 × plus rapide que
rsync suivant le nb de
fichiers, le volume et la BP dispo).
--
Daniel
On devrait construire les villes a la campagne
car l'air y est plus pur !
Alphonse Allais

--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez exc user ma brièveté.
------4X3LYFIGGAK8MY4BRFU6774D0UUAVS
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body>Bonjour<br>
<br>
Ce n&#39;est pas tordre le système de snapshot que de les garder long temps ?<br>
<br>
Pour lvm les snapshots sont en copy on write. Apparemment btrfs ferait p areil vu la description du comportement.<br>
<br>
Tout ce que j&#39;ai lu dit que les snapshot sont des instantanés qui servent le temps d&#39;un backup. Autrement dit : <br>
- on fige le FS sur le disque <br>
- on met à part les écritures (une sorte de tampon, et lvm ou le FS le gère selon le cas)<br>
-jusqu&#39;à ce que le FS figé soit pleinement exploité pou r une tâche de sauvegarde.<br>
- la tâche terminée, on détruit le snapshot en y incorporan t les écritures précédemment mises à part (là enco re lvm ou le FS gère cela)<br>
<br>
On peut tout aussi bien historiser les sauvegardes et laisser le backup le s gérer (backuppc par exemple mais guère pour un usage pro sur gr osse quantités de données)<br>
-- <br>
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez exc user ma brièveté.</body></html>
------4X3LYFIGGAK8MY4BRFU6774D0UUAVS--
Publicité
Poster une réponse
Anonyme