Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 04/04/2013, à 10:27

zapan999

resize2fs >16To quel choix?

Bonjour,

Suite à mon précédent post, et souhaitant rester dans une optique de clarté pour le forum "une question = un post", voici un nouveau post:


Voici la problématique:

serveur ayant 6 disques +1 spare de 3To en raid 5 sous mdadm (un était en panne au déballage, donc j'ai monter le raid avec 7 disques)
réception du 8eme disque, un petit coup de mdadm grow et hop, nickel, le raid est ok.

dans le post précédent, je me suis heurté à la limitation à 16To de ext4 avec des blocs de 4096b (4k).

J'aimerai donc des avis/conseils sur la marche à suivre, sachant qu'actuellement le volume raid fait 18To utilisables, et est amené a évoluer jusqu'à 20 disques (dont 1 spare, soit une cinquantaine de To utiles)

1 - faire une deuxième partition. bof, aucun challenge, et je voudrais garder une seule partition.
2 - conversion vers btrfs. apparemment ce fs est encore jeune, donc ma confiance reste limité. l'avantage semble être l'outil de conversion intégré, entre autre.
3 - passage en XFS ou JFS: je n'ai jamais utiliser ces fs, et je ne sais pas si il y a des outils de conversion fiables (FsTransform ?)
4 - il semblerai que sous le noyau 3.7, resize2fs prenne en charge le 64 bits, donc exit la limitation à 16To avec des blocs de 4k. reste à trouver des retours d'information.
5 - une solution pour convertir la taille des blocs (support des blocs de 1Mb depuis la 3.2, mais à la création du fs uniquement) de mon volume ext4 de 4k vers 8k ou plus, et ce sans perte de données...
6 - autre chose que je n'aurait pas envisager?

Par avance, je vous remercie de votre attention.

Cordialement,

zapan999

Hors ligne

#2 Le 14/04/2013, à 00:50

zapan999

Re : resize2fs >16To quel choix?

Bonsoir,

Je me permet un petit up, au cas où ...


Cordialement,

zapan999

Hors ligne

#3 Le 15/04/2013, à 14:18

guedz45

Re : resize2fs >16To quel choix?

Bonjour,

je ne sais pas si çà peut d'aider mais si j'étais à ta place je ferai de la manière suivante :

XFS pour le choix du FS
(je sais pas si tu es parti sur çà) mais mon volume actuel serait en LVM
J'ajouterai des disques pour créer un nouveau volume LVM en XFS
et je basculerai mes données du premier volume (ext4) au second volume (XFS) et avec LVM je ferai des resizes dès que nécessaire pour obtenir une bascule complète des données

Si pour des raisons x ou y tu ne veux pas jongler avec des données d'un coté ou de l'autre (pour un samba par ex) je monterai mon volume ext4 et xfs sur un montage en AUFS et je modifierai mon samba pour pointer vers le montage AUFS
comme çà en arrière boutique je déplace les données d'un volume à l'autre de manière transparente pour l'utilisateur

En espérant d'avoir un peu aider

Cordialement,
Guedz

Dernière modification par guedz45 (Le 15/04/2013, à 14:18)

Hors ligne

#4 Le 16/04/2013, à 08:07

zapan999

Re : resize2fs >16To quel choix?

Tout d'abord, merci de ta réponse Guedz!

La problématique, c'est que je n'ai pas encore commander le reste des disques. Sinon j'aurais pu faire le vase communicant entre le raid d'origine en ext4 et un nouveau raid en XFS.

Et éffectivement, je ne me serais pas basé sur les limites théoriques du ext4, j'aurais formater cette partition en XFS ou autres (mon second choix après le ext4 était bien le XFS hmm)

Pour le LVM, c'est (d'un point de vue personnel, et peut-être érroné) un intermédiaire supplémentaire non-nécéssaire, donc une cause de bug/perte de donnée supplémentaire. j'en vois l'intérêt si la "partition" final est composé de plusieurs grappes de raid, mais dans mon cas, il n'y aura qu'une seul grappe.
Il faut que je relise un peu des sujets sur le LVM voir ce qu'il pourrait m'apporter que je n'aurais pas vu...

