On Sat, Aug 5, 2017 at 8:51 AM, Shaohua Li wrote:
> From: Shaohua Li
>
> Sometime disk could have tracks broken and data there is inaccessable,
> but data in other parts can be accessed in normal way. MD RAID supports
> such disks. But we don't have a good way to test it, because we can't
> contr
On Fri, 2017-08-04 at 13:56 -0600, Jens Axboe wrote:
> On 08/04/2017 01:44 PM, Bart Van Assche wrote:
> > On Fri, 2017-08-04 at 09:04 -0600, Jens Axboe wrote:
> > > @@ -98,11 +98,13 @@ static void blk_mq_check_inflight(struct
> > > blk_mq_hw_ctx *hctx,
> > > return;
> > >
> > > /*
>
Mikulas,
> The sector number in the integrity tag must match the physical sector
> number. So, it must be verified at the bottom.
The ref tag seed matches the submitter block number (typically block
layer sector for the top device) and is remapped to and from the LBA by
the SCSI disk driver or
Christoph,
> We can simply add another bio flag to get back to the previous
> behavior. That being said thing to do in the end is to verify it
> at the top of the stack, and not the bottom eventuall. I can cook
> up a patch for that.
Yeah, the original code was careful about only adding the ve
From: Kyungchan Koh
Software must flush disk cache to guarantee data safety. To check if
software correctly does disk cache flush, we must know the behavior of
disk. But physical disk behavior is uncontrollable. Even software
doesn't do the flush, the disk probably does the flush. This patch trie
From: Kyungchan Koh
In test, we usually expect controllable disk speed. For example, in a
raid array, we'd like some disks are fast and some are slow. MD RAID
actually has a feature for this. To test the feature, we'd like to make
the disk run in specific speed.
block throttling probably can be
From: Shaohua Li
In testing software RAID, I usually found it's hard to cover specific cases.
RAID is supposed to work even disk is in semi good state, for example, some
sectors are broken. Since we can't control the behavior of hardware, it's
difficult to create test suites to do destructive tes
From: Shaohua Li
Sometime disk could have tracks broken and data there is inaccessable,
but data in other parts can be accessed in normal way. MD RAID supports
such disks. But we don't have a good way to test it, because we can't
control which part of a physical disk is bad. For a virtual disk, t
From: Kyungchan Koh
This create/remove disk when user writes 1/0 to 'power' attribute.
Signed-off-by: Kyungchan Koh
Signed-off-by: Shaohua Li
---
drivers/block/test_blk.c | 539 ++-
1 file changed, 538 insertions(+), 1 deletion(-)
diff --git a/driv
From: Kyungchan Koh
The testb block device driver is intended for testing, so configuration
should be easy. We are using configfs here, which can be configured with
a shell script. Basically the the testb will be configured as:
mount the configfs fs as usual:
mount -t configfs none /mnt
Checkin
On Sat, 5 Aug 2017, Christoph Hellwig wrote:
>
> On Thu, Aug 03, 2017 at 10:10:55AM -0400, Mikulas Patocka wrote:
> > That dm-crypt commit that uses bio integrity payload came 3 months before
> > 7c20f11680a441df09de7235206f70115fbf6290 and it was already present in
> > 4.12.
>
> And on it's
On Thu, Aug 03, 2017 at 10:10:55AM -0400, Mikulas Patocka wrote:
> That dm-crypt commit that uses bio integrity payload came 3 months before
> 7c20f11680a441df09de7235206f70115fbf6290 and it was already present in
> 4.12.
And on it's own that isn't an argument if your usage is indeed wrong,
and
On Thu, Aug 03, 2017 at 05:33:13PM +, Bart Van Assche wrote:
> On Thu, 2017-08-03 at 11:13 +0800, Ming Lei wrote:
> > On Thu, Aug 03, 2017 at 01:35:29AM +, Bart Van Assche wrote:
> > > On Wed, 2017-08-02 at 11:31 +0800, Ming Lei wrote:
> > > > On Tue, Aug 01, 2017 at 03:11:42PM +, Bart
On Sat, Aug 05, 2017 at 12:05:00AM +0200, Paolo Valente wrote:
> >
> > True. However, the difference between legacy-deadline mq-deadline is
> > roughly around the 5-10% mark across workloads for SSD. It's not
> > universally true but the impact is not as severe. While this is not
> > proof that th
Can you use normal linux style for the code instead of copy and
pasting the weird naming and capitalization from the DAC960 driver?
Also please use the driver name as prefix for the functions.
Maybe myraid instead of mylex?
I'll take a more detailed look at the actual driver in a bit.
On Thu, Aug 03, 2017 at 05:33:13PM +, Bart Van Assche wrote:
> Are you aware that the SCSI core already keeps track of the number of busy
> requests
> per LUN? See also the device_busy member of struct scsi_device. How about
> giving the
> block layer core access in some way to that counter?
16 matches
Mail list logo
