La meilleure façon de «durcir» le server de files ext4 embedded contre une perte de puissance inattendue?

Tout d'abord, un peu d'arrière-plan: ma société fabrique un périphérique de diffusion audio qui est une boîte Linux sans tête, montée en rack, avec un lecteur SS-state SATA. Le lecteur est formaté avec ext4. Les users peuvent se connecter au système en utilisant Samba / CIFS pour download de nouveaux files audio ou accéder à des files existants. Il existe également un logiciel personnalisé pour diffuser de l'audio sur le réseau.

Tout va bien. Le seul problème, c'est que les users sont des personnes audio, pas des ordinateurs, et qu'ils voient le système comme une «boîte noire», pas comme un ordinateur. Ce qui signifie qu'à la fin de la journée, ils ne vont pas entrer dans la boîte et entre "/ sbin / shutdown -h"; Ils vont simplement couper le pouvoir sur le rack et partir, et s'attendre à ce que les choses fonctionnent toujours correctement le lendemain.

Étant donné que ext4 a un journal, une vérification des journaux, etc., cela fonctionne surtout. La seule fois où il ne fonctionne pas, c'est quand quelqu'un télécharge un nouveau file via Samba, puis coupe l'alimentation du système avant que datatables téléchargées ne soient totalement effacées sur le disque. Dans ce cas, ils viennent le lendemain et constatent que leur nouveau file a été tronqué ou manque complètement et est malheureux.

Ma question est, quel est le meilleur moyen d'éviter ce problème? Existe-t-il un moyen d'get que smbd appelle «synchronisation» à la fin de chaque téléchargement? (La performance sur les téléchargements n'est pas si importante, car ils ne se produisent que de time en time). Ou existe-t-il un moyen de dire à ext4 de chauffer automatiquement dans quelques secondes de toute modification d'un file? (Encore une fois, la performance peut être sacrifiée pour la security ici) Devrais-je définir un mode de command d'écriture particulier, activer les barrières, etc.?

3 Solutions collect form web for “La meilleure façon de «durcir» le server de files ext4 embedded contre une perte de puissance inattendue?”

Le assembly du système de files avec la sync spécifiée dans fstab aiderait probablement. Je soupçonne que quelqu'un aura une recommandation mieux adaptée à votre application particulière.

J'ai commencé une search initiale sur les filesystems utilisés avec le stockage flash, car je souhaite personnaliser un PC de home theater comme appareil. Vous pouvez find une solution de stockage différente mieux adaptée à votre appareil. Malheureusement, j'ai encore trouvé quelque chose que je préfère, donc je n'ai pas de recommandation détaillée là-bas.

Modifier 1

Selon la page de manuel smb.conf (5), il supporte la synchronisation immédiate dans SAMBA:

  ssortingct sync (S) Many Windows applications (including the Windows 98 explorer shell) seem to confuse flushing buffer contents to disk with doing a sync to disk. Under UNIX, a sync call forces the process to be sus- pended until the kernel has ensured that all out- standing data in kernel disk buffers has been safely stored onto stable storage. This is very slow and should only be done rarely. Setting this parameter to no (the default) means that smbd(8) ignores the Windows applications requests for a sync call. There is only a possibility of losing data if the operating system itself that Samba is running on crashes, so there is little danger in this default setting. In addition, this fixes many performance problems that people have reported with the new Windows98 explorer shell file copys. Default: ssortingct sync = no sync always (S) This is a boolean parameter that controls whether writes will always be written to stable storage before the write call returns. If this is no then the server will be guided by the client's request in each write call (clients can set a bit indicat- ing that a particular write should be synchronous). If this is yes then every write will be followed by a fsync() call to ensure the data is written to disk. Note that the ssortingct sync parameter must be set to yes in order for this parameter to have any affect. Default: sync always = no 

Bien, j'ai travaillé avec le même problème. Si vous désactivez tout type de caching d'écriture dans le système, toutes datatables seront écrites sur le disque dès que possible.

Vous allez perdre des performances, mais vous obtiendrez une meilleure intégrité des données.

La différence entre datatables sur le disque et ce que le operating system pense est sur le disque (mais en fait, en cache) sera considérablement plus faible.

Si vous ne pouvez pas utiliser un onduleur pour la solution, ou une solution matérielle qui arrête gracieusement la machine si une puissance est perdue de l'AC, vous devrez utiliser des hacks comme celui-ci.

Il peut être une idée d'utiliser un système de files beaucoup plus simple pour stocker les médias et démarrer le operating system à partir d'un disque ramdisk. Évitant ainsi la possibilité de corrompre la partition boot / root de la machine.

Donc, pour récapituler,

Montez le système de files avec la synchronisation, vous perdrez des performances, mais toutes les écritures ne seront pas mises en cache.

Désactivez les caches d'écriture du disque dur, vous perdrez de nouveau les performances.

Cet article devrait vous intéresser

http://sr5tech.com/write_back_cache_experiments.htm

Puisque vous mentionnez que votre entreprise construit ces derniers, je reorderais de regarder un angle matériel. J'ai vu des servers avec des sauvegardes de batterie sur les controllers de lecteur pour permettre aux données en cache de survivre à une perte de puissance. Que faire si vos ingénieurs ont construit une petite batterie pour que le système fonctionne assez longtime pour être éteint? Il ne serait pas nécessaire d'être un gros onduleur distinct, il pourrait être interne et arrêter l'installation dès que l'alimentation A / C a été perdue. Cela pourrait append quelques dollars au coût, mais cela pourrait aussi être un sharepoint marketing.

Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de réseau.