Pour le AUFS, je ne connais pas.
D'après ce que tu en dis et notre sujet, ca serais une sorte de "multi-mountage" sur une seul point, donc le samba pointe sur le AUFS, qui lui pointe sur plusieurs sources (dans notre cas mon ext4 et la XFS, le temps du déplacement des données, ou pour éviter un LVM) je suppose?
je vais de ce pas ingurgiter des informations dessus wink

Merci encore pour ton temps, je vais étudier tout ça.

Cordialement,

zapan999

Hors ligne

#5 Le 18/04/2013, à 14:24

zapan999

Re : resize2fs >16To quel choix?

Bonjour,

après plusieurs jours de réflexion, je pense que je vais finir par m'orienter vers la piste conversion Btrfs.

En effet, après de multiples calculs, la conversion en "shrink" raid + partition source et "grow" raid et partition destination risque d'avoir un fort impact sur la durée de vie de mes disques (même s'ils sont garantis 3 ans...)

J'ai réussi à trouver différents posts sur le net parlant de personnes ayant sauter le pas de la conversion d'un raid mdadm en ext4 vers btrfs, et apparemment, ils n'ont pas rencontrer de problèmes.
Je pense me lancer ce soir, sinon d'ici ce weekend...

Je vous tiens au courant de l'évolution de la chose, si ca peux aider quelqu'un dans le futur...



Cordialement,

zapan999

Hors ligne

#6 Le 18/04/2013, à 15:53

Haleth

Re : resize2fs >16To quel choix?

Pour le LVM, c'est (d'un point de vue personnel, et peut-être érroné) un intermédiaire supplémentaire non-nécéssaire, donc une cause de bug/perte de donnée supplémentaire. j'en vois l'intérêt si la "partition" final est composé de plusieurs grappes de raid, mais dans mon cas, il n'y aura qu'une seul grappe.
Il faut que je relise un peu des sujets sur le LVM voir ce qu'il pourrait m'apporter que je n'aurais pas vu...

LVM n'est pas une surcouche, c'est plutôt une algorithme différent.
De fait, les performances sont clairement comparables à un accès "classique".

butterfs, j'espère que tu sais que c'est en béta et en dev intensif

Pourquoi ne pas utiliser ext4 ?

Debian Squeeze, e2fsprogs de chez Wheezy:

root@pvr2:~# uname -a
Linux pvr2 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012 x86_64 GNU/Linux
root@pvr2:~# dpkg -l | grep e2fsprogs
ii  e2fsprogs                           1.42.5-1.1                        ext2/ext3/ext4 file system utilities
ii  libuuid-perl                        0.02-4                            Perl extension for using UUID interfaces as defined in e2fsprogs
root@pvr2:~# parted /dev/sdb print list
Model: SMC SMC2108 (scsi)
Disk /dev/sdb: 18.0TB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  18.0TB  18.0TB  ext4         data

Ubuntu is an ancien African word which means "I can't configure Debian"

Because accessor & mutator are against encapsulation (one of OOP principles), good OOP-programmers do not use them. Obviously, procedural-devs do not. In fact, only ugly-devs are still using them.

Hors ligne

#7 Le 18/04/2013, à 18:49

zapan999

Re : resize2fs >16To quel choix?

Merci de ta réponse Haleth,

Pour Btrfs, oui, c'est même clairement indiqué sur leur wiki, et un peu partout. Cependant, même si on peux trouver quelques posts parlant de perte de données, ceux-ci semblent appartenir à des anciennes versions. Btrfs étant intégré a plusieurs distribution depuis un bout de temps, j'ose espérer que la partie fs est déjà bien clean, seul les parties raid5-6 semblent effectivement en pleine béta. C'est le fait de trouver plusieurs personnes ayant migrer pour cause de limitation du ext4 qui m'ont inciter à me lancer dedans.

Pour ce qui est de ta configuration de ta partition en ext4, quel est le blocksize utilisé?
Car je serai bien resté en ext4 si avec un blocksize de 4096 je n'était pas bloqué à la limite des 16To.

Je pense qu'il y a un gros delta entre nos deux configurations (lors de la création de la partition ext4?), car j'ai bien les même versions que toi

ii  e2fsprogs                                 1.42.5-1ubuntu2                           amd64        ext2/ext3/ext4 file system utilities
ii  libuuid-perl                              0.02-4ubuntu2                             amd64        Perl extension for using UUID interfaces as defined in e2fsprog

