Reprise du message précédent :
ça pourrait être intéressant oui.
Faudrait voir ça dans le topic unique Serveurs@home plus approprié qu'ici.

bonjour a tous,
 
j'ai l'intention de me faire un NAS ( +serveur de plein de choses...) avant la fin du mois
 
je pense me prendre un disque systeme 2.5 pouce + 2 * 1To raid0 en 3.5 pour les data
surement avec une zotac G43 ITX ( j'ai deja un core2duo qui traine).
 
Pour l'instant , je me tatte sur le boitier.
Je voudrais pas un boitier trop grand , meme quand meme pouvoir y mettre 3 DD
Le seul que j'ai trouvé, c'est le antec NSK1380  http://www.materiel.net/ctl/Mini_b [...] K1380.html , cher mais avec une alim
 
Quels autres boitiers pourrais faire le boulot ?

mais pourquoi du raid 0 encore ??
 
vous aimez le risque tous ce que vous etes ou bien?

Est ce que par hasard quelqu'un à sous le coude un comparatif sérieux sur les consos et perfs des différents couples Chipsets/proco ?

Pour les procs: http://www.hardware.fr/articles/77 [...] l-amd.html

la vache, y-a du monde! Dommage, il manque juste les atoms!

Bon, NAS remonté.
 
Va falloir que j'update ma configuration dans mon profil du coup.
 
Ma config est un peu plus bruyante qu'avant. Le PC-Q08 laisse passer les bruits de ventilation, et le boitier est un peu trop léger pour pouvoir atténuer correctement les vibrations de 5 disques. Mais en pratique, ca reste très bas. Je pense que ce que j'entends le plus est le ventilo de mon ventirad, qui tourne a ~700 tours/minute.  
 
Donc, 750 Go en disque principal + 4*1 To WD Green, en raid5 soft avec mdadm, carte mère mini ITX Zotac G43, 2 Go Ram, et boitier Li PC-Q08 silver.
 
Le tout tournant sous Debian.
 
Alors, mes remarques. Perte de perfs brutes due au changement de carte mère, et j'ai du refaire une grosse partie du tuning de mon RAID. En pratique les débits sont toujours à la hauteur de ce que j'espérais (~108 Mo/s en lecture, ~140 Mo/s en écriture).
 
Les optimisations passées au niveau du raid : Elles sont faites via un script lancé au boot :
 
blockdev --setra 8192 /dev/md0
blockdev --setra 8192 /dev/mapper/vg_raid-lv_raid
echo 8192 > /sys/block/md0/md/stripe_cache_size
 
 
Les deux premières commandes me permettent d'aligner le readahead de mon volume raid brut, et de mon LV (ma partition logique) a 8192 ko. Selon le matériel cela peut offrir un gain, sur ma config cela seul ne change rien (débit en lecture a 108 Mo/s en lecture avec la valeur par défaut a 768 et la valeur modifiée). Mais cela prépare une deuxième amélioration.
 
Seconde commande qui augmente le stripe_cache_size, ce qui peut améliorer les perfs en écriture. Ici, j'ai un gain de 10-15%. Pas énorme mais ca reste appréciable.
 
Premier test, je relance un transfert samba, et la c'est le drame, avec une moyenne a ~36 Mo/s.
 
Du coup dans les paramètres du fichier de configuration /etc/samba/smb.conf, j'active les options suivantes:
SO_RCVBUF=8192 SO_SNDBUF=8192
 
Cela ajuste les buffers en émission, et en réception a 8192ko (d'ou mes 2 premiers paramétrages sur le readahead, pour m'aligner sur cette valeur).
Relance du serveur samba, et transfert du même fichier (taille 4 Go, pour éviter que le cache disque fausse les résultats) => Transferts compris entre 72 Mo/s au plus bas, et 102 Mo/s au plus haut.
 
C'est mieux
 
Il me reste a repasser plus tard dans le BIOS de la carte mère pour vérifier le paramétrage, j'ai pas encore vu comment réactiver les options d'économie d'énergie (EIST et cie).

pas mal du tout ca

As tu mesuré la conso de l'ensemble ?

J'ai pas le matos adéquat malheureusement.
 
Edit - Mais j'ai un onduleur, je vais regarder si je peux pas obtenir les stats de conso de la prise.

non désolé , je voulais dire raid1, justement je veux les garder mes données !!    
 
 

 
Pourquoi utiliser un raid "completement" logiciel ?
Le chipset de ta carte te permet de faire du raid 5 aussi, pourquoi avoir choisi mdadm ?  
 
 

avec chipset :
si sa carte lache et qu'il retrouve pas la meme, son raid est potentiellement perdu.
 
avec mdadm :  
si sa carte la et qu'il retrouve pas la meme, il fout son raid dans un linux, remonte le tout et retrouve ses données.
 
je simplifie hein

Exact. J'aurais simplement pas pu changer de carte mère et conserver mon RAID si j'avais pas opté pour Mdadm.
 
Rajoutes le fait que mdadm t'offre une souplesse quasiment inégalée (rajouter ou supprimer des disques dans l'array a chaud, modifier ton type de RAID, agrandir ou diminuer ton RAID), ce que tu ne trouveras pas dans du raid semi soft (raid du chipset) ou du raid 100% hardware a moins de plusieurs centaines d'euros.
 
