5bcd08db289cd02aad8a89b37b2a46244a7bd473 |
|
22-Oct-2015 |
Lennart Poettering <lennart@poettering.net> |
btrfs: beef-up btrfs support with a limited understanding of quota
With this change we understand more than just leaf quota groups for
btrfs file systems. Specifically:
- When we create a subvolume we can now optionally add the new subvolume
to all qgroups its parent subvolume was member of too. Alternatively
it is also possible to insert an intermediary quota group between the
parent's qgroups and the subvolume's leaf qgroup, which is useful for
a concept of "subtree" qgroups, that contain a subvolume and all its
children.
- The remove logic for subvolumes has been updated to optionally remove
any leaf qgroups or "subtree" qgroups, following the logic above.
- The snapshot logic for subvolumes has been updated to replicate the
original qgroup setup of the source, if it follows the "subtree"
design described above. It will not cover qgroup setups that introduce
arbitrary qgroups, especially those orthogonal to the subvolume
hierarchy.
This also tries to be more graceful when setting up /var/lib/machines as
btrfs. For example, if mkfs.btrfs is missing we don't even try to set it
up as loopback device.
Fixes #1559
Fixes #1129 |
8e0b657094c58cb85c4a7c20dd6a1888b38cbb1b |
|
09-Sep-2015 |
Lennart Poettering <lennart@poettering.net> |
machine: when removing, renaming, cloning images also care for .nspawn settings file
Whenever we remove/rename/clone a machine image, make sure we do the
same for the image's .nspawn settings file. |
7e7cddb22493642dad826ec42ac00979f40b2d17 |
|
06-May-2015 |
Seth Jennings <sjenning@redhat.com> |
Fix permissions on /run/systemd/nspawn/locks
machined is getting an EACCES when trying to create the lock file for
images because the mode on /run/systemd/nspawn/locks is 0600.
mkdir("/run/systemd/nspawn/locks", 0600) = -1 EEXIST (File exists)
stat("/run/systemd/nspawn/locks", {st_mode=S_IFDIR|0600, st_size=40, ...}) = 0
open("/run/systemd/nspawn/locks/inode-41:256", O_RDWR|O_CREAT|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC, 0600) = -1 EACCES (Permission denied)
This commit adjusts the mode to 0700 to correct the issue. |
21222ea5cdec65fa30a75bd5a78475459075b946 |
|
22-Apr-2015 |
Lennart Poettering <lennart@poettering.net> |
btrfs-util: introduce btrfs_is_filesystem() and make use of it where appropriate
Let's unify the code that checks whether an fd is on btrfs a bit.
(Also, rename btrfs_is_snapshot() to btrfs_is_subvol(), since that's
usually how this is referred to in our code) |
5f129649b97bdff2bffefcd9c773157843ede6f6 |
|
15-Jan-2015 |
Lennart Poettering <lennart@poettering.net> |
nspawn,machined: change default container image location from /var/lib/container to /var/lib/machines
Given that this is also the place to store raw disk images which are
very much bootable with qemu/kvm it sounds like a misnomer to call the
directory "container". Hence, let's change this sooner rather than
later, and use the generic name, in particular since we otherwise try to
use the generic "machine" preferably over the more specific "container"
or "vm". |
aceac2f0b652dff701e5815c51c2e372e8fee84d |
|
15-Jan-2015 |
Lennart Poettering <lennart@poettering.net> |
import: rename "gpt" disk image type to "raw"
After all, nspawn can now dissect MBR partition levels, too, hence
".gpt" appears a misnomer. Moreover, the the .raw suffix for these files
is already pretty popular (the Fedora disk images use it for example),
hence sounds like an OK scheme to adopt. |
30535c16924a3da7b47ea87190d929d617d95c5a |
|
14-Jan-2015 |
Lennart Poettering <lennart@poettering.net> |
nspawn: add file system locks for controlling access to container images
This adds three kinds of file system locks for container images:
a) a file system lock next to the actual image, in a .lck file in the
same directory the image is located. This lock has the benefit of
usually being located on the same NFS share as the image itself, and
thus allows locking container images across NFS shares.
b) a file system lock in /run, named after st_dev and st_ino of the
root of the image. This lock has the advantage that it is unique even
if the same image is bind mounted to two different places at the same
time, as the ino/dev stays constant for them.
c) a file system lock that is only taken when a new disk image is about
to be created, that ensures that checking whether the name is already
used across the search path, and actually placing the image is not
interrupted by other code taking the name.
a + b are read-write locks. When a container is booted in read-only mode
a read lock is taken, otherwise a write lock.
Lock b is always taken after a, to avoid ABBA problems.
Lock c is mostly relevant when renaming or cloning images. |