et il affiche un peu la même chose du coté de parted:

Model: Linux Software RAID Array (md)
Disk /dev/md0: 18.0TB
Sector size (logical/physical): 512B/4096B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  18.0TB  18.0TB  ext4

un df m'indique toutefois autre chose que 18To (15To et des poussières, mais la partition n'est plus monté, btrfs-convert travail...), et je t'assure que je me heurte bien au message de limitation du 32bits lors d'une tentative de resize2fs. (voir le résultat d'une tentative de resize2fs ici, qui a bien faillit finir en catastrophe hmm )

Hors ligne

#8 Le 18/04/2013, à 19:09

Haleth

Re : resize2fs >16To quel choix?

root@pvr2:~# tune2fs -l /dev/sdb1
tune2fs 1.42.5 (29-Jul-2012)
Filesystem volume name:   <none>
Last mounted on:          /data
Filesystem UUID:          019efd2f-4c09-4d0b-bf07-29cd2afb6016
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              274659328
Block count:              4394529280
Reserved block count:     219726464
Free blocks:              4377009648
Free inodes:              274659313
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
Flex block group size:    16
Filesystem created:       Mon Jan 28 14:25:10 2013
Last mount time:          Mon Jan 28 15:28:08 2013
Last write time:          Mon Jan 28 15:28:08 2013
Mount count:              3
Maximum mount count:      -1
Last checked:             Mon Jan 28 14:25:10 2013
Check interval:           0 (<none>)
Lifetime writes:          66 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      3a10f06f-8f77-44d0-b2e4-40eadd261c6f
Journal backup:           inode blocks

Es-tu sur d'avoir un truc comme ca (c'est le 64b qui est important):

root@pvr2:~# cat /etc/mke2fs.conf | grep fs_type -A 8
[fs_types]
	ext3 = {
		features = has_journal
	}
	ext4 = {
		features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
		auto_64-bit_support = 1
		inode_size = 256
	}

Ubuntu is an ancien African word which means "I can't configure Debian"

Because accessor & mutator are against encapsulation (one of OOP principles), good OOP-programmers do not use them. Obviously, procedural-devs do not. In fact, only ugly-devs are still using them.

Hors ligne

#9 Le 18/04/2013, à 19:17

zapan999

Re : resize2fs >16To quel choix?

oui, c'est ce que j'ai vérifier quand j'ai vu cette info sur le net...

        ext4 = {
                features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
                auto_64-bit_support = 1
                inode_size = 256
        }

Ceci est le résultat de mon ubuntu 64, installé suite au problème de limitation du 32bits.
Pour la petite histoire (voir premier sujet sur ma petite histoire wink ), le ubuntu ou à été crée cette partition était une version 32bits. c'est pourquoi je pense que la création de nos partitions est bien différente (une partition crée en 32bits ne peux *apparemment* prendre le support 64 bits hmm)

Cordialement,

zapan999

Hors ligne

#10 Le 18/04/2013, à 19:18

Haleth

Re : resize2fs >16To quel choix?

Hum, dommage pour toi smile
Je pense que c'est la raison.


Ubuntu is an ancien African word which means "I can't configure Debian"

Because accessor & mutator are against encapsulation (one of OOP principles), good OOP-programmers do not use them. Obviously, procedural-devs do not. In fact, only ugly-devs are still using them.

Hors ligne

#11 Le 18/04/2013, à 19:29

zapan999

Re : resize2fs >16To quel choix?

oui, la prochaine fois, je passerais direct sur le 64^^

Mais j'ai toujours été méfiant des changements, donc j'ai préférer rester sur mon ubuntu existant... hmm

