Improving the performance of my secondary HDD

Improving the performance of my secondary HDD

[Sameer Naik]

Hi,

Recently I purchased an SSD and started using bcache to speed up my
secondary HDD. My entire linux installation and home directory is
setup on the SSD and I have set aside a 20GB partition for bcache.

My secondary storage has multiple partitions all of which are setup as
backing devices and are used to store various types of file,
virtualbox disk images, etc. which are seldom accessed.

I would like to know if bcache would really be effective in my setup,
say for example to speed up the virtual machines since the HDD
partitions are being cached using bcache? Considering that my virtual
machine image sizes would be between 8 - 16 GB, would I need to
perform some level of tuning to achieve a noticeable performance
improvement.

Lastly, should I be noticing a marked improvement in the HDD write
operations or would I need to turn on "write back" mode?

Please do share your inputs.

Thanks and Regards

Re: Improving the performance of my secondary HDD

[Kai Krakow]

Sameer Naik <sameer.subscriptions@damagehead.com> schrieb:

> Recently I purchased an SSD and started using bcache to speed up my
> secondary HDD. My entire linux installation and home directory is
> setup on the SSD and I have set aside a 20GB partition for bcache.
> 
> My secondary storage has multiple partitions all of which are setup as
> backing devices and are used to store various types of file,
> virtualbox disk images, etc. which are seldom accessed.
> 
> I would like to know if bcache would really be effective in my setup,
> say for example to speed up the virtual machines since the HDD
> partitions are being cached using bcache? Considering that my virtual
> machine image sizes would be between 8 - 16 GB, would I need to
> perform some level of tuning to achieve a noticeable performance
> improvement.

Bcache speeds up random accesses where SSDs excel at. You do not need to 
worry about fitting a whole VM inside of bcache. Sequential access goes to 
HDD and can run in parallel with SSD accesses. That means, only when HDD 
access would be slow, it goes through the SSD and uses cache space, and if 
your SSD becomes saturated (and latencies grow), it falls back to passing 
data directly to HDD. It may be worth noting that defragmenting VMs may make 
sense, as it may make sense to mark the VM images as running on SSD (at 
least in VirtualBox that is a setting per image in the machine settings). 
The speedups for VMs is noticable but not magic. Native Linux file accesses 
gain much more performance from bcache setups.

> Lastly, should I be noticing a marked improvement in the HDD write
> operations or would I need to turn on "write back" mode?

If you have many random access write patterns or a lot of data that was 
written may be read later, it should make a noticable difference. And write 
back mode seems to be very stable - I didn't have any problem with it yet 
although I had some hard reboots. Just a dying SSD could become a huge PITA.

I suggest to leave some spare space unpartitioned in the SSD to keep high 
performance and long health, because with unused (and trimmed) space around 
the wear levelling can perform much better. Your SSD probably already has 
some spare space for this hidden from you - like 120GB vs 128GB, or 240GB 
vs. 256GB. I'd recommend going with around 15-20% from the full SSD size 
(read: calculate from 128 or 256 GB or whatever size it internally has) - at 
least if you expect to write much data. That means, for a 256GB SSD (which 
announces 240GB) you partition only around 210GB.

In case you are interested in some numbers: I'm running my rootfs through 
bcache on btrfs, and boot to full desktop has dropped from around >90s 
(30-45s in systemd) down to maybe 20s (5-8s in systemd). I'm using write-
back mode, however. At least it shows: Bcache can be very effective.

VM boot times (Windows 7 in VirtualBox) has dropped to something around 
20-30s with responsive desktop. It hasn't been much slower before (maybe 
30-35s) but it took much longer before the desktop became responsive. So you 
should see improvement there, too. 

-- 
Replies to list only preferred.

Re: Improving the performance of my secondary HDD

[Sameer Naik]

Thanks for the great reply.
Will work with your suggestions.

Cheers
~Sameer

On Mon, Mar 16, 2015 at 1:45 AM, Kai Krakow <hurikhan77@gmail.com> wrote:
> Sameer Naik <sameer.subscriptions@damagehead.com> schrieb:
>
>> Recently I purchased an SSD and started using bcache to speed up my
>> secondary HDD. My entire linux installation and home directory is
>> setup on the SSD and I have set aside a 20GB partition for bcache.
>>
>> My secondary storage has multiple partitions all of which are setup as
>> backing devices and are used to store various types of file,
>> virtualbox disk images, etc. which are seldom accessed.
>>
>> I would like to know if bcache would really be effective in my setup,
>> say for example to speed up the virtual machines since the HDD
>> partitions are being cached using bcache? Considering that my virtual
>> machine image sizes would be between 8 - 16 GB, would I need to
>> perform some level of tuning to achieve a noticeable performance
>> improvement.
>
> Bcache speeds up random accesses where SSDs excel at. You do not need to
> worry about fitting a whole VM inside of bcache. Sequential access goes to
> HDD and can run in parallel with SSD accesses. That means, only when HDD
> access would be slow, it goes through the SSD and uses cache space, and if
> your SSD becomes saturated (and latencies grow), it falls back to passing
> data directly to HDD. It may be worth noting that defragmenting VMs may make
> sense, as it may make sense to mark the VM images as running on SSD (at
> least in VirtualBox that is a setting per image in the machine settings).
> The speedups for VMs is noticable but not magic. Native Linux file accesses
> gain much more performance from bcache setups.
>
>> Lastly, should I be noticing a marked improvement in the HDD write
>> operations or would I need to turn on "write back" mode?
>
> If you have many random access write patterns or a lot of data that was
> written may be read later, it should make a noticable difference. And write
> back mode seems to be very stable - I didn't have any problem with it yet
> although I had some hard reboots. Just a dying SSD could become a huge PITA.
>
> I suggest to leave some spare space unpartitioned in the SSD to keep high
> performance and long health, because with unused (and trimmed) space around
> the wear levelling can perform much better. Your SSD probably already has
> some spare space for this hidden from you - like 120GB vs 128GB, or 240GB
> vs. 256GB. I'd recommend going with around 15-20% from the full SSD size
> (read: calculate from 128 or 256 GB or whatever size it internally has) - at
> least if you expect to write much data. That means, for a 256GB SSD (which
> announces 240GB) you partition only around 210GB.
>
> In case you are interested in some numbers: I'm running my rootfs through
> bcache on btrfs, and boot to full desktop has dropped from around >90s
> (30-45s in systemd) down to maybe 20s (5-8s in systemd). I'm using write-
> back mode, however. At least it shows: Bcache can be very effective.
>
> VM boot times (Windows 7 in VirtualBox) has dropped to something around
> 20-30s with responsive desktop. It hasn't been much slower before (maybe
> 30-35s) but it took much longer before the desktop became responsive. So you
> should see improvement there, too.
>
> --
> Replies to list only preferred.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html