Re: Announcement: STEC EnhanceIO SSD caching software for Linux kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Amit,

I'll look through EnhanceIO this week.

There are several cache solutions out there; bcache, my dm-cache and
EnhanceIO seeming to be the favourites.  In suspect none of them are
without drawbacks, so I'd like to see if we can maybe work together.

I think the first thing we need to do is make it easy to compare the
performance of these impls.

I'll create a branch in my github tree with all three caches in.  So
it's easy to build a kernel with them.  (Mike's already combined
dm-cache and bcache and done some preliminary testing).

We've got some small test scenarios in our test suite that we run [1].
They certainly flatter dm-cache since it was developed using these.
It would be really nice if you could describe and provide scripts for
your test scenarios.  I'll integrate them with the test suite, and
then I can have some confidence that I'm seeing EnhanceIO in its best
light.

The 'transparent' cache issue is a valid one, but to be honest a bit
orthogonal to cache.  Integrating dm more closely with the block layer
such that a dm stack can replace any device has been discussed for
years and I know Alasdair has done some preliminary design work on
this.  Perhaps we can use your requirement to bump up the priority on
this work.

On Tue, Jan 15, 2013 at 09:19:10PM +0800, Amit Kale wrote:
> 5. We have designed our writeback architecture from
> scratch. Coalescing/bunching together of metadata writes and cleanup
> is much improved after redesigning of the EnhanceIO-SSD
> interface. The DM interface would have been too restrictive for
> this. EnhanceIO uses set level locking, which improves parallelism
> of IO, particularly for writeback.

I sympathise with this; dm-cache would also like to see a higher level
view of the io, rather than being given the ios to remap one by one.
Let's start by working out how much of a benefit you've gained from
this and then go from there.

> PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED
> 
> This electronic transmission, and any documents attached hereto, may
> contain confidential, proprietary and/or legally privileged
> information. The information is intended only for use by the
> recipient named above. If you received this electronic message in
> error, please notify the sender and delete the electronic
> message. Any disclosure, copying, distribution, or use of the
> contents of information received in error is strictly prohibited,
> and violators will be pursued legally.

Please do not use this signature when sending to dm-devel.  If there's
proprietary information in the email you need to tell people up front
so they can choose not to read it.

- Joe


  [1] https://github.com/jthornber/thinp-test-suite/tree/master/tests/cache

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel


[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux