1 |
On 7/7/06, Daniel Iliev <danny@××××××××.com> wrote: |
2 |
> A way out of the topic, but its a question that I want to ask. |
3 |
> What is the performance hit of using encrypted file system? |
4 |
> I hate laptops, but you never know ;-) |
5 |
|
6 |
Not so bad. I really don't notice any real performance problem using |
7 |
it, certainly not much worse than a typical laptop HD: |
8 |
|
9 |
carcharias rjf # hdparm -Tt /dev/sda /dev/sys/swap |
10 |
|
11 |
/dev/sda: |
12 |
Timing cached reads: 4096 MB in 1.99 seconds = 2053.20 MB/sec |
13 |
Timing buffered disk reads: 142 MB in 3.01 seconds = 47.17 MB/sec |
14 |
|
15 |
/dev/sys/swap: |
16 |
Timing cached reads: 4848 MB in 1.99 seconds = 2432.13 MB/sec |
17 |
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate |
18 |
ioctl for device |
19 |
Timing buffered disk reads: 138 MB in 3.01 seconds = 45.79 MB/sec |
20 |
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate |
21 |
ioctl for device |
22 |
|
23 |
The biggest hit is in CPU, and having a dual-core system helps *a lot* |
24 |
here. Running a "dd if=/dev/sys/root of=/dev/null bs=64k" while |
25 |
running top at the same time shows that kcryptd consumes about 75% of |
26 |
the processor time on a *single* CPU. |
27 |
|
28 |
BTW, I also use dm-crypt on my AMD X2 desktop at home. There I have a |
29 |
raid0 array which can read at almost 130MB/sec total bandwidth. If |
30 |
memory serves, using dm-crypt there cut my read bandwidth down to |
31 |
about 105MB/s, and writes to 90MB/s. The issue there seems mostly |
32 |
that dm-crypt is a single-thread, even when encrypting multiple |
33 |
devices, so cannot really take advantage of my dual-core processor in |
34 |
that system. |
35 |
|
36 |
I think loop-AES gives higher performance on that box due to having |
37 |
one thread per encrypted device, but it isn't enough for me to worry |
38 |
about. |
39 |
|
40 |
Side note: I think it is appalling that government and business |
41 |
laptops are generally so insecure. Every week brings news of yet |
42 |
another laptop theft that contained sensitive data for hundreds of |
43 |
thousands to millions of people, and oh, btw, we didn't encrypt it |
44 |
"because it's hard". Maybe I'm paranoid, but I like knowing that if |
45 |
my house is ever robbed and my computer stolen, I don't have to worry |
46 |
that the crooks have all my financial records! |
47 |
|
48 |
> Bug-report...Well I'm very confused here. Isn't it Gentoo the right |
49 |
> place to file |
50 |
> a bug-report at? After all these sources get patched with gentoo |
51 |
> patches. I haven't |
52 |
|
53 |
Well you can certainly file on bugs.gentoo.org, and let the gentoo |
54 |
devs work with upstream to find a fix. And in many cases that is the |
55 |
right thing to do, so I'll leave it up to you. |
56 |
|
57 |
My view is that Gentoo devs are all volunteers, and very busy, so if I |
58 |
come across an issue that is clearly a problem with $upstream, and not |
59 |
with any gentoo patches or compile options, and I feel confident that |
60 |
I can communicate properly with $upstream, then I will file the bug |
61 |
there instead. The fix can then get filtered down to Gentoo. In |
62 |
fact, if it might be awhile before the fix filters down, I would file |
63 |
a bug both places, with the gentoo one being "please apply patch |
64 |
referenced in http://bugs.upstream.org/#12345". |
65 |
|
66 |
> On the other hand gentoo people have masked these sources with "~" so they |
67 |
> could also refuse to take the report (unlikely,but..). |
68 |
|
69 |
Yeah, unlikely, considering that ~arch is supposed to be for testing!! |
70 |
|
71 |
> them and send bug-reports directly to the mainstream developers who of |
72 |
> course refuse to accept the report because Gentoo has patched their sources |
73 |
|
74 |
Well, like I said, for me this depends on the nature of the bug. So |
75 |
far I've never had $upstream reject a bug report because I was using |
76 |
Gentoo. Well, ok, I have, but that was a commercial software company |
77 |
that just said "try {RedHat,SuSe}". |
78 |
|
79 |
-Richard |
80 |
-- |
81 |
gentoo-user@g.o mailing list |