[lkml]   [2010]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 26/30] ext4: do not send discards as barriers
Jan Kara <> writes:

> On Mon 30-08-10 15:56:43, Jeff Moyer wrote:
>> Jan Kara <> writes:
>> > An update: I've set up an ext4 barrier testing in KVM - run fsstress,
>> > kill KVM at some random moment and check that the filesystem is consistent
>> > (kvm is run in cache=writeback mode to simulate disk cache). About 70 runs
>> But doesn't your "disk cache" survive the "power cycle" of your guest?
> Yes, you're right. Thinking about it now the test setup was wrong because
> it didn't refuse writes to the VM's data partition after the moment I
> killed KVM. Thanks for catching this. I will probably have to use the fault
> injection on the host to disallow writing the device at a certain moment.
> Or does somebody have a better option?
> My setup is that I have a dedicated partition / drive for a filesystem
> which is written to from a guest kernel running under KVM. I have set it up
> using virtio driver with cache=writeback so that the host caches the writes
> in a similar way disk caches them. At some point I just kill the qemu-kvm
> process and at that point I'd like to also throw away data cached by the
> host...

I've used ilo to power off the system under test from remote. I have a
tool to automate the testing. It works as follows:

There's a client and a server. The server listens on an ip/port for
connections. A client will connect, tell the server it's configuration
(including what disk it's writing to, what block size it's using, and
the total amount of I/O to be done), and then start doing I/O. The I/O
is done using the AIO api, and the data written includes a block number,
a generation number, fill, and a crc. As each completion comes in, the
completed sectors are communicated to the server program. Upon
completion of an entire series of writes (writing the entire data set
once), the server waits some amount of time and then power cycles the
client. The client comes back up and is run in check mode to verify
that all of the data it reported as completed to the server is actually
in tact.

I recently updated the code to run against a file on a file system
(previously it would only work on a block device). It makes use of
stonith modules to do the power cycling. It works, but it isn't the
most elegant bit of engineering I've ever done. ;-)

Anyway, that code is available here:


 \ /
  Last update: 2010-08-30 23:07    [W:0.093 / U:1.156 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site