Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1403330

BLKZEROOUT not zeroing md dev on VMDK

From Sitsofe Wheeler <sitsofe@gmail.com>
Newsgroups linux.kernel
Subject BLKZEROOUT not zeroing md dev on VMDK
Date 2016-05-19 00:40 +0200
Message-ID <rAiid-89L-15@gated-at.bofh.it> (permalink)
Organization linux.* mail to news gateway

Show all headers | View raw


Hi,

With Ubuntu's 4.4.0-22-generic kernel and a Fedora 23
4.6.0-1.vanilla.knurd.1.fc23.x86_64 kernel I've found that the
BLKZEROOUT syscall can malfunction and not zero data.

When BLKZEROOUT is issued to an MD device atop a PVSCSI controller
supplied VMDK from ESXi 6.0 the call returns immediately and with a zero
return code. Unfortunately, inspecting the data on the MD device shows
that it has not been zeroed and is in fact untouched. The easiest way to
see this behaviour is to boot the VM, create an mdadm device atop
/dev/sd?, scribble some non-zero value on the disk and then use
blkdiscard --zeroout /dev/md??? . If you then inspect the MD disk (e.g.
with hexdump) you will still see the old data and using POSIX_FADV_DONTNEED
on the MD device doesn't change the outcome.

The only clue I've seen is that
/sys/block/sd?/queue/write_same_max_bytes starts out being 33553920 but
after a WRITE SAME is issued it becomes 0. If the MD device is created
after write_same_max_bytes has become 0 on the backing disk then
BLKZEROOUT seems to work correctly.

-- 
Sitsofe | http://sucs.org/~sits/

Back to linux.kernel | Previous | NextNext in thread | Find similar | Unroll thread


Thread

BLKZEROOUT not zeroing md dev on VMDK Sitsofe Wheeler <sitsofe@gmail.com> - 2016-05-19 00:40 +0200
  Re: BLKZEROOUT not zeroing md dev on VMDK "Darrick J. Wong" <darrick.wong@oracle.com> - 2016-05-27 06:20 +0200
    Re: BLKZEROOUT not zeroing md dev on VMDK Sitsofe Wheeler <sitsofe@gmail.com> - 2016-05-27 06:50 +0200
      Re: BLKZEROOUT not zeroing md dev on VMDK Tom Yan <tom.ty89@gmail.com> - 2016-05-27 11:40 +0200

csiph-web