Avec en plus la config basée sur les UID des disques, je peux les débrancher / rebrancher a la sauvage sur n'importe quel port de la carte mère et mdadm retrouve ses petits.
 
Ah, et je viens de retrouver comment réactiver l'économie d'énergie : c'est le package cpufrequtils.
 
Voici ce que ca me donne :
 
current CPU frequency is 1.20 GHz (asserted by call to hardware).
  cpufreq stats: 2.00 GHz:1.57%, 1.60 GHz:0.19%, 1.20 GHz:98.24%  (2402)

@ edouard saucisse et ccp6128
 
ok, ca c'est de l'argumentation.
J'ai jamais utilisé les raid intégré des cartes meres. je savais que c'était un peu du "tout pourri" mais pas à ce point la.
 
par contre, moi qui avait l'intention de jouer avec plusieurs système entre autre, raid logiciel, ca va etre juste galere d'une maniere generale...  

non, c'est juste que ca fait un peu peur quand on connait pas, mais une fois qu'on a pris le temps de potasser un peu de doc, ca passe tout seul

Le Raid et le multi OS a la base, c'est pas super facile. Parce que pour avoir des perfs correctes, il faut un FS qui suive.
 
Soit du NTFS sous Windows, mais c'est pas un bon FS pour des Unix like.
Soit un système journalisé Linux, genre Reiserfs / XFS, sous du Linux => Windows n'aime pas
Soit du Zfs (SunOs, BSD, ou Linux via Fuse) => Windows n'aime pas
 
Ne parlons pas du FAT32, ce serait une hérésie sur un volume de plusieurs To.
 
Le choix du type de RAID (logiciel ou matériel) est surtout déterminé par tes besoins en termes de performances, ton budget, et les fonctionnalités que tu veux obtenir. Mais passé ce choix tu restes toujours tributaire d'une plate forme logicielle.

 
 
si tu veux jouer avec plusieurs OS, pas de soucis...
 
mais pas sur le NAS
 
ton nas est sous UN seul OS, il a UN raid, et il partage son raid via ftp/nfs/samba... vers d'autres machines.
 
et avec tes autres machines tu peux switcher les OS comme tu le sens, pas de soucis.

tu peux en dire plus sur cette histoire de UID, ça m'interesse.
 
ta monté quoi comme FS sur ton raid ?
 
ta rajoute d'autres modifs dans ton fstab ou ta juste les options de ton script au demarrage ??

Les UUID, c'est ce qui remplace sur toutes les maj récentes des distribs les liens vers le /dev des disques. Par exemple, voici mon fstab :
 
UUID=7a50217d-0a06-403f-b45d-9c4c9a3de8d6       /               reiserfs notail          0       1
UUID=065cb65e-6eb9-4c35-beb2-ef1c23374e73       none            swap    sw              0       0
UUID=a55c36b5-d5db-40de-8046-6ad81fc6dca0       /data/normal    reiserfs       defaults 0       0
/dev/vg_raid/lv_raid    /data/raid      reiserfs        defaults        0      0
 
L'UUID est un identifiant unique généré lors de la création d'un filesystem. L'avantage, comme je l'ai déjà indiqué plus haut, c'est que tu supprimes totalement la dépendance au branchement physique de tes périphériques. Tu peux l'obtenir pour chaque disque via la commande blkid /dev/tondevice
 
Ce n'est pas nécessaire si tu fais du LVM vu que LVM se base déja sur l'UUID pour détecter tes disques (d'ou le fait que mon volume raid se base toujours sur le /dev ).
 
Ma config s'oriente autour d'un raid5 via mdadm + LVM + reiserfs
 
J'ai choisi ce fs un peu par conservatisme (je n'aime pas l'ext3 sur de gros volumes a cause des fsck de 3 plombes et j'ai eu de mauvaises expériences à la tenue au shutdown brutal, et ext4 est toujours en pleine évolution et n'offre pas de gros changements. J'avais donc le choix entre du Reiser, jfs ou XFS. Vu que je connais bien Reiser et qu'il satisfait mes besoins, j'ai pas été chercher plus loin).
 
