Comment 13 for bug 1371591

Revision history for this message
Chris J Arges (arges) wrote : Re: file not initialized to 0s under some conditions on VMWare

The bisect resulted in the following:

dc019b21fb92d620a3b52ccecc135ac968a7c7ec is the first bad commit
commit dc019b21fb92d620a3b52ccecc135ac968a7c7ec
Author: Mike Snitzer <email address hidden>
Date: Fri May 10 14:37:16 2013 +0100

    dm table: fix write same support

    If device_not_write_same_capable() returns true then the iterate_devices
    loop in dm_table_supports_write_same() should return false.

    Reported-by: Bharata B Rao <email address hidden>
    Signed-off-by: Mike Snitzer <email address hidden>
    Cc: <email address hidden> # v3.8+
    Signed-off-by: Alasdair G Kergon <email address hidden>

:040000 040000 d8b62d18789b5c9e5b52c076abcf4c8c066b5d59 71a5511a8ea76f43bd167524a9186c1d78407bce M drivers

--

However, I don't think the issue is with this patch. The function 'device_not_write_same_capable()' correctly returns:
   return q && !q->limits.max_write_same_sectors;
If max_write_same_sectors is 0 (write_same not supported), then true is returned and thus 'not_write_same_capable'.

Likewise the function 'dm_table_supports_write_same' iterates through dm tables and checks

 if (!ti->type->iterate_devices ||
                    ti->type->iterate_devices(ti, device_not_write_same_capable, NULL))
                        return false;

So if iterate_devices is NULL, this if returns false, otherwise if iterate_devices exist, then device_not_write_same_capable is called, if it returns 'true' then the function returns 'false' (A bit confusing, but essentially the parent function is 'supports_write_same' and uses a 'not_write_same_capable' function to check this fact. )

That logic was introduced in: d54eaa5a0fde0a202e4e91f200f818edcef15bee (v3.8-rc1), which means that previous to that we might not see the same behavior which could account for 2.6.38 not failing this test case.

Relevant thread: http://www.spinics.net/lists/dm-devel/msg19583.html

--

Looking at the affected VM:

Now this makes sense why LVM is only affected, and explains the helpful kernel message output. If we check the dm's for our LVM vg's we see the following:

ubuntu@ubuntu:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 20G 0 disk
├─sda1 8:1 0 243M 0 part /boot
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 19.8G 0 part
  ├─ubuntu--vg-root (dm-0) 252:0 0 18.8G 0 lvm /
  └─ubuntu--vg-swap_1 (dm-1) 252:1 0 1020M 0 lvm [SWAP]
sr0 11:0 1 572M 0 rom

ubuntu@ubuntu:~$ cat /sys/dev/block/252\:1/queue/write_same_max_bytes
33553920
ubuntu@ubuntu:~$ cat /sys/dev/block/252\:0/queue/write_same_max_bytes
33553920

So write_same support is enabled, but then that causes the failure. So at this point, I wonder if the underlying virtual SCSI is at fault.