SMPFR

HEllo,

je suis en train de faire une petite Appliance, et je me retrouve avec des perfs moisies, aussi bien en lecture qu'écriture.

j'étais en ext2 pour éviter la journalisation qui bouffe des IO monstrueusement, et donc réduit la durée de vie des clef USB/cartes flash. (en plus de parfois saturer les contrôleurs quand utilisé sur des machines très légères)

du coup j'ai trouvé ça:
https://blogofterje.wordpress.com/2012/ ... n-sd-card/

donc ext2 c'est bien mais pas optimal, et en plus j'ai trouvé pas mal de truc pour tuner ext4 pour que ce soit plus adapté a des cartes flash !

si ça peut vous éviter de chercher si vous êtes confrontés au pb

F2FS sinon ^^
https://en.wikipedia.org/wiki/F2FS

https://korben.info/f2fs-systeme-de-fic ... aller.html

et pour les clefs usb/sd elles sont pas toutes égales
j'ai un soucis similaire pour mon erl3

regarde le post de bleagh (5° post de mémoire)
https://community.ubnt.com/t5/EdgeMAX/L ... -p/1185011

Si tu peux, travailles le plus possible en RAM.
Pour F2FS, je sais pas s'il est fiable, ça fait plusieurs années que je vois des articles dessus mais pas trop suivi. En tout cas je déconseille ext2. S'il est plus performant c'est parce qu'il est pas fiable. Donc y a plein de choses qui sautent dans les opérations d'écriture principalement, ce qui fait qu'il est plus rapide...

Pour la durée de vie, prends une plus grosse carte aussi.
Si t'as vraiment besoin d'i/o et de fiabilité faudra peut-être revoir ton truc

F2FS ça a pas l'air natif, donc exit.

ext2, oui, c'est moins fiable du fait qu'il n'y a pas la journalisation, ce qui est recherché ici.
ya pas de miracle, si on veut aller vite et/ou limiter les écritures ya forcement un moment ou on perd des trucs annexes (redondance ici) donc de la fiabilité

ext4 sans la journalisation, c'est comme ext2

et oui, c'est prévu de travailler principalement en RAM, sauf qu'il y aura pas bcp de RAM non plus sur l'appliance.
ça sera que du trafic réseau et les logs sont quasi tous désactivés pour limiter les écritures justement (ya guère que ça qui écrira)

tu peux synchro les logs depuis le tmpfs vers le disque toutes les X minutes, ça devrait largement aller. Si tu mets une carte de 32 ou 64 Go le temps de la bousiller je pense que t'as le temps !!

ça sera une 4 ou 8, ou il y aura en gros 1go occupé.
les logs, en gros il reste ceux du démarrage, faut que je tente de secouer un peu le truc voir si ça blablatte trop.

en fait, j'ai pas besoin de perfs disque.
je veux juste limiter l'usure des cartes et par la même avoir des performances acceptables si je dois déployer du soft dessus ou faire des MAJ de temps en temps (que ça mette pas 30mn a mettre a jour un kernel)

Est-ce que tu te ferais pas moins chier en prenant une carte SD ou clé USB "industrielle" en SLC ?

Genre carte Transcend // clé Transcend // clé Mach machin MX-ES // etc.

Le but c'est que ça coûte rien

bon bah avec toutes les optims, j'arrive a 700ko/s en soutenu (vs 150ko/s avant)

je pense que le contrôleur IDE (et le CPU et tout en fait) est juste pourri
m'en fout, une fois le system up, ya plus rien à écrire

je pense que tmpfs va être mon ami pour quelques trucs aussi !

ah oui c'est vraiment une bouze ton truc

Geode GX 500, 366Mhz, 512Mo RAM
un truc de winner !!!
par contre la bête bouffe 7W en full load (pas le CPU, la machine !!)

Geode GX 500, 366Mhz, 512Mo RAM
un truc de winner !!!
par contre la bête bouffe 7W en full load (pas le CPU, la machine !!)

mon gigabyte brix avec un atom et un disque 2.5 7200 tours il consomme 9W à la prise

ça m'a couté 2€50 + des trucs de récup
rapport perfs prix imbattable

ah oui, me fallait un port RS232 aussi.
ça commence a se faire rare ces bestioles.

Qu'est-ce qui nous mijote le dsebire ???

y veut conquérir le monde minus!

[:rofl]
@giz, ya un peu de ça

l'histoire:
a la base, je voulais monitorer mon onduleur mais ça se passe mal avec esxi. d'où l'idée d'une bécane a coté qui consomme que dalle qui ferait juste l'interface.
donc j'ai laissé en sommeil en attendant que j'ai rien de mieux a faire

sauf que entre temps, j'ai un potentiel client qui est intéressé par mes services (supervision en particulier) mais qui veut pas que je rentre chez lui pour aller lire les sondes. (un peu parano mais passons)

du coup, suis en train de développer une bécane sur un truc qui vaut que dalle pour faire un POC. l'idée étant qu'au lieu d'aller chercher les données, ce soit l'Appliance qui les envoie chez moi

pas envie de sortir du fric pour un truc qui servira peut être pas (je le sens moyen en fait) et qui me resservira par la suite
si ça se concrétise avec le client je verrais si ça passe niveau charge, sinon j'investirais (pas envie que le matos "disparaisse" non plus)

me suis planté en mesurant les perfs ... j'avais un process qui tournait en fond
1.6Mo/s en écriture et 12.3Mo/s en lecture.

donc 10x plus que au début, soit le même ordre de grandeur que le gars sur le site que j'ai mis au début.

le port IDE est en DMA33, la carte CF est pas non plus un truc de ouf, je trouve ça assez correct.

c'est largement correct

après 24h d'utilisation sur mon besoin perso qui sert de bench, RAS !
ça suffit largement

le CPU est franchment limite, ça met 200s a faire un apt update (pas upgrade !! )
le cache apt est en tmpfs, mais ce qui bride c'est la decompression des archives une fois téléchargées
(0 ecritures sur le disque, et ça swappe pas, 0% IOWAIT => c'est bien le CPU)

en dehors de ça, ça roule niquel.
pas eu besoin de passer les logs en tmpfs, ça ecrit a peine quelques ko/s

a voir la charge avec le client, vais lui dire que j'ai une solution.

une limitation: bien qu'il y ait un RTC, l'heure n'est pas sauvegardée a l'arret de la machine (comme sur le R-pi)
faut donc un daemon ntp qui fait la synchro
=> au demarrage jusqu'a la synchro, la date/heure dans les logs c'est du grand n'importe quoi

bah ça va le apt-get update t'en fais pas toutes les 5 minutes ?

non
une fois par 24h, ça suffit pour me dire si ya des MAJ dispo ou pas.

Si tu utilises systemd-timesyncd pour la synchro temps tu as normalement une synchro temps sauvegardée et restaurée très tôt lors du boot.
Cf https://wiki.archlinux.org/index.php/Systemd-timesyncd

Par contre ça veut dire que tu as des écritures régulières sur ta carte. :/

yaura quand même une desynchro le temps que le réseau monte et que les infos ntp arrivent
le daemon ntp se sync moins de 2mn après boot

donc ça gène pas pour une machine qui restera up h24
ça reset pas au reboot, ya que si débranché du secteur que l'heure repasse a 2006 (ça reset pas si seulement power off mais encore branché)

si ça se trouve ya possibilité de mettre une batterie pour conserver le RTC, mais j'ai pas le schéma de la carte