ReLoad

Thierry Jaouen ~ WikiBlog
"Rien à foutre d'être lu, tant que je peux me relire."

Outils pour utilisateurs

Outils du site


Action disabled: source
blog:2013:04:20:writeback_incident

"writeback" incident

Tiens, et si on ajoutait “data=writeback” a sa partition racine ?

Et BANG : le système demarre en READ ONLY … la cata: impossible de modifier la conf.

~~READMORE~~

En fait, l'incident a eu lieu comme cela.

Dans mon /etc/fstab j'avais simplement ça (extrait) :

/dev/mapper/vg0-system /        ext4    errors=remount-ro 0       1

Pour faire des tests de performances , j'ai simplement ajouté data=writeback , ce qui donne:

/dev/mapper/vg0-system /        ext4    data=writeback,errors=remount-ro 0       1

Et bien NON , ça ne suffit pas. (j'aurai du m'en douter en me rappelant le montage d'un disk SSD)

Au reboot suivant, je suis bloqué sur une partition système en READ-ONLY .

On peut le vérifier , entre autres, en voyant ça:

# mount  | grep system
/dev/mapper/vg0-system on / type ext4 (ro,relatime,user_xattr,barrier=1,data=ordered)

ro (pour readonly) et data=ordered

Et les mount -o remount=rw / ne sont d'aucune aide !!!

# mount -o remount=rw /
mount: /dev/mapper/vg0-system already mounted or / busy
mount: according to mtab, /dev/mapper/vg0-system is already mounted on /

Le problème c'est que dés le boot, par défaut, le noyau monte la partition en data=ordered et qu'il n'est plus possible d'en changer par la suite.
Combiné avec “errors=remount-ro” , le système voyant une erreur, puisqu'il ne peut appliquer l'option data=writeback , il remonte la partition en “read-only”.

Donc, pour le boot suivant, dans grub, il faut ajouter:

rootflags=data=writeback

Ensuite, aprés avoir enfin une partition “Read-Write”, pour rendre cette modification définitive, ajouter dans /etc/default/grub :

GRUB_CMDLINE_LINUX_DEFAULT="rootflags=data=writeback quiet"

Appliquer la modif avec:

# update-grub

Source:

blog/2013/04/20/writeback_incident.txt · Dernière modification : 2013/04/20 22:03 de thierry