Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS Linux Debian [HS] Fichier tronqué à 4096 octets

[HS] Fichier tronqué à 4096 octets

3 réponses
Avatar
Daniel Caillibaud
Bonjour,

Il m'arrive un truc bizarre, qui n'a probablement pas grand chose =C3=A0 vo=
ir avec debian

J'a un volume lvm en ext3 construit avec --stripes 2 (=C3=A7a revient =C3=
=A0 faire du raid0, mais sans
passer par mdadm) sur des pv qui sont des partitions primaires sur des disq=
ues ssd.=20

Dans ce lv, j'ai un fichier qui se retrouve brusquement tronqu=C3=A9 =C3=A0=
4096 octets. Rien dans les
logs...
Je remet l'original, mais dans les heures qui suivent il est tronqu=C3=A9 d=
e nouveau.

Je d=C3=A9monte mon volume et lance fsck, qui ne trouve rien...

=C3=87a vous cause ?

--=20
Daniel

Le pressentiment, c'est le souvenir du futur.
Pierre Dac

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20110531023554.5c0741da@quad.lairdutemps.org
Signaler un problème avec ce contenu

3 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Bernard Schoenacker
Le Tue, 31 May 2011 02:35:54 +0200,
Daniel Caillibaud a écrit :

Bonjour,

Il m'arrive un truc bizarre, qui n'a probablement pas grand chose à
voir avec debian

J'a un volume lvm en ext3 construit avec --stripes 2 (ça revient à
faire du raid0, mais sans passer par mdadm) sur des pv qui sont des
partitions primaires sur des disques ssd.

Dans ce lv, j'ai un fichier qui se retrouve brusquement tronqué à
4096 octets. Rien dans les logs...
Je remet l'original, mais dans les heures qui suivent il est tronqué
de nouveau.

Je démonte mon volume et lance fsck, qui ne trouve rien...

Ça vous cause ?



bonjour,

essaye de trouver un fil de discussion ayant trait au fs et à la
taille des tables SQL ....

peut être faudrait il penser à employer un autre fs

slt
bernard

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Daniel Caillibaud
Le 31/05/11 à 07:38, Bernard Schoenacker a écrit :

BS> Le Tue, 31 May 2011 02:35:54 +0200,
BS> Daniel Caillibaud a écrit :
BS> > Dans ce lv, j'ai un fichier qui se retrouve brusquement tronqué à
BS> > 4096 octets. Rien dans les logs...

BS> essaye de trouver un fil de discussion ayant trait au fs et à la
BS> taille des tables SQL ....

Je l'ai pas retrouvé, mais j'ai trouvé l'origine de mon pb.

BS> peut être faudrait il penser à employer un autre fs

Pourquoi, ext3 est pas fiable ?

De toute façon, c'est pour des VM en openvz donc j'ai pas trop le choi x du fs (à moins de
chercher davantage de pbs).

En fait, c'était le spare qui avait un pb de disque "silencieux" (smar t ne voit toujours rien,
et à force de faire plein de rsync je commence à voir des trucs d ans le kern.log), et qui
répliquait son pb sur ce fichier sur le serveur en prod.

Il me reste donc à ajouter des contrôles md5 sur tous les fichier s si je veux prévenir ce genre
de choses...

--
Daniel

L'équipe de France de football est très appréciée : tou tes les autres équipes
veulent la rencontrer.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Bernard Schoenacker
Le Wed, 1 Jun 2011 04:22:29 +0200,
Daniel Caillibaud a écrit :

Le 31/05/11 à 07:38, Bernard Schoenacker
a écrit :

BS> Le Tue, 31 May 2011 02:35:54 +0200,
BS> Daniel Caillibaud a écrit :
BS> > Dans ce lv, j'ai un fichier qui se retrouve brusquement tronqué
BS> > à 4096 octets. Rien dans les logs...

BS> essaye de trouver un fil de discussion ayant trait au fs
BS> et à la taille des tables SQL ....

Je l'ai pas retrouvé, mais j'ai trouvé l'origine de mon pb.

BS> peut être faudrait il penser à employer un autre fs

Pourquoi, ext3 est pas fiable ?

De toute façon, c'est pour des VM en openvz donc j'ai pas trop le
choix du fs (à moins de chercher davantage de pbs).

En fait, c'était le spare qui avait un pb de disque
"silencieux" (smart ne voit toujours rien, et à force de faire plein
de rsync je commence à voir des trucs dans le kern.log), et qui
répliquait son pb sur ce fichier sur le serveur en prod.

Il me reste donc à ajouter des contrôles md5 sur tous les fichiers si
je veux prévenir ce genre de choses...




bonjour,

ext3fs est fiable, mais il ne faut pas oublier la limitation de
la taille maxi d'un fichier pour ext3 ....

cette réponse est également valable avec les autres fs et
quelque soit le système d'exploitation.

slt
bernard

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/