Pas d'optimisation particulière au niveau du fstab, vu que le ReiserFs n'offre pas tant d'optimisations disponibles que ca (que des trucs vraiment spécifiques pour des applis).
 
Etant donné que c'est un NAS a usage mixte, j'ai pas voulu orienter les perfs dans un sens en particulier.
 
La plupart des optimisations que j'ai faites portent sur les caches disque et les buffers des applis que j'utilise, et c'est le truc qui apporte le plus de gains avec le moins d'efforts et de tests. Je pourrais gratter encore un peu en allant chercher au niveau kernel (les schedulers et cie), mais ca fait surtout la différence en usage très soutenu.

Ah, et correction, le readahead ca concerne des blocs de 512o, donc 8192 ca fait un readahead a 4Mo.

Bonjour,
 
Je suis en train de tester mon NAs avec UN disque dur IDE.
 
Mais le taux de copie est de 6Mo/Sec sous windows 7.
 
Je trouve ca tres bas.  
 
es que c'est parce que je suis en IDE ? si je suis en Sata ca ira plus vite ou non ?
 
Merci de vos reponses
 
Si vous pouviez donner vos taux de transferts

C'est pas spécialement lié a l'IDE, enfin sauf si c'est un disque qui est vraiment vraiment vieux.
 
Tu pourrais détailler la config du NAS (config matérielle et logicielle) ?

oula  
 
756Mo de ram marque no name  
Alton 64  double coeur 2.2Ghz
Carte mere no-name
carte réseau : Dlink DFE-528TX FASt ethernet
 
un DD IDE 40Go WD
 
Voila  
 
Le NAS est relié a la liveBOx en ethernet et mon PC est relié a la box en RJ45 Par des CPL
 
 
FreeNAS :   0.7.2 Sabanda (revision 5266)

Humm. Y'a pas de raison que tu puisses pas saturer de l'ethernet avec une config pareille (donc au moins du 12Mo/s).
 
Tes CPL, c'est quoi comme modèles ?
 
Si sur ton pc sous 7 tu as un firewall additionnel, teste en le désactivant temporairement.
 
Teste également via un autre protocole, par exemple du FTP, voir si c'est pas un souci au niveau de samba.
 
Ensuite si ca ne résout pas le souci, regarde du côté de FreeNas voir si tu as des courbes de taux CPU pendant les transfert. Si le CPU de ton nas est haut pendant les transferts, le disque peut être en PIO au lieu de DMA, ou alors carte réseau un peu foireuse qui bouffe plein de CPU.

en Ftp je suis a 8mo/s
 
J'ai pas de parefeu windows il est desactivé.
 
Quand je transfert le Cpu monte a 8%  9 % voir 15 % mais jamais au dessus de 25%
 
Edit mes CPL sont des Plug D'orange HD liveplug.

Reste à voir si c'est pas une limitation au niveau des CPL alors.

A Attend j'ai un message d'erreur qui défile :  
 
kernel: ad1: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=38061506
Aug 18 16:53:57  freenas  kernel: ad1: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=38061506
Aug 18 16:53:57  freenas  kernel: ad1: FAILURE - READ_DMA status=51<READY,DSC,ERROR> error=84<ICRC,ABORTED> LBA=38061506
Aug 18 16:53:57  freenas  kernel: g_vfs_done():ad1p1[READ(offset=19487473664, length=65536)]error = 5
 
j'ai tester en Wifi je suis a 3Mo/sec max

Souci hardware, soit ta nappe IDE est un peu foireuse, soit ton disque a des secteurs défectueux.
 
Avant de se préoccuper du débit, il faudrait corriger ce problème, parce que ca t'expose a des dysfonctionnements / perte ou corruption de données.

Ok j'en m'ais un autre mais maintenant je peux pas faire de poitns de montages :  
 
il me met :
 
 Les erreurs suivantes ont été détectées:
Type de partition ou numéro de partition erroné
 
Tu as une Idée.

ouais puis pour un vrai test, evite le wifi et le CPL, un bon fil y a que ça de vrai!!
 
 
ccp6128 : moi j'ai un petit script pour desactiver le cache des disques avec hdparm au demarrage, pr eviter des soucis avec la journalisation sur le FS XFS.
apres j'ai des optimisations au niveau du fstab mais c'est pour de l'ext4 donc normal que tu n'en n'ai pas toi.
je vais voir pr passer mon fstab avec les UUID c'est tres interessant comme option.

Je ne dépasse jamais les 8-9Mo/s en Ethernet 100, depuis un Linux ou vindoze (XP, Vista ou 7) vers un NAS sous Ubuntu 10.04 Server (Samba ou NFS). Je pense que le blocage en débit doit être lié aux box (Free chez moi).
Je compte tester le gigabit sous peu.

9mo/s ca fait du 72mbps
c'est pas si mal

A oui Vous trouvez ca bien.  
 
ba je trouve pas ca bien moi je trouve ca lent. Une  clé usb va plus vite

pour de l'Ethernet 100mbps c'est pas si mal

en ethernet 100Mbs, si tu fais 10 ou 11 Mo/s c'est le grand maxi...

Bon, en ce qui concerne la sauvegarde à distance cryptée et sécurisée, j'ai trouvée une solution enfantine: duplicity !
 
mode d'emploi:
duplicity --encrypt-key=ID_clef_GPG /dossier/à/backuper ftp://user:pass@ftp.serveur.distant
 
La première fois ca fait un full backup, puis les fois suivantes, des sauvegardes incrémentales.
tout çà est crypté avec GPG, il faut donc avoir préalablement crée une clef.
 
En cas de problème, pour restorer , on fait tout simplement:
duplicity ftp://user:pass@ftp.serveur.distant  /chemin/dossier/à/backuper
 
Si on veut sécuriser le transfert, on peut sauvegarder sur scp au lieu de ftp.
 
Il reste plus qu'à faire des tests ur des gros volumes pour voir si les débits sont potables!

a mon avis, le facteur le plus bloquant sera la bande passante, parce qu'a moins d'avoir une charrette en processeur, le chiffrement se fait assez facilement.
 
faudrait effectivement faire quelques tests.
 
perso, quitte a crypter, je dirais qu'on a autant balancer ca sur scp plutot que ftp, ca consomme pas grand chose en plus niveau puissance et bande passante.

Il y a d'ailleurs une IHM qui existe pour manipuler duplicity.
Ca s'appelle Deja-dup pour ceux que ça intéresse...
https://launchpad.net/deja-dup

Tout à fait d'accord, un scp (avec accès par clef) est sans doute plus approprié.
 
En ce qui concerne la bande passante, moi je vois cette sauvegarde comme un moyen de sauver les documents (et eventuellement photos) que je stocke. Ca rest un volume raisonnable (disons une dizaine de Go) , et surtout ca évolue peu. Donc une fois passé la sauvegarde initiale (qui va effectivement etre galère), la bande passante utilisée est faible.

oui, mais tu voulais tester duplicity sur un gros volume pour voir ce qui limiterai... bp ou crypto.
 
donc j'dis juste qu'amha, ca sera la bp qui limitera l'efficacité de la solution, c'est pas le surcout en temps de calcul de la crypto qui flinguera les performances de ce systeme...
 
 
et pis bon, sachant que toutes les connexions adsl ont un up de minimum 60/80ko/s de nos jours, 10Go, ca va se faire rapidement quoi...
en un jour ou deux, c'est plié, pour la sauvegarde initiale
 
 
par contre, perso, avant de me lancer la dedans, y'a juste une microcouille qui me chiffone : qu'est ce qui se passe si bob sauvegarde des fichiers illégaux chez tom?
 
j'parle pas d'illégaux basiques genre mp3 ou autres trucs a la con comme ca, mais plutot illégaux genre pédoporno par exemple...
 
dans un cas comme ca, est ce que celui qui offre un espace disque a l'autre est considéré comme hebergeur? est ce qu'il peut etre considéré comme responsable du contenu, en sachant qu'il n'est pas censé le connaitre mais qu'il est possible qu'il sache ce qu'il en est?
 
le coup de la sauvegarde décentralisée ( et meme multi-décentralisée, on pourrait faire plusieurs copies sur plusieurs sites, un peu comme du raid, on copie un bout des données importantes a droite, un bout a gauche, et une parité sur ce truc dans un troisieme endroit ), ca me plait assez...
mais y'a d'autres considérations que j'ai tendance a prendre en compte, surtout quand on voit comment ca va fliquer et filtrer dans tout les sens d'ici peu...
 
 
 
pardon pour le roman, j'me suis un peu perdu dans mes idées

 
Tu as parfaitement raison, et je n'avais pas pensé à çà...