linux-kernel - Re: [dm-devel] Announcement: STEC EnhanceIO SSD caching software for Linux kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130116104546.GA3869@raspberrypi>
Date:	Wed, 16 Jan 2013 10:45:47 +0000
From:	thornber@...hat.com
To:	device-mapper development <dm-devel@...hat.com>
Cc:	Mike Snitzer <snitzer@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [dm-devel] Announcement: STEC EnhanceIO SSD caching software for
 Linux kernel

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/