Re: [gentoo-user] Getting maximum space out of a hard drive

[William Kenworthy <billk@iinet.net.au>]

What are you measuring the speed with - hdparm or rsync or ?

hdparm is best for profiling just the harddisk (tallks to the interface 
and can bypass the cache depending on settings, rsync/cp/?? usually have 
the whole OS storage chain including encryption affecting throughput.  
Encryption itself can be highly variable depending on what you use and 
usually though not always includes compression before encryption.  There 
are tools you can use to isolate where the slowdown occurs.  atop is 
another one that may help.

[test using a USB3 shingled drive on a 32 it arm system]

xu4 ~ # hdparm -Tt /dev/sda
/dev/sda:
  Timing cached reads:   1596 MB in  2.00 seconds = 798.93 MB/sec
  Timing buffered disk reads: 526 MB in  3.01 seconds = 174.99 MB/sec
xu4 ~ #

BillK

On 21/8/22 06:45, Dale wrote:
> Grant Taylor wrote:
>> Sorry for the duplicate post.  I had an email client error that
>> accidentally caused me to hit send on the window I was composing in.
> I figured it was something like that.  ;-)
>
>> On 8/20/22 1:15 PM, Dale wrote:
>>> Howdy,
>> Hi,
>>
>>> Related question.  Does encryption slow the read/write speeds of a
>>> drive down a fair amount?
>> My experience has been the opposite.  I know that it's unintuitive
>> that encryption would make things faster.  But my understanding is
>> that it alters how data is read from / written to the disk such that
>> it's done in more optimized batches and / or optimized caching.
>>
>> This was so surprising that I decrypted a drive / re-encrypted a drive
>> multiple times to compare things to come to the conclusion that
>> encryption was noticeably better.
>>
>> Plus, encryption has the advantage of destroying the key rendering the
>> drive safe to use independent of the data that was on it.
>>
>> N.B. The actual encryption key is encrypted with the passphrase.  The
>> passphrase isn't the encryption key itself.
>>
>>> This new 10TB drive is maxing out at about 49.51MB/s or so.
>> I wonder if you are possibly running into performance issues related
>> to shingled drives.  Their raw capacity comes at a performance penalty.
> This drive is not supposed to be SMR.  It's a 10TB and according to a
> site I looked on, none of them are SMR, yet.  I found another site that
> said it was CMR.  So, pretty sure it isn't SMR.  Nothing is 100% tho.  I
> might add, it's been at about that speed since I started the backup.  If
> you have a better source of info, it's a WD model WD101EDBZ-11B1DA0 drive.
>
>
>>> I actually copied that from the progress of rsync and a nice sized
>>> file.  It's been running over 24 hours now so I'd think buffer and
>>> cache would be well done with.  LOL
>> Ya, you have /probably/ exceeded the write back cache in the system's
>> memory.
>>
>>> It did pass both a short and long self test.  I used cryptsetup -s 512
>>> to encrypt with, nice password too.  My rig has a FX-8350 8 core running
>>> at 4GHz CPU and 32GBs of memory.  The CPU is fairly busy.  A little more
>>> than normal anyway.  Keep in mind, I have two encrypted drives connected
>>> right now.
>> The last time I looked at cryptsetup / LUKS, I found that there was a
>> [kernel] process per encrypted block device.
>>
>> A hack that I did while testing things was to slice up a drive into
>> multiple partitions, encrypt each one, and then re-aggregate the LUKS
>> devices as PVs in LVM.  This surprisingly was a worthwhile performance
>> boost.
> I noticed there is a kcrypt something thread running, a few actually but
> it's hard to keep up since I see it on gkrellm's top process list.  The
> CPU is running at about 40% or so average but I do have mplayer, a
> couple Firefox profiles, Seamonkey and other stuff running as well.  I
> still got plenty of CPU pedal left if needed.  Having Ktorrent and
> qbittorrent running together isn't helping.  Thinking of switching
> torrent software.  Qbit does seem to use more memory tho.
>
>
>>> Just curious if that speed is normal or not.
>> I suspect that your drive is FAR more the bottleneck than the
>> encryption itself is.  There is a chance that the encryption's access
>> pattern is exascerbating a drive performance issue.
>>
>>> Thoughts?
>> Conceptually working in 512 B blocks on a drive that is natively 4 kB
>> sectors.  Thus causing the drive to do lots of extra work to account
>> for the other seven 512 B blocks in a 4 kB sector.
> I think the 512 has something to do with key size or something.  Am I
> wrong on that?  If I need to use 256 or something, I can.  My
> understanding was that 512 was stronger than 256 as far as the
> encryption goes.
>
>
>>> P. S.  The pulled drive I bought had like 60 hours on it.  Dang near
>>> new.
>> :-)
> I'm going to try some tests Rich mentioned after it is done doing its
> backup.  I don't want to stop it if I can avoid it.  It's about half way
> through, give or take a little.
>
> Dale
>
> :-)  :-)
>