The bisect resulted in the following:
dc019b21fb92d620a3b52ccecc135ac968a7c7ec is the first bad commit
commit dc019b21fb92d620a3b52ccecc135ac968a7c7ec
Author: Mike Snitzer <snit...@redhat.com>
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 <bharata....@gmail.com>
Signed-off-by: Mike Snitzer <snit...@redhat.com>
Cc: sta...@vger.kernel.org # v3.8+
Signed-off-by: Alasdair G Kergon <a...@redhat.com>
: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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1371591
Title:
file not initialized to 0s under some conditions on VMWare
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1371591/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
