Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
Fedora and LVM
Posted Nov 1, 2012 23:55 UTC (Thu) by marcH (subscriber, #57642)
I'm not actually asking about the user interface or about how many times you type this or that but about the internal design. Once I understand the design I (we) will be able to draw my (our) own conclusions :->
Posted Nov 2, 2012 1:15 UTC (Fri) by lacos (subscriber, #70616)
/dev/sda1 is plaintext boot.
In experiment (a), /dev/sdb2 was handed to dm-crypt (--> /dev/mapper/luks-UUID), which was then formatted as the single PV in a VG, having three LVs (/, /home, and swap). In this case a single password is used.
In experiment (b), /dev/sdb2 was formatted as a single PV in a VG. Three LVs were created, individually encrypted with dm-crypt (using the same password), and then the three separate luks-UUID devices were formatted as /, /home, and swap. The boot process still only asks for "the" password once.
(Unfortunately, the real goal of this experimentation was not reached. The goal was to see if separately encrypting block devices (ie. in exp. (b)) would keep kcryptd from merging "request streams" targeting those separate devices, before they reach the IO scheduler. Alas, it's insufficient; as far as I understand, kcryptd instances (kernel threads?) are spawned per-CPU, not per-device, and whatever requests a given kcryptd instance issues looks same-origin to the IO scheduler, ie. serialized.
Even in experiment (b), an fsync() that follows a big, scattered write on "/" blocks a read request targeting "/home". I've seen stalls as long as 13 seconds on my laptop.
But it's my understanding that this is being worked on.)
Posted Nov 5, 2012 10:26 UTC (Mon) by mstefani (subscriber, #31644)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds