Crash Syno en copie iscsi (cryptosetup)

[kralisec]

Bonsoir,

 

J'espère croiser par ici un ou plusieurs curieux qui voudront bien me suivre avec un problème que j'ai rencontré déjà 4 fois,

en gros: crash total du syno au moment de l'écriture (environ 10Mo/s) sur un lun iscsi avec une couche crypto ...

Le linux se porte bien lui puisque une fois le syno revenue à la vie il tenter de continuer d'écrire jusqu'une prochain reboot.

 

Le crash est avéré: plus de son / plus d'images (i.e.: plus de ping et un uptime de 2mn au ssh suivamt)

pour le moment j'en suis à 4 crash, le seul truc qui semble aider c'est d'ajouter un --bwlimit=1000 dans la commande rsync

une copie directement sur le volume du nas fonctionne sans problème (par smb, rien à voir avec le lun)

et pour info: le lun a été ajouté sur l'espace disque du volume du syno (il n'y pas sa partition dédié)

 

Je mets ci-dessous un max d'infos technique qui peuvent être lié au problème

DS-411J
 - 3 DD 2To + 1 DD 2.5Go (suite échange défectueux)
 - système quasi plein: 17Go de libre :(
 - DSM derniers en date 5.2-5644
 - LUN 20Go en Thin Provisionning No

Aucun accès externe aussi bien par redirection de port ou quickconnect (en cas de suspicion virus ou autre)
utilisation extrèmement basique, packages installés: media server (dlna) et surveillance station (tourne pas)

Accès depuis ubuntu 14.04 LTS 64b :
 - open-iscsi : 2.0.873-3ubuntu9
 - crypsetup  : 2:1.6.1-1ubuntu1

montage en wifi Intel(R) Dual Band Wireless AC 7260, REV=0x144: vitesse de copie entre 6 et 14Mo/s

 

Comme j'ai qu'1 syno je suis pas terriblement chaud pour continuer à crasher le système,

je suppose qu'à force d'insister il va finir par le me faire payer ^^

Mais si qqu'un a des question n'hésitez pas, ce serait déjà un bon départ de savoir si c'est reproductible.

 

a+,

Laurent.

[DaffY]

J'ai un l'un de 50go colle toi mais les différences sont

Absence de cryptage

OS X et non Linux

Pas de pb rencontré pour le moment

[Fenrir]

• le chiffrement est une opération qui coute très cher en cpu (sauf avec les modèles qui ont une puce dédiée), mais ici c'est ton linux qui s'en charge
• l'iscsi en fichier (vs sur un volume dédié) et aussi une opération qui coute assez cher en cpu
• devoir écrire des blocs sur un système presque plein coute aussi cher en cpu + en accès disques
• les modèles J sont pauvre en cpu

=>ça ne m'étonne qu'à moitié que ça plante

vérifie la charge (load) du syno lors d'une opération d'écriture, si ça monte en flèche c'est probablement ça

[kralisec]

@daffy: merci pour ton retour.

@Fenrir: pour l'idée que le disque presque plein coûte cher en cpu, le fichier a été créé en un seul block continue,
c'est pas une taille dynamique, je pense pas que cela soit un critère.

Je viens de faire un rsync pour les valeurs de top:

au repos:

Mem: 96624K used, 21840K free, 0K shrd, 1624K buff, 32976K cached
CPU:  0.1% usr  0.1% sys  0.0% nic 99.6% idle  0.0% io  0.0% irq  0.0% sirq
Load average: 0.02 0.06 0.01 1/233 30402

avec --bwlimit=1000  => pas de crash  (fichier 400Mo)

Mem: 89660K used, 28804K free, 0K shrd, 1600K buff, 25740K cached
CPU:  0.0% usr  0.3% sys  0.0% nic 99.0% idle  0.5% io  0.0% irq  0.0% sirq
Load average: 0.28 0.13 0.03 1/234 30446

 
avec --bwlimit=5000  => crash après 40s de copie, dernière valeur (fichier 400Mo)

Mem: 109148K used, 9316K free, 0K shrd, 1480K buff, 29256K cached
CPU:  0.1% usr 11.8% sys  0.0% nic 17.0% idle 64.9% io  0.3% irq  5.5% sirq
Load average: 0.78 0.28 0.09 3/234 30474

Le load monte vite ...

Valeurs en reconstruction du raid (pour comparaison, c'est censé être une tâche "lourde")

Mem: 97716K used, 20748K free, 0K shrd, 1772K buff, 21784K cached
CPU:  0.3% usr  0.5% sys  0.0% nic 76.3% idle 22.6% io  0.0% irq  0.0% sirq
Load average: 0.03 0.23 0.64 2/234 8393

Cela fait qque temps que j'avais pas écrit aussi je ne sais pas à quand cela remonte,
mais le problème ne s'est jamais présenté avec un DSM 4 par exemple.

Un crash de cette violence c'est tout de même étonnant,

d'autres idées ?

a+,
Laurent.

 

[kralisec]

Un autre essai de copie avec --bwlimit=1000

Mem: 91856K used, 26608K free, 0K shrd, 1464K buff, 25068K cached
CPU:  0.0% usr  0.1% sys  0.0% nic 99.6% idle  0.1% io  0.0% irq  0.0% sirq
Load average: 0.63 0.24 0.09 1/233 28796

le load augmente et baisse comme par vague, mais chaque nouveau pic va plus loin que le précédent,
hier j'ai eu 0,28, la j'ai vu 0,45 puis 0,75 => ctrl-z à ce moment
(c'était la dernière valeur avant le crash avec --bwlimit=5000)
après reprise du job par fg la variation revient progressivement, 2mn pour repasser à 0,30
baisser à 0,10

Mem: 93488K used, 24976K free, 0K shrd, 1632K buff, 27624K cached
CPU:  0.1% usr  0.1% sys  0.0% nic 99.2% idle  0.3% io  0.0% irq  0.0% sirq
Load average: 0.14 0.14 0.09 1/233 29015

Mem: 101320K used, 17144K free, 0K shrd, 1652K buff, 29400K cached
CPU:  0.0% usr  1.3% sys  0.0% nic 97.4% idle  0.3% io  0.0% irq  0.7% sirq
Load average: 0.10 0.13 0.09 1/232 29020

Bref, la charge est la bonne piste, une théorie à 2 balle: le système de cryptage
est + gourmand en opération mathématique que les précédentes version, le cpu J ne suit pas :(

a+,
Laurent.