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.
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
The bisect resulted in the following:
dc019b21fb92d62 0a3b52ccecc135a c968a7c7ec is the first bad commit 0a3b52ccecc135a c968a7c7ec
commit dc019b21fb92d62
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 supports_ write_same( ) should return false.
loop in dm_table_
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 d8b62d18789b5c9 e5b52c076abcf4c 8c066b5d59 71a5511a8ea76f4 3bd167524a9186c 1d78407bce M drivers
--
However, I don't think the issue is with this patch. The function 'device_ not_write_ same_capable( )' correctly returns: max_write_ same_sectors; same_sectors is 0 (write_same not supported), then true is returned and thus 'not_write_ same_capable' .
return q && !q->limits.
If max_write_
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: d54eaa5a0fde0a2 02e4e91f200f818 edcef15bee (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 -vg-swap_ 1 (dm-1) 252:1 0 1020M 0 lvm [SWAP]
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-
sr0 11:0 1 572M 0 rom
ubuntu@ubuntu:~$ cat /sys/dev/ block/252\ :1/queue/ write_same_ max_bytes block/252\ :0/queue/ write_same_ max_bytes
33553920
ubuntu@ubuntu:~$ cat /sys/dev/
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.