# [ext4] Un premier *couac* ? (identifié)

## El_Goretto

Bonjour,

Bon, je m'avance peut être, mais vu l'état de mon système, je soupçonne fortement une gonade dans le potage côté système de fichiers. Qui est en full ext4 maintenant, youpi.

Les faits: hier, j'ai lancé la MAJ d'OpenOffice, et suis allé faire autre chose pendant qq heures. En revenant, mon bureau était figé, le clic droit marchait encore, puis 1 aller/retour plus tard sur la console, bam, affichage complètement freezé. Bon, mettant ça sur le compte de compiz, je fais la séquence "SUB" des magic sys keys pour rebooter.

Et là, horreur, j'ai des messages debug des scripts init, et surtout, plein de progs refusent de se lancer (KDE, eix, tar) dont certains se plaignent de ne pas trouver libstdc++.so.6. Oui, ça pue velu.

Un coup de sysrescuecd, fsck, puis gcc-config plus tard, mon PC redémarre son KDE.

Maintenant: Sauf que... j'ai un gros doute. Les icônes des applications sont introuvables (en haut des fenêtres dans la barre), les aperçus des thèmes compiz ont disparus, et openoffice me fait une autre jolie erreur sur une autre lib qui me fait flipper: 

```
$ oowriter 

/usr/lib64/openoffice/program/../basis-link/ure-link/bin/javaldx: error while loading shared libraries: /usr/lib64/openoffice/ure/bin/../lib/libjvmfwk.so.3: file too short

/usr/lib64/openoffice/program/soffice.bin: error while loading shared libraries: /usr/lib64/openoffice/program/../basis-link/program/libsfxlx.so: invalid ELF header

```

Ah, et un revdeprebuild qui part en sucette avec:

```
>>> Installing (1 of 1) dev-python/PyQt4-4.4.4-r2

sandbox:main  signal SIGQUIT already had a handler ...

!!! COUNTER file is corrupt: '/var/cache/edb/counter'

!!! invalid literal for long() with base 10: ''

!!! Initializing COUNTER to value of 2832

```

fsck -f sur / n'avait rien montré, pas d'erreur sur le contrôleur RAID... Ouinouin XP va bien pour le moment, donc je n'accuse pas le contrôleur.

Question: vous auriez une idée sur la façon de mettre en évidence un crash FS si fsck ne remonte rien?

Des infos:

```
# mount

/dev/sdc2 on / type ext4 (rw,noatime)

/proc on /proc type proc (rw)

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)

udev on /dev type tmpfs (rw,nosuid,size=10240k,mode=755)

devpts on /dev/pts type devpts (rw,nosuid,noexec,gid=5,mode=620)

/dev/mapper/vg_raid_os-lv_home on /home type ext4 (rw,noatime)

/dev/mapper/vg_raid_data-lv_data on /opt/data type ext4 (rw,noatime)

/dev/sde on /usr/portage type xfs (rw,noatime)

none on /var/tmp/portage type tmpfs (rw)

/dev/mapper/vg_raid_data-lv_vmware on /vmware_VMs type ext4 (rw,noatime,acl)

/dev/mapper/vg_raid_data-lv_vms on /VMs type ext4 (rw,noatime,acl)

/dev/sdh1 on /mnt/backup_local type xfs (rw,noatime)

none on /proc/bus/usb type usbfs (rw)

none on /dev/shm type tmpfs (rw)

binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)

```

```
$ df -h

Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur

/dev/sdc2              19G   11G  6,7G  62% /

udev                   10M  180K  9,9M   2% /dev

/dev/mapper/vg_raid_os-lv_home

                      6,9G  5,3G  1,3G  81% /home

/dev/mapper/vg_raid_data-lv_data

                       99G   49G   50G  50% /opt/data

/dev/sde               15G  8,9G  6,0G  60% /usr/portage

none                  2,0G     0  2,0G   0% /var/tmp/portage

/dev/mapper/vg_raid_data-lv_vmware

                      8,9G  7,2G  1,3G  86% /vmware_VMs

/dev/mapper/vg_raid_data-lv_vms

                       15G  4,6G   11G  32% /VMs

/dev/sdh1             789G  189G  601G  24% /mnt/backup_local

none                  2,0G     0  2,0G   0% /dev/shm
```

