core-admin/qubes/storage
Rusty Bird 2b4b45ead8
storage/reflink: preferably get volume size from image size
There were (at least) five ways for the volume's nominal size and the
volume image file's actual size to desynchronize:

- loading a stale qubes.xml if a crash happened right after resizing the
  image but before saving the updated qubes.xml (-> previously fixed)
- restarting a snap_on_start volume after resizing the volume or its
  source volume (-> previously fixed)
- reverting to a differently sized revision
- importing a volume
- user tinkering with image files

Rather than trying to fix these one by one and hoping that there aren't
any others, override the volume size getter itself to always update from
the image file size. (If the getter is called though the storage API, it
takes the volume lock to avoid clobbering the nominal size when resize()
is running concurrently.)
2019-06-23 12:48:00 +00:00
..
__init__.py Make pylint happy 2019-02-27 18:40:18 +01:00
file.py storage/file: gracefully handle not mounted pool 2019-02-27 06:03:57 +01:00
kernels.py storage: add Pool.included_in() method for checking nested pools 2018-03-20 16:53:39 +01:00
lvm.py lvm: run blkdiscard before remove 2019-06-21 18:40:03 -04:00
README.md Merge remote-tracking branch 'marmarek/master' into core3-devel 2016-03-03 01:13:51 +01:00
reflink.py storage/reflink: preferably get volume size from image size 2019-06-23 12:48:00 +00:00

WNI File storage

Before v3.1 there existed a draft wni storage. You can find it in the git history

(it was in /core/storage directory, now gone)