Misalignment of volatile LVs?

[brendanhoar]

Qubes OS version
R4.01 (current-testing)

Affected component(s) or functionality
Volatile LVs

Brief summary
Just by happenstance, while prepping some devices for new installs, I happened to type fdisk -l into the wrong window, and looked at the output of fdisk -l in dom0, which flagged the alignment issues in red.

To Reproduce

dom0% sudo fdisk -l
...
Device                                              Boot Start     End Sectors Size Id Type
/dev/mapper/qubes_dom0-vm--disp3379--volatile-part1          1 2097152 2097152   1G 82 Linux swap / Solaris

Partition 1 does not start on physical sector boundary.
...

Expected behavior
Start sector/block should be 0, not 1.

Actual behavior
Start is 1

Additional context
This is non-optimal from a SSD perfomance and device lifetime perspective, though I'm not sure how that interacts with the LVs being hosted on a thin-pool with 64KB clusters.

B

[brendanhoar]

Update: if 0 is not possible (I have read that LV should have a MBR block 0 partition table to prevent corruption of volume by poorly written tools), then probably something like 2048 would be better from an alignment perspective, even if it "wastes" space temporarily.

Unless someone has more wisdom on this than I, of course.

B

Updated to list only the current linux standard of 1MB (block no. 2048 w/ 512B blocks) alignment.

[marmarek]

Slightly related: #4974

[xaki23]

this seems actualy a bit silly. i did some rapid tests against the volatile of a vm on a raid1-of-two-ssds.

dom0 says in fdisk-l on the /dev/mapper/blahbla-volatile:
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 65536 bytes / 65536 bytes

so no weird sector sizes or anything.
but fdisk (only in dom0, not in fc29 vms) will complain about this "does not start on a physical sector boundary" unless i make the start a multiple of 64kb.

aligining the swap to 1MB might really be the sanest option there. (and as long we are talking lvm-thin with no more than 1MB blocksize, it doesnt really even waste that one mb)

[brendanhoar]

aligining the swap to 1MB might really be the sanest option there. (and as long we are talking lvm-thin with no more than 1MB blocksize, it doesnt really even waste that one mb)

Ha! I didn't even think of this.

If we skip forward to the 1MB for the partition, then at most one cluster will be written before that mark (for the partition table), so unless the LVM host VG is rather large, most of the 1MB will be unallocated anyway.

[qubesos-bot]

Automated announcement from builder-github

The package qubes-utils_4.1.2 has been pushed to the r4.1 testing repository for the Debian template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing (or appropriate equivalent for your template version), then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package python2-qubesimgconverter-4.1.2-1.fc29 has been pushed to the r4.1 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package linux-utils has been pushed to the r4.1 testing repository for the CentOS centos7 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.1-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package linux-utils has been pushed to the r4.0 testing repository for the CentOS centos7 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package python2-qubesimgconverter-4.0.26-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-utils_4.0.26 has been pushed to the r4.0 testing repository for the Debian template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing (or appropriate equivalent for your template version), then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-utils_4.0.26+deb9u1 has been pushed to the r4.0 stable repository for the Debian template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package python2-qubesimgconverter-4.0.26-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package linux-utils has been pushed to the r4.0 stable repository for the CentOS centos7 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update