Forum Linux.général fichiers qui s'effacent tout seul au reboot

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
0
21
jan.
2021

Hello à toutes et à tous :) !

Je fais face à un problème qui me prend la tête depuis une semaine.

Lorsque je créée un fichier texte par exemple :
echo 'ok' > /data/systeme/test.txt, ce fichier aura pour poids 4ko.

celui-ci se retrouve avec un poids à 0k lorsque je reboot.

Quelqu'un a une idée :)?

Merci d'avance

  • # Ça ne répond pas à la question...

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    … mais 4 ko c'est beaucoup pour 2 octets de données.

    Que donne la comment mount ?

    • [^] # Re: Ça ne répond pas à la question...

      Posté par  . Évalué à 1. Dernière modification le 21 janvier 2021 à 19:47.

      hello
      merci pour ta reponse.
      Je donnais un poids au hasard pour l'exemple ^
      mais chaque document que je créée et avec un poids, se retrouve avec un poids a zero au reboot

      Pour la commande mount: 

          # mount
    /dev/root on / type ext4 (rw,relatime)
    devtmpfs on /dev type devtmpfs (rw,relatime,size=481120k,nr_inodes=120280,mode=755)
    proc on /proc type proc (rw,relatime)
    devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=666)
    tmpfs on /dev/shm type tmpfs (rw,relatime,mode=777)
    tmpfs on /tmp type tmpfs (rw,relatime)
    tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
    sysfs on /sys type sysfs (rw,relatime)
    /dev/mmcblk1p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
    /dev/mmcblk1p4 on /data type ext4 (rw,relatime,errors=remount-ro)

      • [^] # Re: Ça ne répond pas à la question...

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Très étrange. La partition est pourtant en ext4 sans options de montage exotiques donc ça ne devrait pas faire ça. Sauf si ce comportement est lié à une action qui se produit au démarrage uniquement.

        Essaye de créer un fichier, puis de démonter la partition umount /data, et de la remonter ensuite mount /data pour voir si tu reproduis ce comportement sans redémarrer.

      • [^] # Re: Ça ne répond pas à la question...

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        T'arrives à écrire dans /data/… après avoir démarré ? car il est marqué que ce doit être mis en lecture seule en cas de souci. D'ailleurs, il serait bien de faire un check de la partition.

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: Ça ne répond pas à la question...

      Posté par  . Évalué à 2. Dernière modification le 23 janvier 2021 à 18:42.

      … mais 4 ko c'est beaucoup pour 2 octets de données.

      Non, c'est juste la taille d'une page, d'un bloc, d'un cluster. Ça peut se modifier dans le FS soit pour avoir des blocs plus grands (permets de réduire la fragmentation -utile sur disque mécanique!- et diminue l'espace disque consommé par les inodes) ou pour avoir des blocs plus petits (permets de réduire le gâchis d'espace, mais augmente la fragmentation et la zone réservées aux inodes).

      Bon, ok, pour voir ça, il faut utiliser le commutateur -s de ls, par exemple.

  • # fsck ?

    Posté par  . Évalué à 2.

    La partition est peut-être corrompue. Essaye de forcer un fsck sur la partition.

    Suite à un shutdown inopiné (plus de batterie pendant une mise à jour système, le boulet), je me suis retrouvé avec des dizaines de fichiers à 0 octets.

    • [^] # Re: fsck ?

      Posté par  . Évalué à 1.

      merci :)

      je suis sur un système embarqué.
      Je provoque des soft reboot en ligne de commande.
      J'éteins et rallume ma petite carte directement avec son alimentation.

      Je ne comprends pas comment le fichier peut se corrompre alors qu'avant de redémarrer, il est intact. :(

      • [^] # Re: fsck ?

        Posté par  (site web personnel) . Évalué à 2.

        Ce qui est affiché ne correspond pas forcément à ce qu'il y a sur disque, mais à ce qu'il y a dans le cache (RAM). Si le cache n'est pas proprement écrit sur le disque au reboot, alors avant reboot on affiche l'état de la RAM, et après reboot ce qu'il reste, c'est à dire le contenu du disque.

    • [^] # Re: fsck ?

      Posté par  . Évalué à 2.

      je pense que tes conseils me mènent sur la bonne piste :)

      comme dis un peu avant, je suis sur un système embarqué.

      J'ai créé un script pour rebooter la carte (commande reboot -f).
      Et quand je veux l'éteindre électriquement, je débranche l'alimentation électrique.

      En voulant l'éteindre "proprement" avec la commande poweroff j'ai eu ce retour :
      ```
      [ 59.280164] kvm: exiting hardware virtualization

      PANIC at PC : 0x0000000004023248
      ```
      Dans mon script, j'utilise reboot -f car la carte bloquait avec ce message, [ 59.280164] kvm: exiting hardware virtualization,
      et je voulais forcer la carte a redémarrer.

      Donc je pense que dans un premier temps, il faut que j'arrive a éliminer mes deux erreurs citées au dessus et ensuite forcer l'extinction de la carte via la commande poweroff.

      As tu une idée pour mes erreurs :)?

      Merci encore pour ta reflexion

  • # sync

    Posté par  (Mastodon) . Évalué à 8. Dernière modification le 22 janvier 2021 à 08:18.

    et en utilisant sync, tu as le meme soucis ?

    • echo "ok" > fichier
    • sync
    • reboot
    • cat fichier

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: sync

      Posté par  . Évalué à 2.

      Excellent. Ca a résolu mon problème.
      Merci beaucoup :) ^

      • [^] # Re: sync

        Posté par  (Mastodon) . Évalué à 5. Dernière modification le 22 janvier 2021 à 11:48.

        Ça sous entend que ta procédure de reboot est un poil violente, le kernel est censé en faire un et apparemment il ne le fait pas.

        tu parles d'embarqué, je ne sais pas à quel point le portage du kernel est mature sur ta cible, mais méfie-toi pour le coup.

        ou alors c'est peut-être le -f qui cause ça.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: sync

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          Ah oui, le -f n'attend pas que les process en cours se terminent ; y compris de s'assurer que les disques ont fait leurs écritures…

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: sync

            Posté par  . Évalué à 1.

            je pense en effet que c'etait du au petit -f ^
            du coups en forçant le sync, je garde mes infos.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.