|
Authored by: Anonymous on Sunday, November 11 2012 @ 05:23 AM EST |
True but for the seriously paranoid it is the only way to be sure something
won't be visible in a cache, or in a log or temp file. There are services
logging all sorts of stuff these days. Yes there are ways to tell them to ignore
certain files or not log certain things. But there are so many places things get
logged or backed up it is easy to slip up and forget something. If you have
confidential stuff the only way to be really sure of no leaks is to encrypt the
lot.
For example zeitgeist seems implacably determined to index every file you touch
and everything you do; the location service seems implacably determined to log
your physical location every couple of seconds. Your browser is implacably
determined to cache everything; as is your media player. Etc. So many logging
caching things. [ Reply to This | Parent | # ]
|
|
Authored by: yacc on Monday, November 12 2012 @ 06:15 AM EST |
Well, if it's so, you've got something wrong with the
encryption.
For practically any modern PC encryption is a trivial load,
especially if you compare it to hdd access times. Basically,
even my old (and it was not a high end one when I bought it
either) AMD box manages to decrypt 100MB/s.
For filesystem browsing the most relevant issues involve
seeking time (because the directories are most probably not
stored sequentially at one place), and filesystem code, e.g.
some filesystems are better at handling huge directories
than others. Additionally depending upon your OS/tools
involved, the file browser might want to probe the files as
such to determinate their contents, even more seeking.
As to the reason why a backup, and restore to a new system
without encryption produced a speed up => if you did the
backup on file level (e.g. tar on Unix), the restoring
operation produced a nearly perfectly defragmented,
sequentially layed out filesystem content.
To put it to numbers, using an average seek time of 10ms, my
box can easily decrypt around 1MB during this time, using
only one of it's 4 cores. Reads of 1MB are seldom, e.g. on
my hdd it defaults to 128KB read ahead.
So what do you need for speedy file browsing no matter what?
Basically a good (good nowadays implies avoid the buggy
ones) SSD.
For example, my PC is currently backing up my SSD via a lvm
snapshot, the SSD is doing 1000-2000 io transactions per
second, and I don't really notice that, because my normal
operating needs are a tiny compared to it's capacity for
random access. Try the same with a normal hdd, and the PC
will slow down to a crawl, as normal hdd (again based on the
10ms average) can handle roughly 100 transactions per
second, even with considering the scheduling optimizations
that Linux applies, they seldom manage more than 200
transactions per second (how? simple by sorting the access
locations, the seek time on average is lower than the quoted
"average seek time" which is derived on seeking from a
random location to another random location.)
[ Reply to This | Parent | # ]
|
|
|
|
|