A part espérer que les FS contenant les données sont indemne et balourder une gros "emerge -e world", je ne vois pas trop quoi faire.

edit: mon cas semble être un scénario tristement classique: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781

----------

## titoucha

Je ne vois pas trop mais avec les outils SMART ?

----------

## Kazuya

Hello,

Juste comme ça, tu utilises quelle version du kernel ?!

Car au passage dans le Changelog de gentoo-source:

 *Quote:*   

> 
> 
> *gentoo-sources-2.6.29-r2 (29 Apr 2009)
> 
>   29 Apr 2009; Mike Pagano <mpagano@gentoo.org>
> ...

 

Moi qui voulait passer ma /home en ext4, tu viens de m'en dissuader...

----------

## El_Goretto

 *Kazuya wrote:*   

> Hello,
> 
> Juste comme ça, tu utilises quelle version du kernel ?!
> 
> Car au passage dans le Changelog de gentoo-source:
> ...

 

HAHAHAHAHahaheheheh, hum

Ben la gentoo-sources-2.6.28-r1, bien sûr.

RAAAAHHH.

Ok, bon, j'étais trop flippé à faire l'état des lieux de ma bécane que j'ai pas suivi le changelog. La R5 est d'ailleurs la première 2.6.28 à passer en stable. J'imagine que c'est la même fournée de fix que dans le bug report Ubuntu.

Bon, mes données sont sur un FS à part (en ext4 toujours, certes), je n'ai pas trouvé de fichiers de taille 0 dans mes données propres (quelques fichiers parmi ceux de conf, qui étaient peut être déjà vides). On va dire que tout va bien.

Je vous tiens au courant si ça remerdoie.

Et un emerge -e world pour cette nuit, un...

----------

## El_Goretto

Oui, bon, en fait ya plein de patches pour ext4, dont les noms font peur.

C'est sûrement celui là qui m'aurait été utile:

```
*gentoo-sources-2.6.28-r4 (19 Mar 2009)

  19 Mar 2009; Mike Pagano <mpagano@gentoo.org>

  +gentoo-sources-2.6.28-r4.ebuild:

  X.org PPC fix. Generic journaling for block device fix. Support for PAC207

  webcam. Linux 2.6.28.8. Ext4 data loss on crash prevention patches.

```

----------

## xaviermiller

Je penche surtout pour /var/tmp qui est saturé. Il faut des GIGAS d'espace libre pour compiler OOo  :Wink: 

----------

## El_Goretto

 *XavierMiller wrote:*   

> Je penche surtout pour /var/tmp qui est saturé. Il faut des GIGAS d'espace libre pour compiler OOo 

 

Erf, je m'ai gouré dans mon copier collé et ai fourni 2 fois les infos mount:

```
$ df -h

Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur

/dev/sdc2              19G   11G  6,7G  62% /

udev                   10M  180K  9,9M   2% /dev

/dev/mapper/vg_raid_os-lv_home

                      6,9G  5,3G  1,3G  81% /home

/dev/mapper/vg_raid_data-lv_data

                       99G   49G   50G  50% /opt/data

/dev/sde               15G  8,9G  6,0G  60% /usr/portage

none                  2,0G     0  2,0G   0% /var/tmp/portage

/dev/mapper/vg_raid_data-lv_vmware

                      8,9G  7,2G  1,3G  86% /vmware_VMs

/dev/mapper/vg_raid_data-lv_vms

                       15G  4,6G   11G  32% /VMs

/dev/sdh1             789G  189G  601G  24% /mnt/backup_local

none                  2,0G     0  2,0G   0% /dev/shm
```

Sachant que /var/tmp/portage à 2Go ne suffit pas pour compiler OOo, donc je le démonte temporairement (pour que ça aille temporairement dans le FS de / où il y a suffisamment d'espace). Ceci étant, même un FS full ne s'auto-corrompt pas tout seul (enfin, j'espère...), et encore moins n'apparaît  plus comme full au reboot suivant  :Smile:  (au vidage de /tmp près).

Donc je vote, OK, la compil' OOo aurait pu saturer le FS, mais le bug ext4 "m'a tuer". D'accord?  :Smile: 

----------

