Re: no deprecation of /usr as a standalone filesystem
Pierre Habouzit <madcoder@madism.org> writes:
> On Mon, Jun 01, 2009 at 01:11:20PM +0200, Goswin von Brederlow wrote:
>> Josselin Mouette <joss@debian.org> writes:
>> > > - LVM and/or RAID: no real reason nowadays to not use these for the root
>>
>> As long as debian does not provide support for kernel independent non
>> breaking initramfs support (i.e. not regenerated on every whim and
>> break) having / outside lvm and no initramfs is a real plus.
>
> You meant /boot right ?
No, /. Where /boot is has no effect on wether you need an initrd or
not. That only interests the bootloader.
>> You can not mount / nodev if you don't use udev. But you /usr you can.
>> What I'm trying to say is that read-only is not the only option that
>> can differ between / and /usr.
>
> What's the purposes of mounting /usr nodev as all directories there are
> owned by root (or at least should be) ?
Only allow what is neccessary. That way when accidentally some device
node lands in /usr it still can't be abused. For example someone could
sneak in a package into Debian that contains
crw-rw-rw- 1 root kmem 1, 1 May 30 15:55 /usr/lib/rootkit/mem
crw-rw-rw- 1 root kmem 1, 2 May 30 15:55 /usr/lib/rootkit/kmem
>> >> - dmcrypt: not crypting /usr is just an optimization. E.g. on my laptop
>> >> I decided to crypt only /home, and use symlinks for the few files in
>> >> /etc which contain sensitive information, YMMV.
>> >
>> > Iâ??m the only one who quoted it, and I already find this is a minor use
>> > case.
>>
>> Count me there too. Crypting /usr on a laptop just wastes performance
>> and cpu which spells into real battery life. Although ecryptfs is
>> probably a even better alternative.
>
> Give me numbers please, crypting /usr in my experience wastes little
> amount of CPU given that the in-ram cache is _not_ encrypted, so as long
> you don't hit the disk, it costs almost nothing.
Agreed. If it is cached it doesn't matter. IF. Most peoples /usr
partition is by far larger than available ram not to mention only a
part of that is used for cache. My old laptop only had 128MB
ram. Forget about caching there.
> And as soon as you hit the disk, I'm told that the disk consumptions in
> nowadays hardware wins over the CPU one from decryption. (I don't count
> encryption as you usually very seldomly _write_ to /usr except when you
> upgrade or install packages).
Cpu frequency scalled up all the way in both cases for the test:
root@frosties:~# time dd if=/dev/sdc of=/dev/null bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 46.6188 s, 92.1 MB/s
dd if=/dev/sdc of=/dev/null bs=1M count=4096 0.01s user 8.35s system 17% cpu 46.737 total
root@frosties:~# time dd if=/dev/mapper/sdc-crypt of=/dev/null bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 56.5635 s, 75.9 MB/s
dd if=/dev/mapper/sdc-crypt of=/dev/null bs=1M count=4096 0.02s user 8.66s system 15% cpu 56.806 total
Despite that it says only 15% system is used in the case of sdc-crypt
all the remaining cpu power is used up by:
2651 root -5 0 0 R 78.7 0.0 1:00.28 kcryptd
Those 78% means that the cpu goes into full speed. The voltage and
frequency is increased. The cpu fan spins up to a higher setting. The
time spend in kcryptd is also stolen from e.g. gcc or ld. Compiling takes
longer, esspecially the first time. The CPU stays in full speed for
longer eating more power.
For me the "takes longer" part is actually more important. That even
holds when you are not running on battery. I don't have numbers on the
battery life as I never compared the time with and without
dm-crypt. Feel free to time it yourself.
MfG
Goswin
Reply to: