[BTRFS] Quel partitionnement choisir ? (Résolu)

[JPEC]

BTRFS n'étant plus considéré comme expérimental et commençant à se stabiliser, ça me donne envie de l'essayer… Mon SSD de 128Go est actuellement partitionné de façon classique :

Code : Tout sélectionner

/boot - 512Mo     (EXT2)
/     - 25Go      (EXT4)
SWAP  - 8Go
/home - le reste  (EXT4)

J'envisage de passer sous BTRFS mais plusieurs questions se posent :

1) Comme mon Thinkpad boote en mode BIOS du coup je n'ai pas à créer une partition EXT2 pour /boot ?
2) Qu'est-ce qui est le mieux entre créer une partion BTRFS pour tout le disque puis créer des sous volumes ou créer plusieurs partitions ?
3) J'ai 8Go de RAM par contre j'utilise l'hibernation : faut-il une partition SWAP dédiée ou un SWAPFILE sur BTRFS fonctionne bien ?
4) Quel partitionnement me conseillez vous pour un SSD de 128Go ?
5) Comme le disque est un SSD, quelles sont les options à activer pour augmenter la durée de vie ?

Par avance, merci.

[JPEC]

J'oubliais, j'aimerais aussi chiffrer le disque.

[Moviuro]

Plop,

J'ai une config similaire mais je n'utilise pas l'hibernation, donc je n'ai pas de swap. J'utilise en plus BTRFS over LUKS, et UEFI donc mon /boot est à part.
EDIT : /boot à part pour toi aussi.

Clairement, c'est un no-brainer :

Code : Tout sélectionner

