Linux Device Mapper development
 help / color / mirror / Atom feed
From: "Bryn M. Reeves" <breeves@redhat.com>
To: Mike Snitzer <snitzer@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>,
	dm-devel@redhat.com, Ming Lei <ming.lei@redhat.com>
Subject: Re: [dm-devel] [RFC PATCH] io_uring: reissue in case -EAGAIN is returned after io issue returns
Date: Thu, 7 Apr 2022 16:36:56 +0100	[thread overview]
Message-ID: <Yk8FGN1HtVTYjoSl@redhat.com> (raw)
In-Reply-To: <Yk3FO6r59nTrDuiS@redhat.com>

On Wed, Apr 06, 2022 at 12:52:11PM -0400, Mike Snitzer wrote:
> On Tue, Apr 05 2022 at 10:09P -0400, Ming Lei <ming.lei@redhat.com> wrote:
> > Because it is null block...
> 
> Ha, yes.. very good point. I was expecting null_blk capability (read
> back written data) that it was never intended to provide. Sorry ;)

You can configure a memory backed nullblk instance using the configfs
interface that will return written data on reads:

  # modprobe null_blk nr_devices=0
  # mkdir -p /sys/kernel/config/nullb/nullb0
  # echo 500 > /sys/kernel/config/nullb/nullb0/size
  # echo 1 > /sys/kernel/config/nullb/nullb0/memory_backed
  # echo 1 > /sys/kernel/config/nullb/nullb0/power 
  # lsblk | grep null
  nullb0               250:0    0  500M  0 disk 

It's good enough to make and mount an ext4 file system; the contents
persist across umount as you'd expect and the image will pass an fsck:

  # mkfs.ext4 /dev/nullb0 
  mke2fs 1.46.3 (27-Jul-2021)
  ...

However there's still something in null_blk that causes fio's verify
mode some indigestion:

  # fio --bs=4096 --ioengine=io_uring --fixedbufs --registerfiles --hipri=1 --iodepth=2 --iodepth_batch_submit=2 --iodepth_batch_complete_min=2 --filename=/dev/nullb0 --direct=1 --runtime=20 --numjobs=2 --rw=randread --name=test --group_reporting --norandommap --do_verify=1 --verify=crc32c --verify_async=1
  test: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=io_uring, iodepth=2
  ...
  fio-3.26
  Starting 2 processes
  fio: filehash.c:64: __lookup_file_hash: Assertion `f->fd != -1' failed.
  verify: bad magic header 0, wanted acca at file /dev/nullb0 offset 31621120, length 4096 (requested block: offset=31621120, length=4096)
  verify: bad magic header 0, wanted acca at file /dev/nullb0 offset 388124672, length 4096 (requested block: offset=388124672, length=4096)
  fio: pid=2074, err=84/file:verify.c:1444, func=async_verify, error=Invalid or incomplete multibyte or wide character
  fio: pid=2075, got signal=6
  Jobs: 1 (f=0): [f(1),K(1)][-.-%][eta 00m:00s]
  Jobs: 1 (f=0): [f(1),K(1)][-.-%][eta 00m:00s]
  Jobs: 1 (f=0): [f(1),K(1)][-.-%][eta 00m:00s]
  
  ^Cbs: 1 (f=0): [f(1),K(1)][-.-%][eta 00m:00s]
  fio: terminating on signal 2

I haven't looked into it any further at this point (I was looking at
null_blk to evaluate it for use in stacker, as a backing device for
test stacks).

Regards,
Bryn.
 

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


      reply	other threads:[~2022-04-07 15:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220403114532.180945-1-ming.lei@redhat.com>
2022-04-04 16:51 ` [dm-devel] [RFC PATCH] io_uring: reissue in case -EAGAIN is returned after io issue returns Mike Snitzer
2022-04-06  2:09   ` Ming Lei
2022-04-06 16:52     ` Mike Snitzer
2022-04-07 15:36       ` Bryn M. Reeves [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yk8FGN1HtVTYjoSl@redhat.com \
    --to=breeves@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=dm-devel@redhat.com \
    --cc=ming.lei@redhat.com \
    --cc=snitzer@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox