[Haifux] Whole disk encryption, because it costs nothing?

[Maxim Kovgan]

I think you guys always keep forgetting about the gremlins.


On Tue, Jan 12, 2010 at 1:25 PM, Eli Billauer <eli at billauer.co.il> wrote:

> Etzion Bar-Noy wrote:
>
> > Sequential IO is very simple, relatively, so that you will hardly feel
> > the performance impact testing it.
> > Test random IO loads with small packets (0.5K-4K) and you will
> > probably feel the performance impact there.
> >
> It crossed my mind that a sequential test was too simplistic. My ideal
> test would be a database server running like crazy on the data, but this
> is not my application anyhow. I agree that I should test the system
> "under load" but I can't really think about a realistic "under load"
> scenario for 4 hyperthreaded CPUs. At least not something that I could
> test without turning it into a project. So I went for the session below.
>
> /usr is unencypted. /secret is encrypted. My home directory sits on a
> 740 GB ext4 partition, which has seen some activity. /secret and /fresh
> are 20 GB, and are pretty untouched.
>
> The whole system will be reinstalled pretty soon, so I don't care about
> being root and fooling around. ;)
>
> My finding is that encryption still speeds up writes. This is really
> weird. I swear that /fresh was created a minute before I used it on this
> test, so I suppose it can't be in a better shape. Still, writing to
> /secret is faster. The only thing that was slower was removing a lot of
> files in one go.
>
> It's also interesting to note that writing to my home directory was
> considerably slower. So even if encryption turns out to have some
> impact, other factors (partition size? Fragmentation?) seem to be more
> dominant.
>
> So while I still agree with the concept that encryption must surely slow
> down disk writes, my tests show me the contrary.
>
> Insights, anyone?
>    Eli
>
> ---------- Session follows ---------------
>
> [root at short eli]# tar -c /usr | { cd /secret/delete-this/ && time tar -x ;
> }
> tar: Removing leading `/' from member names
> tar: Removing leading `/' from hard link targets
>
> real    5m12.709s
> user    0m2.351s
> sys    0m31.486s
> [root at short eli]# time rm -rf /secret/delete-this
>
> real    0m13.319s
> user    0m0.180s
> sys    0m5.154s
> [root at short eli]# tar -c /usr | { cd /home/eli/delete-this/ && time tar
> -x ; }
> tar: Removing leading `/' from member names
> tar: Removing leading `/' from hard link targets
>
> real    7m0.826s
> user    0m2.344s
> sys    0m32.340s
> [root at short eli]# time rm -rf /home/eli/delete-this
>
> real    0m8.195s
> user    0m0.196s
> sys    0m5.620s
> [root at short eli]# tar -c /usr | { cd /fresh/delete-this/ && time tar -x ;
> }
> tar: Removing leading `/' from member names
> tar: Removing leading `/' from hard link targets
>
> real    5m42.639s
> user    0m2.332s
> sys    0m36.879s
> [root at short eli]# time rm -rf /fresh/delete-this
>
> real    0m9.612s
> user    0m0.203s
> sys    0m6.275s
>
> --
> Web: http://www.billauer.co.il
>
> _______________________________________________
> Haifux mailing list
> Haifux at haifux.org
> http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
>



-- 
Maxim Kovgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://haifux.org/pipermail/haifux/attachments/20100112/3ad31dc9/attachment.html