/boot - 500Mo (j'ignore quelles possibilités pour assurer le boot d'un vrai kernel par contre, moi j'ai secureboot)
swap  -   8Go (j'ignore comment ça marche avec LUKS, mais ça m'intéresse)
Container LUKS/dm-crypt pour le reste
 -> BTRFS par dessus
     -> root
         -> var (pour ne pas l'inclure dans les snapshots)
         -> home (pour avoir une fréquence de snapshots différente que /)
     -> backup (dans lequel il y a mes sauvegardes de sous-volumes, cf au-dessus)

Swap chiffrée avec hibernation : https://wiki.archlinux.org/index.php/Dm ... sk_support
Avantage des sous-volumes : pas de quota obligatoire, le sous-volume prend la place dont il a besoin ; les snapshots ne sont pas récurssifs.
BTRFS honore le flag/attribut c (man 1 chattr) donc tes données sont compressées sur le disque et accessibles de manière transparente.
https://wiki.archlinux.org/index.php/Dm ... _with_LUKS <- et au lieu de mkfs.ext4 tu utilises mkfs.btrfs.

Extrait de mon syslinux.cfg :

Code : Tout sélectionner

LABEL arch
    MENU LABEL ArchLinux
    LINUX ../vmlinuz-linux
    APPEND cryptdevice=UUID=e39da0aa-e582-47cf-b2cf-811b1a9374fc:luks-e39da0aa-e582-47cf-b2cf-811b1a9374fc root=UUID=89d8124b-9279-4a38-91f6-f743033465a9 rw quiet
    INITRD ../initramfs-linux.img

Et autres trucs intéressants :

Code : Tout sélectionner

root@schizophrenia ~ # blkid /dev/sdb
/dev/sdb: PTUUID="2ec0e5b4-4d32-11e3-8d33-904ce5853622" PTTYPE="gpt"
root@schizophrenia ~ # blkid /dev/sdb1 # /boot
/dev/sdb1: SEC_TYPE="msdos" UUID="512D-340B" TYPE="vfat" PARTLABEL="Linux filesystem" PARTUUID="17e75d7e-ad6f-467a-b8ee-0b4a76ea1a4a" 
root@schizophrenia ~ # blkid /dev/sdb2 # la partition LUKS
/dev/sdb2: UUID="e39da0aa-e582-47cf-b2cf-811b1a9374fc" TYPE="crypto_LUKS" PARTLABEL="Linux filesystem" PARTUUID="4b525250-f656-4d54-86a0-ac5a53a946a1"
root@schizophrenia ~ # blkid /dev/dm-0 
/dev/dm-0: UUID="89d8124b-9279-4a38-91f6-f743033465a9" UUID_SUB="f97e3898-350b-4460-aa5e-5d96bf22be6c" TYPE="btrfs" 
root@schizophrenia ~ # blkid /dev/mapper/luks-e39da0aa-e582-47cf-b2cf-811b1a9374fc
/dev/mapper/luks-e39da0aa-e582-47cf-b2cf-811b1a9374fc: UUID="89d8124b-9279-4a38-91f6-f743033465a9" UUID_SUB="f97e3898-350b-4460-aa5e-5d96bf22be6c" TYPE="btrfs"

EDIT:
Et pour le fstab:

Code : Tout sélectionner

# /dev/mapper/luks-e39da0aa-e582-47cf-b2cf-811b1a9374fc
UUID=89d8124b-9279-4a38-91f6-f743033465a9       /               btrfs           rw,relatime,space_cache 0 0
UUID=89d8124b-9279-4a38-91f6-f743033465a9       /mnt/backup     btrfs           rw,relatime,space_cache,subvol=backup   0 0

Et pour le SSD, options noatime,ssd,compress=lzo,discard dans le fstab ; il n'y a rien dans le crypttab.

En espérant que ça aide

[JPEC]

Merci Moviuro,

En réfléchissant bien, je n'utilise quasiment jamais l'hibernation donc je peux me passer de SWAP (le démarre est quasiment aussi rapide que le reveil).

Du coup je partirais sur un /boot séparé et un conteneur LUKS.

Dans ton conteneur LUKS, pour être sur d'avoir tout compris :

root et backup sont des partitions BTRFS ou des sous-volumes ?
var et home sont des sous-volumes ?

Sais tu si le layout bépo est supporté par DM_CRYPT pour taper le mot de passe ?

[Moviuro]

Tout est sous-volume : BTRFS occupe tout /dev/sdb2. Regarde les numéros "Top level" pour voir les relations père-fils.

Code : Tout sélectionner

# btrfs subvolume list /                                  
ID 257 gen 98849 top level 5 path root
ID 258 gen 97001 top level 5 path backup
ID 259 gen 98857 top level 257 path var
ID 260 gen 98857 top level 257 path home
ID 515 gen 96933 top level 258 path backup/2014-04-16/root_vol

J'ai un pote sous Fedora avec ext4 over LUKS qui entre sa passphrase LUKS en bépo, donc oui, ça doit pouvoir se configurer quelque part (genre, au pif, un hook dans mkinitcpio.conf)

[JPEC]

OK merci pour les réponses ! Je vais essayer de faire ça ce weekend !

[JPEC]

Pour tes backups, tu as un script ?

[Moviuro]

oui, dans un timer systemd, lancé une fois par semaine :

Code : Tout sélectionner

#!/bin/sh
BAK=/mnt/backup
DIR=$(date --iso-8601)
mkdir -p $BAK/$DIR
btrfs subvolume snapshot -r / $BAK/$DIR/root_vol

Mais j'attends impatiemment que snapper vienne avec ses propres units systemd. (https://www.archlinux.org/packages/comm ... 4/snapper/)

[JPEC]

OK merci !

[benjarobin]

Si on veut jouer sur les mots, ce n'est pas un backup au sens strict du terme, car s'il y a une défaillance au niveau matériel ou si le système de fichier est corrompu les snapshot ne sont pas récupérable. Cela permet "juste" de revenir en arrière très facilement. Et il faut l'avouer c'est une fonctionnalité très sympa.

[Moviuro]

Vrai, pour les backups, faut utiliser un truc comme rsync, unison ou duplicity.

(D'ailleurs, mon service s'appelle "snap")

[JPEC]

Merci pour vos réponses (et Moviuro sur IRC). Ma migration s'est bien passée !

Le seul bémol c'est que la disposition bépo n'est pas supportée correctement par le hook keymap et on est obligé de rester en QWERTY pour le mot de passe de déchiffrement. Voir le rapport de bug : FS#40756 - [mkinitcpio] Keymap fr-bepo seems broken.