On Wed, 5 May 2010 03:33:43 pm Neil Brown wrote:
On Wed, 5 May 2010 14:28:41 +0930
Rusty Russell ru...@rustcorp.com.au wrote:
On Wed, 5 May 2010 05:47:05 am Jamie Lokier wrote:
Jens Axboe wrote:
On Tue, May 04 2010, Rusty Russell wrote:
ISTR someone mentioning a desire for such
Rusty Russell wrote:
Seems over-zealous.
If the recovery_header held a strong checksum of the recovery_data you would
not need the first fsync, and as long as you have two places to write
recovery
data, you don't need the 3rd and 4th syncs.
Just:
Rusty Russell wrote:
On Wed, 5 May 2010 05:47:05 am Jamie Lokier wrote:
Jens Axboe wrote:
On Tue, May 04 2010, Rusty Russell wrote:
ISTR someone mentioning a desire for such an API years ago, so CC'ing
the
usual I/O suspects...
It would be nice to have a more fuller API
On Wed, 5 May 2010 14:28:41 +0930
Rusty Russell ru...@rustcorp.com.au wrote:
On Wed, 5 May 2010 05:47:05 am Jamie Lokier wrote:
Jens Axboe wrote:
On Tue, May 04 2010, Rusty Russell wrote:
ISTR someone mentioning a desire for such an API years ago, so CC'ing
the
usual I/O
Jens Axboe wrote:
On Tue, May 04 2010, Rusty Russell wrote:
ISTR someone mentioning a desire for such an API years ago, so CC'ing the
usual I/O suspects...
It would be nice to have a more fuller API for this, but the reality is
that only the flush approach is really workable. Even just
Rusty Russell wrote:
On Fri, 19 Feb 2010 08:52:20 am Michael S. Tsirkin wrote:
I took a stub at documenting CMD and FLUSH request types in virtio
block. Christoph, could you look over this please?
I note that the interface seems full of warts to me,
this might be a first step to
On Wed, 5 May 2010 05:47:05 am Jamie Lokier wrote:
Jens Axboe wrote:
On Tue, May 04 2010, Rusty Russell wrote:
ISTR someone mentioning a desire for such an API years ago, so CC'ing the
usual I/O suspects...
It would be nice to have a more fuller API for this, but the reality is