Wiki

Ez az oldal csak olvasható. Megtekintheted a forrását, de nem változtathatod meg. Ha úgy gondolod, hogy ez helytelen, kérdezd az Adminisztrátorokat!
=== BTRFS subvolume parancsok ===

  btrfs subvolume list
  btrfs subvolume create valami
  btrfs subvolume snapshot valami valami-2020-01-02

=== BTRFS subvolume-ok logikája (részleges) ===
Alapból létezik egy 5-ös id-jú btrfs subvolume, kezdetben ez a default subvolume, ami az igazi "gyökeret" tartalmazza, ilyenek vannak benne (pl. timeshift használatát feltételezem):

  @
  @cache
  @home
  @log
  timeshift-btrfs
    |-snapshots
    |-snapshots-daily
    |    |-<dátum>
    |    ..    |-@
    |    ..    |-@home
    |-...

Mivel a timeshift épít arra, hogy ez a default subvol, nem érdemes átállítani a default subvolume-ot másra, csak ha muszáj.

=== Visszaállás BTRFS snapshot subvolume-ra ===
(Itt a / visszaállítását írom le.)

Ha az fstab-od úgy van beállítva, hogy a @ legyen felmountolva a /-be:

  ... /              btrfs   subvol=/@,...
  
akkor a legegyszerűbb az, ha a jelenlegi @-ot átnevezed valami másra, majd a kívánt snapshotot átnevezed @-ra.
<code bash>
  mount /dev/nvme0n1p5 /mnt/btrfs  # ilyenkor a default subvolume-ot fogja felmountolni
  mv /mnt/btrfs/@ /mnt/btrfs/@_latest_root
  mv /mnt/btrfs/<snapshot-neve>/@ /mnt/btrfs/@
</code>
Ezután rebootkor a snapshotot fogja felbootolni a gép, és mehet tovább minden. Ha minden oké, akkor a régi @_latest_root-ot lehet törölni, illetve minden más snapshotot, ami már nem kell.

=== BTRFS subvolume (snapshot) törlése ===
<code bash>
  btrfs subvolume list
  # feljegyezni az id-t : pl 123
  mount -o subvol=@valami /dev/sdb /mnt
  btrfs subvolume delete -c -i 123 /mnt   # -c = commit, -i = identifer
</code>
=== BTRFS no space left on device ===

source: [[https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/FAQ.html#if_your_device_is_large_.28.3E16GiB.29]]

If the filesystem has allocated (but not used) all of the available space, and the metadata is close to full, then df can show lots of free space, but you may still get out of space errors because there isn't enough metadata available.

To see if this is the case, first look for the amount of allocated space with
<code bash>
  sudo btrfs fi show /dev/device
</code>
If this shows the "used" value equal to the "total" value on each device, then everything has been allocated, which is the first condition for this problem.

Secondly, look at the amount of space you have in metadata, as reported by
<code bash>
  btrfs fi df /mountpoint
</code>
If the "used" metadata is close to the "total" value, then that's the second condition for this problem, and you should read on. What does "close" mean? If the free space in metadata is less than or equal to the block reserve value (typically 512 MiB, but might be something else on a particularly small or large filesystem), then it's close to full.

If you have full up metadata, and more than 1 GiB of space free in data, as reported by btrfs fi df, then you should be able to free up some of the data allocation with a partial balance:
<code bash>
  btrfs balance start /mountpoint -dlimit=3
</code>
We know this isn't ideal, and there are plans to improve the behavior. Running close to empty is rarely the ideal case, but we can get far closer to full than we do.

=== BTRFS quota, lassulás, timeshift ===

A BTRFS quota funkciója nem túl megbízható, durva lassulásokat tud okozni. Ezért érdemes kikapcsolni.

A Timeshift hajlamos automatikusan bekapcsolni a quota funkciót, mert az szükséges a snapshotok "unshared" értékének megjelenítéséhez.

Szerintem megéri lemondani erről a funkcióról, mert nagyon nagy impact a quotázás, és annyit nem ér, hogy lássuk, mekkora helyet foglal egy snapshot.

  # btrfs qgroup show /
  # btrfs quota disable /
  # btrfs qgroup show /