On 10/4/18 7:35 PM, Bart Van Assche wrote:
When debugging e.g. the SCSI timeout handler it is important that
requests that have not yet been started or that already have
completed are also reported through debugfs.
Signed-off-by: Bart Van Assche
Cc: Christoph Hellwig
Cc: Ming Lei
Cc: Hannes
When do GC, the number of read/write sectors are determined
by max_write_pgs(see gc_rq preparation in pblk_gc_line_prepare_ws).
Due to max_write_pgs doesn't consider max hw sectors
supported by nvme controller(128K), which leads to GC
tries to read 64 * 4K in one command, and see below error
When debugging e.g. the SCSI timeout handler it is important that
requests that have not yet been started or that already have
completed are also reported through debugfs.
Signed-off-by: Bart Van Assche
Cc: Christoph Hellwig
Cc: Ming Lei
Cc: Hannes Reinecke
Cc: Johannes Thumshirn
Cc: Martin
On 10/4/18 10:15 AM, Mikhail Gavrilov wrote:
> Sorry I don't finded answer on my question.
> Why BFQ scheduler available only for NVMe device?
>
> $ find /sys -name scheduler -exec grep . {} +
> find: ‘/sys/kernel/debug’: Permission denied
> find: ‘/sys/fs/pstore’: Permission denied
> find:
Sorry I don't finded answer on my question.
Why BFQ scheduler available only for NVMe device?
$ find /sys -name scheduler -exec grep . {} +
find: ‘/sys/kernel/debug’: Permission denied
find: ‘/sys/fs/pstore’: Permission denied
find: ‘/sys/fs/bpf’: Permission denied
On Thu 27-09-18 23:47:01, Tetsuo Handa wrote:
> Possible changes folded into this series.
Thanks for having a look. But please comment on individual patches at
appropriate places instead of sending this patch where everything is just
mixed together. It is much easier to find out what we are