enfin, je pense que la première partie de mon passage sur btrfs (le convert) devrait prendre entre 30 et 60 heures (d'après les quelques exemples vu sur le net, mais bon trop de paramètres à prendre en compte...), donc je repasserais pour vous donner des news sur le sujet!

Sinon, tu utilise quoi comme carte pour ton raid matériel (j'ai dut lâcher ma bonne vieille LSI/intel sasu8 et une dell perc 6/i de backup une fois que j'ai constater que celles-ci ne supportaient pas de disques de plus de 2.2To.
Donc j'ai pris une IBM M1015,  que j'ai reflashée (d'ailleurs pas mal de misère ici aussi, le soft de reflash ne détecte pas la carte sur toutes les cartes mères!)

Hors ligne

#12 Le 18/04/2013, à 19:33

Haleth

Re : resize2fs >16To quel choix?

Ce semble être un truc comme ca

Fonctionne bien pour l'instant, installation un peu délirante (via une interface psychotrope, du genre internet explorer wrapper par le bios .. immonde);

Dernière modification par Haleth (Le 18/04/2013, à 19:34)


Ubuntu is an ancien African word which means "I can't configure Debian"

Because accessor & mutator are against encapsulation (one of OOP principles), good OOP-programmers do not use them. Obviously, procedural-devs do not. In fact, only ugly-devs are still using them.

Hors ligne

#13 Le 19/04/2013, à 06:49

zapan999

Re : resize2fs >16To quel choix?

Ah pas mal comme carte. 8 port sas ca fait du 32 disques sata, sans expander.
Mais bon j'arrête de rêver, mon boitier ne va pas jusque là... (Norco 4020)

Bon sinon, ca mouline toujours ce matin... wink

Hors ligne

#14 Le 20/04/2013, à 07:34

zapan999

Re : resize2fs >16To quel choix?

ça mouline encore et toujours...

zapan@UBUNTU-SERVER:~$ ps auxw | grep btrfs
root      3134  0.0  0.0  62204  1824 pts/2    S+   Apr18   0:00 sudo btrfs-convert /dev/md0
root      3135 77.4 22.0 878032 866096 pts/2   R+   Apr18 1776:27 btrfs-convert /dev/md0
zapan     7909  0.0  0.0  13580   940 pts/4    S+   07:45   0:00 grep --color=auto btrfs

1776 minutes, soit presque 30 heures (29.6)


Si on peux extrapoler un peu sur la relation accès disk <=> avancement de la conversion:

zapan@UBUNTU-SERVER:~$ iostat -k
Linux 3.7.9-030709-generic (UBUNTU-SERVER)      04/20/2013      _x86_64_        (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          38.11    0.01    3.16   44.17    0.00   14.55

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               5.59       488.94       395.25   68039127   55001888
sdb               0.00         0.02         0.00       2426          0
sdc             130.88      8941.38       350.31 1244256466   48748336
sdf             123.08      8887.48       296.84 1236755406   41307368
sde             127.40      8936.49       347.71 1243575418   48385644
sdd             129.31      8922.79       332.97 1241668539   46335800
sdh               0.00         0.01         0.00       1246          2
sdi             125.47      8914.72       325.71 1240546650   45325100
sdg             122.97      8893.11       304.06 1237539518   42312416
sdj             127.09      8916.29       326.27 1240764866   45403188
md0           15351.41     60202.81      1202.84 8377646333  167383832

On arriverai à 7.8Tb (8377646333 kB) de données lues pour 0.16Tb (167383832 kB) de données écrites (nouveau fs je suppose)

Sachant que j'avais grosso-modo 15Tb de données, j'en suis à la moitié du chemin en 30 Heures... wink


@ dans 30 heures environ!

zapan999

Hors ligne

#15 Le 23/04/2013, à 18:17

zapan999

Re : resize2fs >16To quel choix?

bon, conversion terminé à 16h environ, soit 5 jours complets. (~120h)

je vous post les détails ci-dessous, si ça peux aider à chiffrer des estimation de temps de conversion pour les futur intéressés:



30 secondes pour mount la partition, puis un petit df:

Filesystem       1K-blocks        Used  Available Use% Mounted on
/dev/md0       14651302400 12652447828 1329469628  91% /mnt/raid0

Bon, on active la compression, histoire de rigoler wink (et on le colle aussi dans le fstab, hein!)

mount -o remount,compress /dev/md0 /mnt/raid0

nano /etc/fstab
/dev/md0        /mnt/raid0      btrfs   defaults,compress       0       1

le resize => max:

btrfs filesystem resize max /mnt/raid0

13 minutes après, un df:

Filesystem       1K-blocks        Used  Available Use% Mounted on
/dev/md0       17581562880 12656028104 4256166664  75% /mnt/raid0

un "df sous btrfs", pour voir l'utilisation de l'espace dans la partition:

btrfs filesystem df /mnt/raid0
Data: total=9.10TB, used=7.86TB
System: total=32.00MB, used=700.00KB
Metadata: total=4.55TB, used=3.92TB

un petit bench rapide (archivage sans compression du contenu d'un BR PS3 de 11.9Gb: (sous ext4, il m'avait donné 2m74.425s)

for f in */; do time tar -caf "${f%/}.tar" "$f"; done   
real    2m23.022s
user    0m0.364s
sys     0m16.988s

Donc un gain en btrfs compressé! cool! faut que je compare sans compression btrfs, et en créant des archives compressés... quand j'aurais le temp)

voyons si on compare les btrfs filesystem df /mnt/raid0 avant et après la création de ce tar de 11.9Gb (pour estimer la compression btrfs...)

avant:

Data: total=9.10TB, used=7.86TB
System: total=32.00MB, used=700.00KB
Metadata: total=4.55TB, used=3.92TB

après:

Data: total=9.10TB, used=7.87TB
System: total=32.00MB, used=700.00KB
Metadata: total=4.55TB, used=3.92TB

bon rien de visible, il faudrait afficher dans une unité plus petite, ou en compresser plus.... (je vais en compresser plus...)

voyons si on archive 100Gb, voir si on vois une différence entre les df...

je vous dis ca au prochain post...

Hors ligne

#16 Le 23/04/2013, à 19:09

zapan999

Re : resize2fs >16To quel choix?

Bon.... on reviens sur l'option de compression...

je me suis amuser à faire des tests, mais je tombais toujours à un ratio de compression de 0, donc pas de compression.....

je viens d'utiliser l'option compress-force, et là, ça marche.


Voici la méthode de test pour voir si la compression est ok:
on crée un fichier de 100Gb, composé de zéro, donc compression proche de 100%

dd if=/dev/zero of=/mnt/raid0/Consoles/PS3/JEUX/test/bigfile bs=1024 count=102400000

avec un mount -o compress, avec ou sans remount, pas de compression, je voyais  les Gb sauter à la vitesse de l'éclair...


mais avec un compress-force, là j'ai bien le même résultat, avec ou sans le fichier de 100Gb

Data: total=9.10TB, used=7.96TB
System: total=32.00MB, used=700.00KB
Metadata: total=4.55TB, used=3.92TB

(pour la petite comparaison, je tourne à 133Mb/s sans la compression, 215Mb/s avec...)



Avec un peu de lecture à droite à gauche, il semblerais que :

Compression doesn't work / poor compression ratios
First of all make sure you have passed "compress" mount option in fstab or mount command. If yes, and ratios are unsatisfactory, then you might try "compress-force" option. This way you make the btrfs to compress everything. The reason why "compress" ratios are so low is because btrfs very easily backs out of compress decision. (Probably not to waste too much CPU time on bad compressing data).

Zut, moi j'aurais préférer qu'il soit moins tatillon sur la décision de compression... hmm



Bon tout ça pour dire que mes premières heures de btrfs me satisfont, je voulais en priorité dépasser la barrière des 16Tb imposé par mon system, c'est chose faite. La suppression du backup ext4 se fera dans un certain temps.

et ah oui, faut que je refasse un test de compression du rep de 11.9Gb, car le gain de temps est donc apparemment sans l'option de compression active...

Hors ligne

#17 Le 23/04/2013, à 19:44

Haleth

Re : resize2fs >16To quel choix?

C'est interessant;
Sur des données type multimedia, tu n'auras, j'imagine, qu'un taux de compression < 2%. Mais sur des fichiers textes, j'pense que le gain est visible.

Hésite pas à venir en dire plus si y'a des trucs cool que tu trouves, et des problèmes smile

D'avance, merci


Ubuntu is an ancien African word which means "I can't configure Debian"

Because accessor & mutator are against encapsulation (one of OOP principles), good OOP-programmers do not use them. Obviously, procedural-devs do not. In fact, only ugly-devs are still using them.

Hors ligne

#18 Le 23/04/2013, à 20:27

zapan999

Re : resize2fs >16To quel choix?

Bonsoir Haleth.

Oui, les fichiers dont le contenu est déjà compressé logiciellement (vidéo, audio, archives compressés, images, ...) sont inintéressants pour la compression btrfs hélas.... mais pour le reste (iso, archives non compressées, textes, images bmp, fichiers de données non compressés en général..... ), l'intérêt est tout autre!

et oui, je vais continuer a fouiller^^

cordialement,
zapan999

Hors ligne

#19 Le 24/04/2013, à 07:40

Hoper

Re : resize2fs >16To quel choix?

Pour le LVM, c'est (d'un point de vue personnel, et peut-être érroné) un intermédiaire supplémentaire non-nécéssaire, donc une cause de bug/perte de donnée supplémentaire.

Effectivement, tu n'a pas saisi l'un des avantage majeur de LVM.

Oui, c'est une couche supplémentaire mais sans impact sur les performances, et c'est une couche d'une EXTREME fiabilité (nettement supérieur à mdadm dans mon expérience par exemple, alors que je considère le raid logiciel de linux comme une couche déjà très fiable).

LVM ne sert pas du tout qu'a aggréger différents volumes. C'est un usage possible, mais la plupart des utilisateurs de LVM l'utilise pour l'inverse, le découpage. Car, comme tu viens de t'en apercevoir, avoir des FS de taille trop importantes peut poser beaucoup de problèmes.

Sérieusement, ne le prend pas mal mais un FS de 16 To aujourd'hui, c'est de la folie. Tant mieux si tu n'a toujours rien perdu, je te souhaite que cela reste le cas bien sur. Je ne connais pas encore btrfs, mais imagine le temps qu'il faudrait pour faire un fsck sur 16 To de données en ext3... C'est juste pas possible en production (surtout que pendant le fsck les données ne sont pas accessibles).

Et puis, si jamais il y a un problème, (bug, corruption de FS, soucis matériel ce qui ne devrait pas etre ton cas en raid, mais imagine un disque dur unique de 4 To etc), c'est tout le FS qui risque de partir en fumée. Alors que si tu découpe ta volumétrie en plusieurs FS, Le même bug ne causera la perte que d'une partie de tes données. Les fsck seront beaucoup plus rapides etc.

Il y a très peu de cas ou tu as besoin d'un seul FS avec une volmétrie énorme. En général, tu peux parfaitement découper en plusieurs FS. Découpage par usage, par type de fichiers hébergés (ce qui permets d'utiliser des FS différents, ou paramétrés de façon différentes (nb d'inode etc). Mettre des vidéos en XFS et des jpg en ext4 ou reiserfs etc.

Et non, tu ne "perd" pas de place à découper. D’abord parce que "découper" ca ne veut pas dire faire 20 FS qu lieu d'un, il y a un juste millieu à trouver, ensuite parce que justement LVM te permet très facilement d'adapter l'espace réservé à tel ou tel FS. De plus, comme tu ajoute de l'a volumétrie au fur et à mesure, en fonction des besoins, chaque ajout (resize2fs) ne prend que très peu de temps...


Mes tutos et coups de gueule :
http://hoper.dnsalias.net/atdc/
Mastodon: @hoper@framapiaf.org

Hors ligne

#20 Le 24/04/2013, à 08:07

Haleth

Re : resize2fs >16To quel choix?

C'est sur que des gros FS, c'est pas toujours une bonne idée smile
Chez nous par exemple, nous avons un FS de 18To, pour stocker les flux TV .. pas le choix donc, à moins de gérer plusieurs FS au niveau soft (ca sucks)

M'enfin, quant à la protection des données, raid oblige smile


Ubuntu is an ancien African word which means "I can't configure Debian"

Because accessor & mutator are against encapsulation (one of OOP principles), good OOP-programmers do not use them. Obviously, procedural-devs do not. In fact, only ugly-devs are still using them.

Hors ligne

#21 Le 24/04/2013, à 08:48

zapan999

Re : resize2fs >16To quel choix?

Bonjour,

Effectivement, je n'avais pas vu le LVM sous cet angle (découpage) et en effet, c'est loin d'être bête.

C'est ce que j'avais fait à une époque sur windows 2k, et le fait de jongler entre les différents volumes alloués, ou retailler les volumes avaient finit par user de ma patience. mais je pense que LVM est bien plus rapide et plus sûr. même si chaque opération de resize2fs engendre un risque de corruption, voir perte total du volume.

Un effet négatif serai par contre que l'espace occupé par les informations des FS serait plus grand (mais dans quelle mesure.... à mon avis, négligeable)


Je vous rassure, il s'agit là d'un serveur personnel, sinon je ne me permettrai pas une conversion de FS à la volée sans un backup complet!


par contre, il me semble que l'effacement est plus long sur btrfs que sur ext4...

Hors ligne

#22 Le 24/04/2013, à 10:12

Hoper

Re : resize2fs >16To quel choix?

Un effet négatif serai par contre que l'espace occupé par les informations des FS serait plus grand (mais dans quelle mesure.... à mon avis, négligeable)

Les méta data de LVM prennent un peu de place. Je ne peux pas forcément te donner de valeurs précises sur le sujet, mais ça se compte facilement en Mo, voir en dizaines de Mo (pas en centaines quand même). Cela dit, cela reste négligeable sur des volumétries de plusieurs To, surtout en comparaison des services rendus.

La modification de la taille est fiable à 100% dans le cas d'un agrandissement. Dans le cas d'un rétrécissement, c'est l'erreur humaine qu'il faut éviter à tout prix (erreur qui, oui, peut facilement causer une perte de donnée). Je n'ai jamais eu de soucis (et j'ai fait ce genre d'opérations un bon paquet de fois). Mais oui, réduire un FS fait toujours plus peur que de l'agrandir. C'est pour ça que, avec LVM, la bonne stratégie est de conserver pas mal d'espace libre, et de l'attribuer en fonction des besoins (sans pour autant tomber dans l'excès, en taillant initialement les FS au plus juste et en ajoutant de très petite quantité d'espace à chaque fois, ce qui sera vraiment pas top d'un point de vue performance). Par expérience, il faut absolument éviter des FS (même gros) plein à plus de 90%.

Pour btrfs, j'ai passé toute la matinée à lire de la doc technique sur le sujet (cela fait un moment que je voulais le faire, ton sujet m'a fourni un bon pretexte pour me lancer). Je suis assez dubitatif à son sujet...

Ca peut etre bien pour quelqu'un qui n'a aucune compétence sur mdadm et lvm. Cela simplifie un peu les choses, mais cela reste TRES limité par rapport à l'utilisation "normale" de mdadm, puis lvm au dessus, puis un FS standard. Beaucoup de choses manquent à l'appel (raid5, raid6, chiffrement des données, transparence en cas de crash d'un disque etc).

Je pense que j'écrirai un petit billet sur le sujet quand j'aurai un peu plus de temps smile


Mes tutos et coups de gueule :
http://hoper.dnsalias.net/atdc/
Mastodon: @hoper@framapiaf.org

Hors ligne

#23 Le 24/04/2013, à 11:07

zapan999

Re : resize2fs >16To quel choix?

Concernant le resize en growing, je t'assure que moi j'ai eut une belle surprise (d'ailleurs à l'origine de ma recherche de solution de dépassement des 16To).

Sinon moi aussi, la doc du btrfs n'est pour moi pas convaincante. mais après quelques lectures sur le net, je pense que même s'il n'est pas encore finit (partie raid, entre autres), la partie fs pur est apparemment pas mal.

Concernant ta dernière remarque, oui pour le manque de compétence (j'aurais plutôt dit connaissance/utilisations) sur LVM, la partie mdadm n'a pour moi rien à voir dans mon cas (le growing s'est passé sans problème, et je savais très bien ou j'étais et ou j'allais sur la partie raid logiciel).

Pour LVM, je lis bien qu'il est très fiable, je n'en doute pas. Mais faire du vase communicant pour balancer les données de mon raid + ext4 vers une nouvelle partition sur un nouveau raid au fur-et-à-mesure que la première partition/raid se mange des shrink pour que la nouvelle partition/raid fait des grow, ca aurait été un peu stressant pour les disques je pense. (voir mon explication sur un précédent post.)

Je ne pense pas échanger mon baril de mdadm contre deux baril de raid géré par btrfs avant bien longtemps, mais je continuerai de suivre l'avancement de ce fs, et de partager mes impressions personnelles dessus wink

Pour le moment, je vais me concentrer sur les différences d'accès en lecture/écriture, avec ou sans compression, et de voir comment la compression opère (décisons du fs, taux réel en fonction du type de fichier, impact sur la performance, qui sont apparemment positives)

Hors ligne

#24 Le 24/04/2013, à 11:24

Hoper

Re : resize2fs >16To quel choix?

et de partager mes impressions personnelles dessus

Des retours d’expérience que je lirais avec plaisir smile

Et oui, pour tes précédentes remarques, LVM est un choix à faire au départ. Après, sa mise en place est beaucoup plus compliquée.


Mes tutos et coups de gueule :
http://hoper.dnsalias.net/atdc/
Mastodon: @hoper@framapiaf.org

Hors ligne

#25 Le 26/04/2013, à 19:13

zapan999

Re : resize2fs >16To quel choix?

Bon, déjà premières leçons apprises:

si comme moi vous avez ça:

btrfs filesystem df /mnt/raid0
Data: total=9.10TB, used=7.86TB
System: total=32.00MB, used=700.00KB
Metadata: total=4.55TB, used=3.92TB

sur un volume comme ca:

btrfs fi show
Label: none  uuid: f4f04e16-ce38-4a57-8434-67562a0790bd
        Total devices 1 FS bytes used 11.31TB
        devid    1 size 16.37TB used 11.58TB path /dev/md0

Btrfs Btrfs v0.19

C'est à dire 4.55Tb de réservés (dont 3.92 utilisés) pour les metadata (en gros, y'a de quoi s'en peindre une en bleu, ou se la mordre...), utilisez le balancing des metadata!:

btrfs fi balance start -musage=10 /mnt/raid0
Done, had to relocate 17 out of 5679 chunks
btrfs fi balance start -musage=50 /mnt/raid0
Done, had to relocate 49 out of 5662 chunks
btrfs fi balance start -musage=80 /mnt/raid0
Done, had to relocate 256 out of 5613 chunks
btrfs fi balance start -musage=80 /mnt/raid0
Done, had to relocate 34 out of 5364 chunks
btrfs fi balance start -musage=90 /mnt/raid0
Done, had to relocate 870 out of 5338 chunks
btrfs fi balance start -musage=95 /mnt/raid0
Done, had to relocate 1059 out of 4897 chunks

vous arriverez à ça: (bon en groupant aussi quelques 700.000 fichiers en une 50aines d'archives non compressés, parce que ça fait beaucoup de metadata pour rien aussi...)

btrfs fi df /mnt/raid0/
Data: total=9.65TB, used=9.62TB
System: total=32.00MB, used=744.00KB
Metadata: total=1.94TB, used=1.69TB

1.94Tb, soit 2.5Tb de gagnés (grosso modo plus de 1.5~2Tb juste avec le balancing, le reste avec la diminution du nombre de répertoires)
Chose étrange, les derniers balance exécutés ont fait baisser les métadata, mais monter le volume de données... J'ai repenser au fait que j'avais lu que depuis quelques versions, les blocs pouvaient êtres mixtes (meta+data), ceci explique cela...


Voyons plus en détail la commande:

btrfs fi balance start -musage=90 /mnt/raid0

btrfs fi balance: on lance un balancing, qui équivaut à redispatcher (réécrire) les blocs. Dans notre cas (partition btrfs normal, car raid sous mdadm), elle sert surtout à faire un pseudo défrag et optimiser le remplissage des blocs)
(fi est équivalent a filesystem)
start: pour indiquer qu'on lance un blancing. on peux aussi "Pause", "Resume", "Cancel", mais surtout "Show"(voir plus loin pour cette derniere):
-m (filtre de type de blocs: -m pour metadata seulement. ou -d pour data, -s pour system)
usage=xx (collé au filtre précédent) on ne traite que les blocs remplis à moins de xx%



Les balancing de metadata peuvent êtres plus ou moins longs (20 minutes pour une valeur de 5%, jusque 6 heures pour le dernier round à 95%...), donc pour savoir ou ça en est, on ouvre un autre terminal, et on utilise la commande show:

btrfs fi balance status /mnt/raid0
Balance on '/mnt/raid0' is running
130 out of about 1067 chunks balanced (472 considered),  88% left




En résumé:

Si vous devez convertir une partition de donnés:

  1. diminuez le nombre de fichiers: des fichiers de vieux backup et autres, les archiver sans compression (.tar) est une action rapide et facile. Ne faites pas comme moi, faites le AVANT.

  2. Faites des balancing des metadata juste après la conversion, en commençant par 5%, pour terminer entre 80 et 95%

  3. envoyez-moi vos disques WD red 3To...ils seront cajolés lol



Cordialement,
zapan999

Hors ligne