J=E2=80=99ai repris un lourd dossier de l=E2=80=99administration de =
serveurs g=C3=A9ographiques pour notre UMR. Ce projet n=E2=80=99a pas de =
buts lucratifs et est principalement ouvert =C3=A0 la recherche et aux =
collectivit=C3=A9s.
Le syst=C3=A8me repose sur un SAN Dell de 250 To pour l=E2=80=99instant =
(PowerVault MD3860f) raccord=C3=A9 =C3=A0 une lame Dell (PowerEdge R620) =
pour offrir un service NAS (NFS, FTP, SMB, =E2=80=A6). Le serveur tourne =
sur Debian Wheezy et la gestion NAS est couverte par =C2=AB =
openMediaVault =C2=BB. Les syst=C3=A8mes de fichiers sont situ=C3=A9s =
sur des volumes logiques (LVM) et format=C3=A9s en Ext4 dont la limit=C3=A9=
de volume affich=C3=A9e en taille est de 1 Eio (1024 Tio) =
(https://fr.wikipedia.org/wiki/Ext4).
Nous avons des volumes de 50 To et j=E2=80=99ai eu besoin d=E2=80=99agrand=
ir l=E2=80=99un de ceux-ci. Malheur =C3=A0 moi car autant il semble que =
les commandes de cr=C3=A9ation de volume physique (pv=E2=80=A6), de =
volumes logiques (lv=E2=80=A6) et de cr=C3=A9ation de syst=C3=A8me de =
fichiers fonctionne, autant la commande d=E2=80=99agrandissement du =
syst=C3=A8me de fichiers (=C2=AB resize2fs =C2=BB) ne fonctionne pas et =
me sort un =C2=AB resize2fs: New size too large to be expressed in 32 =
bits =C2=BB tr=C3=A8s d=C3=A9sagr=C3=A9able.
En cherchant, en suivant le post =
(http://permalink.gmane.org/gmane.comp.file-systems.ext4/19565), j=E2=80=99=
ai pu constater que mon fichier =C2=AB /etc/mke2fs.conf =C2=BB contenait =
bien la r=C3=A9f=C3=A9rence =C2=AB auto_64-bit_support =3D 1 =C2=BB qui =
semble limiter les commandes =C2=AB e2fsprogs =C2=BB. Mais selon le blog =
de Ronny Egners =C2=AB =
http://blog.ronnyegner-consulting.de/2011/08/18/ext4-and-the-16-tb-limit-n=
ow-solved/=C2=AB il est clairement =C3=A9crit que l=E2=80=99agrandissemen=
t au del=C3=A0 des fatidiques 16 To est impossible.
Tous ces =C3=A9changes datant de 2013 et aucune modification n=E2=80=99aya=
nt =C3=A9t=C3=A9 apport=C3=A9e depuis sur nos distributions j=E2=80=99en =
d=C3=A9duis que le probl=C3=A8me est peut =C3=AAtre inh=C3=A9rent au =
syst=C3=A8me et difficilement solvable. Ayant besoin de cet espace, de =
beaucoup plus d=E2=80=99espace =C3=A0 l=E2=80=99avenir (on pense au Po), =
je me dis qu=E2=80=99il faudrait peut-=C3=AAtre changer notre fusil =
d=E2=80=99=C3=A9paule et rechercher des solutions de syst=C3=A8mes de =
fichiers autres; ou m=C3=AAme de m=C3=A9ta-syst=C3=A8mes de fichiers =
regroupant plusieurs FS.
J=E2=80=99ai lu que BtrFS semblait se pr=C3=A9senter comme le =C2=AB =
successeur =C2=BB de ext4 et proposait un redimensionnement =C3=A0 chaud =
en compl=C3=A9ment du gestionnaire de volumes logiques de Linux. Il =
permettrait =C3=A9galement l=E2=80=99agr=C3=A9gat de pr=C3=A9if=C3=A9rique=
s et la gestion de =C2=AB snapshots =C2=BB =
(https://fr.wikipedia.org/wiki/Btrfs). Avez-vous une exp=C3=A9rience =
dans ce domaine et est-ce que cela r=C3=A9pondrait =C3=A0 notre besoin =
de gros volumes extensibles ?
J=E2=80=99ai =C3=A9galement lu un truc sur le stockage distribu=C3=A9 =
avec le projet =C2=AB GlusterFS =C2=BB =
(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=E2=80=99exp=C3=A9rience=
dans ce domaine ?
Merci d'avance
--
Pierre Malard
=C2=AB L'=C3=A9mancipation politique doit marcher de pair avec =
l'=C3=A9mancipation
sociale ou les r=C3=A9sultats sont d=C3=A9sastreux =C2=BB
Romain Gary - "Les racines du ciel"
|\ _,,,---,,_
/,`.-'`' -. ;-;;,_
|,4- ) )-,_. ,\ ( `'-'
'---''(_/--' `-'\_) =CF=80r
perl -e '$_=3Dq#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) =
)-,_. ,\ ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): =
24=CF=80r::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n=E2=80=99engage que son auteur <--
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">Bonjour,<div class=3D""><br class=3D""></div><div =
class=3D"">J=E2=80=99ai repris un lourd dossier de l=E2=80=99administratio=
n de serveurs g=C3=A9ographiques pour notre UMR. Ce projet n=E2=80=99a =
pas de buts lucratifs et est principalement ouvert =C3=A0 la recherche =
et aux collectivit=C3=A9s.</div><div class=3D"">Le syst=C3=A8me repose =
sur un SAN Dell de 250 To pour l=E2=80=99instant (PowerVault MD3860f) =
raccord=C3=A9 =C3=A0 une lame Dell (PowerEdge R620) pour offrir un =
service NAS (NFS, FTP, SMB, =E2=80=A6). Le serveur tourne sur Debian =
Wheezy et la gestion NAS est couverte par =
=C2=AB openMediaVault =C2=BB. Les syst=C3=A8mes de fichiers =
sont situ=C3=A9s sur des volumes logiques (LVM) et format=C3=A9s en Ext4 =
dont la limit=C3=A9 de volume affich=C3=A9e en taille est de 1 Eio (1024 =
Tio) (<a href=3D"https://fr.wikipedia.org/wiki/Ext4" =
class=3D"">https://fr.wikipedia.org/wiki/Ext4</a>).</div><div =
class=3D"">Nous avons des volumes de 50 To et j=E2=80=99ai eu besoin =
d=E2=80=99agrandir l=E2=80=99un de ceux-ci. Malheur =C3=A0 moi car =
autant il semble que les commandes de cr=C3=A9ation de volume physique =
(pv=E2=80=A6), de volumes logiques (lv=E2=80=A6) et de cr=C3=A9ation de =
syst=C3=A8me de fichiers fonctionne, autant la commande =
d=E2=80=99agrandissement du syst=C3=A8me de fichiers =
(=C2=AB resize2fs =C2=BB) ne fonctionne pas et me sort un =
=C2=AB <font color=3D"rgba(0, 0, 0, 0)" face=3D"Consolas, Monaco, =
Andale Mono, monospace" class=3D""><span style=3D"white-space: =
pre-wrap;" class=3D"">resize2fs: New size too large to be expressed in =
32 bits</span></font><span style=3D"white-space: pre-wrap;" =
class=3D""><font face=3D"Consolas, Monaco, Andale Mono, monospace" =
class=3D""> </font>=C2=BB tr=C3=A8s d=C3=A9sagr=C3=A9able.</span></di=
v><div class=3D""><span style=3D"white-space: pre-wrap;" class=3D""><br =
class=3D""></span></div><div class=3D""><span style=3D"white-space: =
pre-wrap;" class=3D"">En cherchant, en suivant le post (<a =
href=3D"http://permalink.gmane.org/gmane.comp.file-systems.ext4/19565" =
class=3D"">http://permalink.gmane.org/gmane.comp.file-systems.ext4/19565</=
a>), j=E2=80=99ai pu constater que mon fichier =C2=AB </span><span =
style=3D"background-color: rgb(255, 255, 255);" =
class=3D"">/etc/mke2fs.conf =C2=BB contenait bien la =
r=C3=A9f=C3=A9rence =C2=AB </span><span =
style=3D"background-color: rgb(255, 255, 255);" =
class=3D"">auto_64-bit_support =3D 1 =C2=BB qui semble limiter les =
commandes =C2=AB e2fsprogs =C2=BB. Mais selon le blog de =
Ronny Egners =C2=AB </span><a =
href=3D"http://blog.ronnyegner-consulting.de/2011/08/18/ext4-and-the-16-tb=
-limit-now-solved" =
class=3D"">http://blog.ronnyegner-consulting.de/2011/08/18/ext4-and-the-16=
-tb-limit-now-solved</a>/=C2=AB il est clairement =C3=A9crit que =
l=E2=80=99agrandissement au del=C3=A0 des fatidiques 16 To est =
impossible.</div><div class=3D""><br class=3D""></div><div class=3D"">Tous=
ces =C3=A9changes datant de 2013 et aucune modification n=E2=80=99ayant =
=C3=A9t=C3=A9 apport=C3=A9e depuis sur nos distributions j=E2=80=99en =
d=C3=A9duis que le probl=C3=A8me est peut =C3=AAtre inh=C3=A9rent au =
syst=C3=A8me et difficilement solvable. Ayant besoin de cet espace, de =
beaucoup plus d=E2=80=99espace =C3=A0 l=E2=80=99avenir (on pense au Po), =
je me dis qu=E2=80=99il faudrait peut-=C3=AAtre changer notre fusil =
d=E2=80=99=C3=A9paule et rechercher des solutions de syst=C3=A8mes de =
fichiers autres; ou m=C3=AAme de m=C3=A9ta-syst=C3=A8mes de fichiers =
regroupant plusieurs FS. </div><div class=3D""><br =
class=3D""></div><div class=3D"">J=E2=80=99ai lu que BtrFS semblait se =
pr=C3=A9senter comme le =C2=AB successeur =C2=BB de ext4 et =
proposait un redimensionnement =C3=A0 chaud en compl=C3=A9ment du =
gestionnaire de volumes logiques de Linux. Il permettrait =C3=A9galement =
l=E2=80=99agr=C3=A9gat de pr=C3=A9if=C3=A9riques et la gestion de =
=C2=AB snapshots =C2=BB (<a =
href=3D"https://fr.wikipedia.org/wiki/Btrfs" =
class=3D"">https://fr.wikipedia.org/wiki/Btrfs</a>). Avez-vous une =
exp=C3=A9rience dans ce domaine et est-ce que cela r=C3=A9pondrait =C3=A0 =
notre besoin de gros volumes extensibles ?</div><div class=3D""><br =
class=3D""></div><div class=3D"">J=E2=80=99ai =C3=A9galement lu un truc =
sur le stockage distribu=C3=A9 avec le projet =C2=AB GlusterFS =C2=
=BB (<a =
href=3D"https://www.synergeek.fr/glusterfs-3-1-stockage-distribue-redondan=
t-pour-linux" =
class=3D"">https://www.synergeek.fr/glusterfs-3-1-stockage-distribue-redon=
dant-pour-linux</a>, <a =
href=3D"http://www.supinfo.com/articles/single/171-mise-place-stockage-par=
tage-avec-glusterfs" =
class=3D"">http://www.supinfo.com/articles/single/171-mise-place-stockage-=
partage-avec-glusterfs</a>, <a =
href=3D"https://fr.wikipedia.org/wiki/GlusterFS" =
class=3D"">https://fr.wikipedia.org/wiki/GlusterFS</a>) qui pourrait =
nous permettre de distribuer notre stockage. Idem, avez-vous de =
l=E2=80=99exp=C3=A9rience dans ce domaine ?</div><div class=3D""><br =
class=3D""></div><div class=3D"">Merci d'avance</div><div class=3D""><br =
class=3D""><div class=3D"">
<div style=3D"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=3D""><div style=3D"margin: 0px; font-size: 10px; font-family: =
'Courier New';" class=3D""><div style=3D"margin: 0px;" =
class=3D"">-- </div><div style=3D"margin: 0px;" class=3D"">Pierre =
Malard</div><div style=3D"margin: 0px; min-height: 11px;" class=3D""><br =
class=3D""></div><div style=3D"font-size: 12px; margin: 0px; =
font-family: Times;" class=3D""> =C2=AB <i =
class=3D"">L'=C3=A9mancipation politique doit marcher de pair avec =
l'=C3=A9mancipation</i></div><div style=3D"font-size: 12px; margin: 0px; =
font-family: Times;" class=3D""><i class=3D""> sociale =
ou les r=C3=A9sultats sont d=C3=A9sastreux </i>=C2=BB</div><div =
style=3D"font-size: 12px; margin: 0px; font-family: Times;" =
class=3D""><span class=3D"Apple-tab-span" style=3D"white-space: pre;"> =
</span> Romain Gary - "Les racines du =
ciel"</div><div style=3D"margin: 0px;" class=3D""> |\ =
_,,,---,,_</div><div style=3D"margin: 0px;" =
class=3D""> /,`.-'`' =
-. ;-;;,_</div><div style=3D"margin: 0px;" =
class=3D""> |,4- ) )-,_. ,\ =
( `'-'</div><div style=3D"margin: 0px;" =
class=3D""> '---''(_/--' `-'\_) =CF=80r</div><div =
style=3D"font-size: 12px; margin: 0px; font-family: Times; min-height: =
14px;" class=3D""><br class=3D""></div><div style=3D"margin: 0px;" =
class=3D"">perl -e '$_=3Dq#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. =
;-;;,_: |,A- ) )-,_. ,\ ( `'"'"'-'"'"': =
'"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): =
24=CF=80r::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'</div><div =
style=3D"margin: 0px;" class=3D"">- --> Ce message n=E2=80=99engage =
que son auteur <--</div></div></div>
</div>
<br class=3D""></div></body></html>=
É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
É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:Gabriel.Moreau@legi.grenoble-inp.fr tel:+33.476.825.015
É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
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
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
É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
------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 a écrit :
Le 21/03/17 à 11:42, Pierre Malard a é crit : 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'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'ai lu dit que les snapshot sont des instantanés qui servent le temps d'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'à 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><br><div class="gmail_quote">Le 2 mai 2017 17:46:40 GMT+02:00, Danie l Caillibaud <> a écrit :<blockquote class ="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px sol id rgb(204, 204, 204); padding-left: 1ex;"> <pre class="k9mail">Le 21/03/17 à 11:42, Pierre Malard < ledetection.fr> a écrit : PM> J’ai lu que BtrFS s emblait se présenter comme le « successeur » de ext4 et proposait un PM> redimensionnement à chaud en complém ent du gestionnaire de volumes logiques de Linux. Il PM> permettr ait également l’agrégat de préifériques e t la gestion de « snapshots PM> » (<a href="https://f r.wikipedia.org/wiki/Btrfs">https://fr.wikipedia.org/wiki/Btrfs</a> ). Avez-vous une expérience dans ce domaine et est-ce PM> que cela répondrait à notre besoin de gros volumes extensible s ? J'arrive longtemps après la question, au cas où ; ça serve à d'autres… Je n'ai pas d'exp&ea cute;rience de btrfs sur de tels volumes, mais sur 3~4To de datas avec bcp de snapshots, il faut faire attention à l'ordre des snaphots po ur garder une "filiation la plus linéaire possible" . C'était pour du backup, je faisais - rsync de pl eins de vm dans last (un subvolume) - delete Monday && snapsho t de last sur Monday le lundi - … idem les autres jours, avec e n 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ètem ent exploser le système, à retardement (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 s ystème qui fige, avec ou sans oomkill tous azimuts. Un expert btrfs m'a confirmé avoir déjà vu la RAM explos er dans ce genre de cas, sans vraiment savoir pourquoi… (que le load explose parce que le fs devient très lent ça peut s'exp liquer, mais pas qu'il consomme énormément de RAM).<br /> C'est visiblement lié au fait du nb de snapshots qui d&eacu te;pendaient du volume dans lequel j'écrivais, chaque éc riture sur un fichier déclenchant une cascade d'opérations po ur que tous les subvolumes retrouvent leurs petits (tous ses snapshots doivent se mettre à jour sur l'ancienne version du fichier, tr ouver 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 copy on write sur le dernier snapsh ot sans que les autres n'aient à faire qqchose, la suppression d'un subvolume n'entraînant de modif que chez son unique "f ils"). Tout ça pour dire que btrfs reste chatouill eux et peut partir en vrille (machine HS mais pas perdu d'octet), m&ec irc;me si la gestion des snapshots reste un avantage très appr&eacut e;ciable. Et je n'ai pas encore osé passer au btrfs sen d/receive pour synchroniser deux volumes, mais chez d'autres ça marche vraiment très bien (10~100 × plus rapide que rsync sui vant le nb de fichiers, le volume et la BP dispo). </pre></bloc kquote></div><br> -- <br> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez exc user ma brièveté.</body></html> ------4X3LYFIGGAK8MY4BRFU6774D0UUAVS--
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 <ml@lairdutemps.org> a écrit :
Le 21/03/17 à 11:42, Pierre Malard <plm@teledetection.fr> a é crit :
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'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'ai lu dit que les snapshot sont des instantanés qui servent le temps d'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'à 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><br><div class="gmail_quote">Le 2 mai 2017 17:46:40 GMT+02:00, Danie l Caillibaud <ml@lairdutemps.org> a écrit :<blockquote class ="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px sol id rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Le 21/03/17 à 11:42, Pierre Malard <plm@te ledetection.fr> a écrit :<br />PM> J’ai lu que BtrFS s emblait se présenter comme le « successeur » de ext4 et proposait un<br />PM> redimensionnement à chaud en complém ent du gestionnaire de volumes logiques de Linux. Il<br />PM> permettr ait également l’agrégat de préifériques e t la gestion de « snapshots<br />PM> » (<a href="https://f r.wikipedia.org/wiki/Btrfs">https://fr.wikipedia.org/wiki/Btrfs</a> ). Avez-vous une expérience dans ce domaine et est-ce<br />PM> que cela répondrait à notre besoin de gros volumes extensible s ?<br /><br />J'arrive longtemps après la question, au cas où ; ça serve à d'autres…<br /><br />Je n'ai pas d'exp&ea cute;rience de btrfs sur de tels volumes, mais sur 3~4To de datas avec bcp de<br />snapshots, il faut faire attention à l'ordre des snaphots po ur garder une "filiation la plus<br />linéaire possible" .<br /><br />C'était pour du backup, je faisais<br />- rsync de pl eins de vm dans last (un subvolume)<br />- delete Monday && snapsho t de last sur Monday le lundi<br />- … idem les autres jours, avec e n plus le dimanche un<br />- delete week_XX && snapshot de last sur week_XX<br /><br />mais de temps en temps, et de plus en plus souvent avec l'augmentation du nb de snapshots, le<br />delete faisait complètem ent exploser le système, à retardement (lorsque btrfs nettoie ses<br />metadatas, un peu plus tard, si le rsync démarre avant que tout soit nettoyé).<br /><br />L'explosion se traduisait par un s ystème qui fige, avec ou sans oomkill tous azimuts. <br /><br />Un expert btrfs m'a confirmé avoir déjà vu la RAM explos er dans ce genre de cas, sans vraiment<br />savoir pourquoi… (que le load explose parce que le fs devient très lent ça peut s'exp liquer,<br />mais pas qu'il consomme énormément de RAM).<br /><br />C'est visiblement lié au fait du nb de snapshots qui d&eacu te;pendaient du volume dans lequel<br />j'écrivais, chaque éc riture sur un fichier déclenchant une cascade d'opérations po ur que tous<br />les subvolumes retrouvent leurs petits (tous ses snapshots doivent se mettre à jour sur<br />l'ancienne version du fichier, tr ouver lequel la détient, etc.)<br /><br />En modifiant la rotation pour faire<br />mv Monday avirer<br />mv last Monday<br />snapshot Monday last<br />rsync vers last<br /><br />ça va bcp mieux (chaque é ;criture ne déclenche qu'un seul copy on write sur le dernier snapsh ot<br />sans que les autres n'aient à faire qqchose, la suppression d'un subvolume n'entraînant de<br />modif que chez son unique "f ils").<br /><br />Tout ça pour dire que btrfs reste chatouill eux et peut partir en vrille (machine HS mais pas<br />perdu d'octet), m&ec irc;me si la gestion des snapshots reste un avantage très appr&eacut e;ciable.<br /><br />Et je n'ai pas encore osé passer au btrfs sen d/receive pour synchroniser deux volumes, mais<br />chez d'autres ça marche vraiment très bien (10~100 × plus rapide que rsync sui vant le nb de<br />fichiers, le volume et la BP dispo).<br /></pre></bloc kquote></div><br>
-- <br>
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez exc user ma brièveté.</body></html>
------4X3LYFIGGAK8MY4BRFU6774D0UUAVS--
------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 a écrit :
Le 21/03/17 à 11:42, Pierre Malard a é crit : 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'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'ai lu dit que les snapshot sont des instantanés qui servent le temps d'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'à 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><br><div class="gmail_quote">Le 2 mai 2017 17:46:40 GMT+02:00, Danie l Caillibaud <> a écrit :<blockquote class ="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px sol id rgb(204, 204, 204); padding-left: 1ex;"> <pre class="k9mail">Le 21/03/17 à 11:42, Pierre Malard < ledetection.fr> a écrit : PM> J’ai lu que BtrFS s emblait se présenter comme le « successeur » de ext4 et proposait un PM> redimensionnement à chaud en complém ent du gestionnaire de volumes logiques de Linux. Il PM> permettr ait également l’agrégat de préifériques e t la gestion de « snapshots PM> » (<a href="https://f r.wikipedia.org/wiki/Btrfs">https://fr.wikipedia.org/wiki/Btrfs</a> ). Avez-vous une expérience dans ce domaine et est-ce PM> que cela répondrait à notre besoin de gros volumes extensible s ? J'arrive longtemps après la question, au cas où ; ça serve à d'autres… Je n'ai pas d'exp&ea cute;rience de btrfs sur de tels volumes, mais sur 3~4To de datas avec bcp de snapshots, il faut faire attention à l'ordre des snaphots po ur garder une "filiation la plus linéaire possible" . C'était pour du backup, je faisais - rsync de pl eins de vm dans last (un subvolume) - delete Monday && snapsho t de last sur Monday le lundi - … idem les autres jours, avec e n 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ètem ent exploser le système, à retardement (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 s ystème qui fige, avec ou sans oomkill tous azimuts. Un expert btrfs m'a confirmé avoir déjà vu la RAM explos er dans ce genre de cas, sans vraiment savoir pourquoi… (que le load explose parce que le fs devient très lent ça peut s'exp liquer, mais pas qu'il consomme énormément de RAM).<br /> C'est visiblement lié au fait du nb de snapshots qui d&eacu te;pendaient du volume dans lequel j'écrivais, chaque éc riture sur un fichier déclenchant une cascade d'opérations po ur que tous les subvolumes retrouvent leurs petits (tous ses snapshots doivent se mettre à jour sur l'ancienne version du fichier, tr ouver 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 copy on write sur le dernier snapsh ot sans que les autres n'aient à faire qqchose, la suppression d'un subvolume n'entraînant de modif que chez son unique "f ils"). Tout ça pour dire que btrfs reste chatouill eux et peut partir en vrille (machine HS mais pas perdu d'octet), m&ec irc;me si la gestion des snapshots reste un avantage très appr&eacut e;ciable. Et je n'ai pas encore osé passer au btrfs sen d/receive pour synchroniser deux volumes, mais chez d'autres ça marche vraiment très bien (10~100 × plus rapide que rsync sui vant le nb de fichiers, le volume et la BP dispo). </pre></bloc kquote></div><br> -- <br> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez exc user ma brièveté.</body></html> ------4X3LYFIGGAK8MY4BRFU6774D0UUAVS--
