bonjour,
suite au fil sur les SSD et la réécriture des fichiers :
j'ai un RPi dans lequel je stocke un par un des milliers d'images
(jusqu'à 15000) dans une clé USB.
À chaque création de fichier, il y a écriture bien sûr mais aussi
écriture du "descripteur" du répertoire. C'est lui qui souffre.
Comme il y a 20 secondes entre deux demandes d'écriture il n'y a pas de
mise en cache (ce que j'ai constaté par la LED d'activité sur la cle USB.
Peut-on limiter le nombre d'écritures en faisant un tar d'une centaine
d'images dans un /tmp en RAM puis d'écrire ce fichier tar une fois qu'il
atteint une certaine taille.
De l'autre côté pour "détarrer" c'est un DD "normal" donc le problème ne
se pose pas.
Si vous voyez d'autres solutions, je suis preneur.
Merci d'avance
Entrevoyez vous d'autres solutionspour limiter le nombre d'écritures.
moi-meme , dans le message <545bc065$0$5117$, a écrit :
Peut-on limiter le nombre d'écritures en faisant un tar d'une centaine d'images dans un /tmp en RAM puis d'écrire ce fichier tar une fois qu'il atteint une certaine taille.
Oui, évidemment, puisque tu as décrit la méthode.
moi-meme , dans le message <545bc065$0$5117$426a34cc@news.free.fr>, a
écrit :
Peut-on limiter le nombre d'écritures en faisant un tar d'une centaine
d'images dans un /tmp en RAM puis d'écrire ce fichier tar une fois qu'il
atteint une certaine taille.
moi-meme , dans le message <545bc065$0$5117$, a écrit :
Peut-on limiter le nombre d'écritures en faisant un tar d'une centaine d'images dans un /tmp en RAM puis d'écrire ce fichier tar une fois qu'il atteint une certaine taille.
Oui, évidemment, puisque tu as décrit la méthode.
Denis Corbin
Le 06/11/2014 19:52, Nicolas George a écrit :
moi-meme , dans le message <545bc065$0$5117$, a écrit :
Peut-on limiter le nombre d'écritures en faisant un tar d'une centaine d'images dans un /tmp en RAM puis d'écrire ce fichier tar une fois qu'il atteint une certaine taille.
Oui, évidemment, puisque tu as décrit la méthode.
utiliser dar http://dar.linux.free.fr/ au lieu de tar, il sait créer des archives en tranches de taille définie par l'utilisateur ... sans compter qu'il sauvegarde plus de choses que tar (lien durs, fichiers creux, ACL, extended Attributes, etc.)
Le 06/11/2014 19:52, Nicolas George a écrit :
moi-meme , dans le message <545bc065$0$5117$426a34cc@news.free.fr>, a
écrit :
Peut-on limiter le nombre d'écritures en faisant un tar d'une centaine
d'images dans un /tmp en RAM puis d'écrire ce fichier tar une fois qu'il
atteint une certaine taille.
Oui, évidemment, puisque tu as décrit la méthode.
utiliser dar http://dar.linux.free.fr/ au lieu de tar, il sait créer
des archives en tranches de taille définie par l'utilisateur ... sans
compter qu'il sauvegarde plus de choses que tar (lien durs, fichiers
creux, ACL, extended Attributes, etc.)
moi-meme , dans le message <545bc065$0$5117$, a écrit :
Peut-on limiter le nombre d'écritures en faisant un tar d'une centaine d'images dans un /tmp en RAM puis d'écrire ce fichier tar une fois qu'il atteint une certaine taille.
Oui, évidemment, puisque tu as décrit la méthode.
utiliser dar http://dar.linux.free.fr/ au lieu de tar, il sait créer des archives en tranches de taille définie par l'utilisateur ... sans compter qu'il sauvegarde plus de choses que tar (lien durs, fichiers creux, ACL, extended Attributes, etc.)
moi-meme
Le Thu, 06 Nov 2014 20:50:24 +0100, Denis Corbin a écrit :
utiliser dar http://dar.linux.free.fr/ au lieu de tar, il sait créer des archives en tranches de taille définie par l'utilisateur ... sans compter qu'il sauvegarde plus de choses que tar (lien durs, fichiers creux, ACL, extended Attributes, etc.)
Vu le package.
J'essaie Merci
Le Thu, 06 Nov 2014 20:50:24 +0100, Denis Corbin a écrit :
utiliser dar http://dar.linux.free.fr/ au lieu de tar, il sait créer des
archives en tranches de taille définie par l'utilisateur ... sans
compter qu'il sauvegarde plus de choses que tar (lien durs, fichiers
creux, ACL, extended Attributes, etc.)
Le Thu, 06 Nov 2014 20:50:24 +0100, Denis Corbin a écrit :
utiliser dar http://dar.linux.free.fr/ au lieu de tar, il sait créer des archives en tranches de taille définie par l'utilisateur ... sans compter qu'il sauvegarde plus de choses que tar (lien durs, fichiers creux, ACL, extended Attributes, etc.)
Vu le package.
J'essaie Merci
Dominique MICOLLET
Bonjour,
moi-meme wrote:
Si vous voyez d'autres solutions, je suis preneur.
Il fût une époque où existait le "jffs" (journalized flash file system). Je n'en vois plus de trace claire dans ma Debian. Quelqu'un sait-il si ça existe toujours ?
Cordialement
Dominique.
Bonjour,
moi-meme wrote:
Si vous voyez d'autres solutions, je suis preneur.
Il fût une époque où existait le "jffs" (journalized flash file system).
Je n'en vois plus de trace claire dans ma Debian.
Quelqu'un sait-il si ça existe toujours ?
Si vous voyez d'autres solutions, je suis preneur.
Il fût une époque où existait le "jffs" (journalized flash file system). Je n'en vois plus de trace claire dans ma Debian. Quelqu'un sait-il si ça existe toujours ?
Cordialement
Dominique.
Pascal Hambourg
Dominique MICOLLET a écrit :
Il fût une époque où existait le "jffs" (journalized flash file system). Je n'en vois plus de trace claire dans ma Debian. Quelqu'un sait-il si ça existe toujours ?
Le support de jffs2 est inclus dans le noyau standard. Mais jffs2 et ses cousins (yaffs, ubifs...) ne sont pas adaptés aux clés USB et autres périphériques bloc qui cachent la mémoire flash derrière un contrôleur USB/SATA/autre, ils sont conçus pour fonctionner directement avec des puces de mémoire flash comme on peut en trouver dans les équipements "embarqués".
Dominique MICOLLET a écrit :
Il fût une époque où existait le "jffs" (journalized flash file system).
Je n'en vois plus de trace claire dans ma Debian.
Quelqu'un sait-il si ça existe toujours ?
Le support de jffs2 est inclus dans le noyau standard. Mais jffs2 et ses
cousins (yaffs, ubifs...) ne sont pas adaptés aux clés USB et autres
périphériques bloc qui cachent la mémoire flash derrière un contrôleur
USB/SATA/autre, ils sont conçus pour fonctionner directement avec des
puces de mémoire flash comme on peut en trouver dans les équipements
"embarqués".
Il fût une époque où existait le "jffs" (journalized flash file system). Je n'en vois plus de trace claire dans ma Debian. Quelqu'un sait-il si ça existe toujours ?
Le support de jffs2 est inclus dans le noyau standard. Mais jffs2 et ses cousins (yaffs, ubifs...) ne sont pas adaptés aux clés USB et autres périphériques bloc qui cachent la mémoire flash derrière un contrôleur USB/SATA/autre, ils sont conçus pour fonctionner directement avec des puces de mémoire flash comme on peut en trouver dans les équipements "embarqués".
Dominique MICOLLET
Bonjour,
Pascal Hambourg wrote:
ils sont conçus pour fonctionner directement avec des puces de mémoire flash comme on peut en trouver dans les équipements "embarqués".
Je suis surpris. Je pensais qu'il serait possible d'implanter le système de journalisation au dessus du système d'écriture en bloc (qui pour moi se trouve à un niveau matériel plus bas que le système de fichier dans le noyau). Mais je dois reconnaître ma grande ignorance en la matière.
Cordialement
Dominique.
Bonjour,
Pascal Hambourg wrote:
ils sont conçus pour fonctionner directement avec des
puces de mémoire flash comme on peut en trouver dans les équipements
"embarqués".
Je suis surpris. Je pensais qu'il serait possible d'implanter le système de
journalisation au dessus du système d'écriture en bloc (qui pour moi se
trouve à un niveau matériel plus bas que le système de fichier dans le
noyau).
Mais je dois reconnaître ma grande ignorance en la matière.
ils sont conçus pour fonctionner directement avec des puces de mémoire flash comme on peut en trouver dans les équipements "embarqués".
Je suis surpris. Je pensais qu'il serait possible d'implanter le système de journalisation au dessus du système d'écriture en bloc (qui pour moi se trouve à un niveau matériel plus bas que le système de fichier dans le noyau). Mais je dois reconnaître ma grande ignorance en la matière.
Cordialement
Dominique.
Dominique MICOLLET
Bonjour,
Pascal Hambourg wrote:
des choses qui ont piqué ma curiosité.
D'après wikipedia, il y aurait des solutions. http://en.wikipedia.org/wiki/JFFS2 en mentionne plusieurs parmi lesquelles NILFS semblerait une solution intéressante.
Il va falloir que je regarde de plus près.
Cordialement
Dominique.
Bonjour,
Pascal Hambourg wrote:
des choses qui ont piqué ma curiosité.
D'après wikipedia, il y aurait des solutions.
http://en.wikipedia.org/wiki/JFFS2 en mentionne plusieurs parmi lesquelles
NILFS semblerait une solution intéressante.
D'après wikipedia, il y aurait des solutions. http://en.wikipedia.org/wiki/JFFS2 en mentionne plusieurs parmi lesquelles NILFS semblerait une solution intéressante.
Il va falloir que je regarde de plus près.
Cordialement
Dominique.
moi-meme
Le Thu, 06 Nov 2014 20:50:24 +0100, Denis Corbin a écrit :
Le 06/11/2014 19:52, Nicolas George a écrit :
moi-meme , dans le message <545bc065$0$5117$, a écrit :
Peut-on limiter le nombre d'écritures en faisant un tar d'une centaine d'images dans un /tmp en RAM puis d'écrire ce fichier tar une fois qu'il atteint une certaine taille.
Oui, évidemment, puisque tu as décrit la méthode.
utiliser dar http://dar.linux.free.fr/ au lieu de tar, il sait créer des archives en tranches de taille définie par l'utilisateur ... sans compter qu'il sauvegarde plus de choses que tar (lien durs, fichiers creux, ACL, extended Attributes, etc.)
vu la manière de faire un tmpfs : je vais approfondir.
Le Thu, 06 Nov 2014 20:50:24 +0100, Denis Corbin a écrit :
Le 06/11/2014 19:52, Nicolas George a écrit :
moi-meme , dans le message <545bc065$0$5117$426a34cc@news.free.fr>, a
écrit :
Peut-on limiter le nombre d'écritures en faisant un tar d'une centaine
d'images dans un /tmp en RAM puis d'écrire ce fichier tar une fois
qu'il atteint une certaine taille.
Oui, évidemment, puisque tu as décrit la méthode.
utiliser dar http://dar.linux.free.fr/ au lieu de tar, il sait créer des
archives en tranches de taille définie par l'utilisateur ... sans
compter qu'il sauvegarde plus de choses que tar (lien durs, fichiers
creux, ACL, extended Attributes, etc.)
vu la manière de faire un tmpfs : je vais approfondir.
Le Thu, 06 Nov 2014 20:50:24 +0100, Denis Corbin a écrit :
Le 06/11/2014 19:52, Nicolas George a écrit :
moi-meme , dans le message <545bc065$0$5117$, a écrit :
Peut-on limiter le nombre d'écritures en faisant un tar d'une centaine d'images dans un /tmp en RAM puis d'écrire ce fichier tar une fois qu'il atteint une certaine taille.
Oui, évidemment, puisque tu as décrit la méthode.
utiliser dar http://dar.linux.free.fr/ au lieu de tar, il sait créer des archives en tranches de taille définie par l'utilisateur ... sans compter qu'il sauvegarde plus de choses que tar (lien durs, fichiers creux, ACL, extended Attributes, etc.)
vu la manière de faire un tmpfs : je vais approfondir.
Nicolas George
Dominique MICOLLET , dans le message <545c92cf$0$1980$, a écrit :
Je suis surpris. Je pensais qu'il serait possible d'implanter le système de journalisation au dessus du système d'écriture en bloc (qui pour moi se trouve à un niveau matériel plus bas que le système de fichier dans le noyau).
On peut, oui, mais ce n'est pas ce que fait JFFS2. JFFS2 est spécifiquement conçu pour les périphériques flash contrôlables directement.
Accessoirement, les clefs USB et compagnie sont censées faire un peu de wear-levelling. Même s'il est tout pourri sur les versions d'entrée de gamme, ça ruine les possibilités de contrôler finement ce qui se passe.
Dominique MICOLLET , dans le message
<545c92cf$0$1980$426a74cc@news.free.fr>, a écrit :
Je suis surpris. Je pensais qu'il serait possible d'implanter le système de
journalisation au dessus du système d'écriture en bloc (qui pour moi se
trouve à un niveau matériel plus bas que le système de fichier dans le
noyau).
On peut, oui, mais ce n'est pas ce que fait JFFS2. JFFS2 est spécifiquement
conçu pour les périphériques flash contrôlables directement.
Accessoirement, les clefs USB et compagnie sont censées faire un peu de
wear-levelling. Même s'il est tout pourri sur les versions d'entrée de
gamme, ça ruine les possibilités de contrôler finement ce qui se passe.
Dominique MICOLLET , dans le message <545c92cf$0$1980$, a écrit :
Je suis surpris. Je pensais qu'il serait possible d'implanter le système de journalisation au dessus du système d'écriture en bloc (qui pour moi se trouve à un niveau matériel plus bas que le système de fichier dans le noyau).
On peut, oui, mais ce n'est pas ce que fait JFFS2. JFFS2 est spécifiquement conçu pour les périphériques flash contrôlables directement.
Accessoirement, les clefs USB et compagnie sont censées faire un peu de wear-levelling. Même s'il est tout pourri sur les versions d'entrée de gamme, ça ruine les possibilités de contrôler finement ce qui se passe.
JKB
Le Fri, 07 Nov 2014 09:50:11 +0100, Pascal Hambourg écrivait :
Dominique MICOLLET a écrit :
Il fût une époque où existait le "jffs" (journalized flash file system). Je n'en vois plus de trace claire dans ma Debian. Quelqu'un sait-il si ça existe toujours ?
Le support de jffs2 est inclus dans le noyau standard. Mais jffs2 et ses cousins (yaffs, ubifs...) ne sont pas adaptés aux clés USB et autres périphériques bloc qui cachent la mémoire flash derrière un contrôleur USB/SATA/autre, ils sont conçus pour fonctionner directement avec des puces de mémoire flash comme on peut en trouver dans les équipements "embarqués".
Tu peux néanmoins l'utiliser. J'ai eu tellement de merdes avec des disques SSD dans l'embarqué que je n'utilise plus aujourd'hui que des adaptateurs SATA vers CF et des cartes CF SLC. Avec le module mtdblock, tu peux émuler un device mtd au dessus d'un device de type block et tu peux alors utiliser ubifs ou consort (je préfère ubifs aux autres car le montage est bienplus rapide).
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Fri, 07 Nov 2014 09:50:11 +0100,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> écrivait :
Dominique MICOLLET a écrit :
Il fût une époque où existait le "jffs" (journalized flash file system).
Je n'en vois plus de trace claire dans ma Debian.
Quelqu'un sait-il si ça existe toujours ?
Le support de jffs2 est inclus dans le noyau standard. Mais jffs2 et ses
cousins (yaffs, ubifs...) ne sont pas adaptés aux clés USB et autres
périphériques bloc qui cachent la mémoire flash derrière un contrôleur
USB/SATA/autre, ils sont conçus pour fonctionner directement avec des
puces de mémoire flash comme on peut en trouver dans les équipements
"embarqués".
Tu peux néanmoins l'utiliser. J'ai eu tellement de merdes avec des
disques SSD dans l'embarqué que je n'utilise plus aujourd'hui que
des adaptateurs SATA vers CF et des cartes CF SLC. Avec le module
mtdblock, tu peux émuler un device mtd au dessus d'un device de type
block et tu peux alors utiliser ubifs ou consort (je préfère ubifs
aux autres car le montage est bienplus rapide).
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Fri, 07 Nov 2014 09:50:11 +0100, Pascal Hambourg écrivait :
Dominique MICOLLET a écrit :
Il fût une époque où existait le "jffs" (journalized flash file system). Je n'en vois plus de trace claire dans ma Debian. Quelqu'un sait-il si ça existe toujours ?
Le support de jffs2 est inclus dans le noyau standard. Mais jffs2 et ses cousins (yaffs, ubifs...) ne sont pas adaptés aux clés USB et autres périphériques bloc qui cachent la mémoire flash derrière un contrôleur USB/SATA/autre, ils sont conçus pour fonctionner directement avec des puces de mémoire flash comme on peut en trouver dans les équipements "embarqués".
Tu peux néanmoins l'utiliser. J'ai eu tellement de merdes avec des disques SSD dans l'embarqué que je n'utilise plus aujourd'hui que des adaptateurs SATA vers CF et des cartes CF SLC. Avec le module mtdblock, tu peux émuler un device mtd au dessus d'un device de type block et tu peux alors utiliser ubifs ou consort (je préfère ubifs aux autres car le montage est bienplus rapide).
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
