On 7/7/06, Daniel Iliev <[EMAIL PROTECTED]> wrote:
A way out of the topic, but its a question that I want to ask.
What is the performance hit of using encrypted file system?
I hate laptops, but you never know ;-)

Not so bad.  I really don't notice any real performance problem using
it, certainly not much worse than a typical laptop HD:

carcharias rjf # hdparm -Tt /dev/sda /dev/sys/swap

/dev/sda:
Timing cached reads:   4096 MB in  1.99 seconds = 2053.20 MB/sec
Timing buffered disk reads:  142 MB in  3.01 seconds =  47.17 MB/sec

/dev/sys/swap:
Timing cached reads:   4848 MB in  1.99 seconds = 2432.13 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device
Timing buffered disk reads:  138 MB in  3.01 seconds =  45.79 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device

The biggest hit is in CPU, and having a dual-core system helps *a lot*
here.  Running  a "dd if=/dev/sys/root of=/dev/null bs=64k" while
running top at the same time shows that kcryptd consumes about 75% of
the processor time on a *single* CPU.

BTW, I also use dm-crypt on my AMD X2 desktop at home.  There I have a
raid0 array which can read at almost 130MB/sec total bandwidth.  If
memory serves, using dm-crypt there cut my read bandwidth down to
about 105MB/s, and writes to 90MB/s.  The issue there seems mostly
that dm-crypt is a single-thread, even when encrypting multiple
devices, so cannot really take advantage of my dual-core processor in
that system.

I think loop-AES gives higher performance on that box due to having
one thread per encrypted device, but it isn't enough for me to worry
about.

Side note: I think it is appalling that government and business
laptops are generally so insecure.  Every week brings news of yet
another laptop theft that contained sensitive data for hundreds of
thousands to millions of people, and oh, btw, we didn't encrypt it
"because it's hard".  Maybe I'm paranoid, but I like knowing that if
my house is ever robbed and my computer stolen, I don't have to worry
that the crooks have all my financial records!

Bug-report...Well I'm very confused here. Isn't it Gentoo the right
place to file
a bug-report at? After all these sources get patched with gentoo
patches. I haven't

Well you can certainly file on bugs.gentoo.org, and let the gentoo
devs work with upstream to find a fix.  And in many cases that is the
right thing to do, so I'll leave it up to you.

My view is that Gentoo devs are all volunteers, and very busy, so if I
come across an issue that is clearly a problem with $upstream, and not
with any gentoo patches or compile options, and I feel confident that
I can communicate properly with $upstream, then I will file the bug
there instead.  The fix can then get filtered down to Gentoo.  In
fact, if it might be awhile before the fix filters down, I would file
a bug both places, with the gentoo one being "please apply patch
referenced in http://bugs.upstream.org/#12345";.

On the other hand gentoo people have masked these sources with "~" so they
could also refuse to take the report (unlikely,but..).

Yeah, unlikely, considering that ~arch is supposed to be for testing!!

them and send bug-reports directly to the mainstream developers who of
course refuse to accept the report because Gentoo has patched their sources

Well, like I said, for me this depends on the nature of the bug.  So
far I've never had $upstream reject a bug report because I was using
Gentoo.  Well, ok, I have, but that was a commercial software company
that just said "try {RedHat,SuSe}".

-Richard
--
gentoo-user@gentoo.org mailing list

Reply via email to