Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


flashcache vs bcache
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

flashcache vs bcache

onepoundonepound Member
edited February 2013 in General

Any of the hosts able to provide any hands on experience between the two, with and without write back enabled.

Yes I can and have google'd, but as some here have tried both and some are using it in production was hoping for some feedback.

Comments

  • earlearl Member
    edited February 2013

    @onepound said: Yes I can and have google'd

    You know it's sad that you have to say that considering this is a forum, but yeah I can see the first comment be some smart ass telling you to google it!! I mean really whats the point of this forum then!!

  • Flashcache is stable, but not the fastest. It works.

    bcache is well like alpha/beta - very advanced, not stable, keeps changing and is awesome but not reliable. So far anyway.

    I think long term - 1 day bcache will be great, but not now.

  • SSD Cache results don't seem all that great tbh, I seen ramnode had like 5K IOPS in the other thread.

  • @Jacob said: SSD Cache results don't seem all that great tbh, I seen ramnode had like 5K IOPS in the other thread.

    Benchmarks don't reflect how SSD Cache works if you know the architecture. SSD Cache caches hot data based on some statistics and paths. Benchmarks aren't hot data in most cases.

  • Thanks @concerto49 flashcache is where I will start my initial testing then.

    Has write back improved with regards to reliability on flashcache enough for a production environment, off course with a mirrored set.
    Or is it still best to stick to write around?

  • @onepound said: Has write back improved with regards to reliability on flashcache

    I doubt it can be improved, the only thing you can do is use SSDs with big capactitors in them. Or just use write through caching, which is safe.

  • @rds100 said: I doubt it can be improved, the only thing you can do is use SSDs with big capactitors in them. Or just use write through caching, which is safe.

    It also depends if the SSD has a buffer/cache at all, e.g. Sandforce drives don't have them, but Marvell / Samsung based do.

  • I meant as in reliability I vaguely remember reading a post from @Francisco where he was able to get some random data corruption when he was testing with write back on flashcache.

  • FranciscoFrancisco Top Host, Host Rep, Veteran

    @onepound said: I meant as in reliability I vaguely remember reading a post from @Francisco where he was able to get some random data corruption when he was testing with write back on flashcache.

    Correcto.

    When I was trying things out I tested what would happen if a node hard crashed in the midst of writes. The box rebooted and the cached drive was pretty messed up.

    Francisco

  • Thanks @Francisco what SSD's were those out of interest, I have a couple of intel 520's to test this with when I get to the DC.

    Are yours all set to 'write around' then? With a single SSD?

  • FranciscoFrancisco Top Host, Host Rep, Veteran

    Writearound with sammy 830's.

    Francisco

  • rds100rds100 Member
    edited February 2013

    When i tested write around i found it to be slowing things down in some situations, so i settled with writethrough.

    In reality if there was some mode that is between writethrough and writearoud it would be best but there isn't (or at least wasn't the last time i looked).

  • FranciscoFrancisco Top Host, Host Rep, Veteran

    @rds100 said: When i tested write around i found it to be slowing things down in some situations, so i settled with writethrough.

    If your array is faster than the SSD, you'll end up limiting yourself due to how writethrough works.

    Francisco

  • rds100rds100 Member
    edited February 2013

    @Francisco true, but there is also skip_seq_thresh_kb to play with, i.e. you can exclude large sequential writes from the caching (like the stupid 1GB dd test).

    Thanked by 1VikingLayer
Sign In or Register to comment.