********
## It gets even worse - DM accepts writes even if the underlying disk has been
removed
********
#### Here is an example
root@ubusrv:~# l /dev/sda*
brw-rw---- 1 root disk 8, 0 Oct 26 09:06 /dev/sda
brw-rw---- 1 root disk 8, 1 Oct 26 09:06 /dev/sda1
root@ubusrv:~# pvs
PV VG Fmt Attr PSize PFree
/dev/sda1 vgtmp lvm2 a-- <2.00g 0 <<<<
/dev/vda3 ubuntu-vg lvm2 a-- 18.22g 0
root@ubusrv:~# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log
Cpy%Sync Convert
ubuntu-lv ubuntu-vg -wi-ao---- 18.22g
lvtmp vgtmp -wi-a----- <2.00g <<<<
root@ubusrv:~# l /dev/mapper/vgtmp-lvtmp
lrwxrwxrwx 1 root root 7 Oct 26 09:06 /dev/mapper/vgtmp-lvtmp -> ../dm-1
<<<< DM link
root@ubusrv:~#
#### Removing the underlying DM disk /dev/sda (in my case: deleting from the OS
or forced removal via hypervisor)
root@ubusrv:~# echo 1 > /sys/block/sda/device/delete
root@ubusrv:~# l /dev/sda* ## sda removed from the OS
ls: cannot access '/dev/sda*': No such file or directory
root@ubusrv:~#
root@ubusrv:~# pvs ## /dev/sda1 PV disappeared
PV VG Fmt Attr PSize PFree
/dev/vda3 ubuntu-vg lvm2 a-- 18.22g 0
root@ubusrv:~#
root@ubusrv:~# lvs ## lvtmp LV is also gone - OK
LV VG Attr LSize Pool Origin Data% Meta% Move Log
Cpy%Sync Convert
ubuntu-lv ubuntu-vg -wi-ao---- 18.22g
root@ubusrv:~#
root@ubusrv:~# l /dev/mapper/vgtmp-lvtmp ## DM link still exists
lrwxrwxrwx 1 root root 7 Oct 26 09:06 /dev/mapper/vgtmp-lvtmp -> ../dm-1
root@ubusrv:~# l /dev/dm-1
brw-rw---- 1 root disk 252, 1 Oct 26 09:06 /dev/dm-1
root@ubusrv:~#
#### Writing to faulty DM device
root@ubusrv:~# l file.tar
-rw-r--r-- 1 root root 2.4G Oct 19 14:12 file.tar
root@ubusrv:~#
root@ubusrv:~# dd if=file.tar of=/dev/mapper/vgtmp-lvtmp bs=10M count=204
204+0 records in
204+0 records out
2139095040 bytes (2.1 GB, 2.0 GiB) copied, 4.33304 s, 494 MB/s <<<<
completed successfully?!
root@ubusrv:~#
root@ubusrv:~# grep kernel /var/log/syslog | tail <<<< this means that the
kernel knows that writes are failing
2024-10-26T10:36:06.405786+02:00 ubusrv kernel: Buffer I/O error on dev dm-1,
logical block 0, lost async page write
2024-10-26T10:36:06.405845+02:00 ubusrv kernel: Buffer I/O error on dev dm-1,
logical block 1, lost async page write
2024-10-26T10:36:06.405861+02:00 ubusrv kernel: Buffer I/O error on dev dm-1,
logical block 2, lost async page write
2024-10-26T10:36:06.405876+02:00 ubusrv kernel: Buffer I/O error on dev dm-1,
logical block 3, lost async page write
2024-10-26T10:36:06.405890+02:00 ubusrv kernel: Buffer I/O error on dev dm-1,
logical block 4, lost async page write
2024-10-26T10:36:06.405905+02:00 ubusrv kernel: Buffer I/O error on dev dm-1,
logical block 5, lost async page write
2024-10-26T10:36:06.405919+02:00 ubusrv kernel: Buffer I/O error on dev dm-1,
logical block 6, lost async page write
2024-10-26T10:36:06.405972+02:00 ubusrv kernel: Buffer I/O error on dev dm-1,
logical block 7, lost async page write
2024-10-26T10:36:06.406022+02:00 ubusrv kernel: Buffer I/O error on dev dm-1,
logical block 8, lost async page write
2024-10-26T10:36:06.406035+02:00 ubusrv kernel: Buffer I/O error on dev dm-1,
logical block 9, lost async page write
root@ubusrv:~#
I can only repeat the question: where has this data been stored?
It's a very dangerous "feature". It may cause data loss, loss of data
consistency, e.g. in DB applications.
--
Regards,
Mirek
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2084979
Title:
Device Mapper accepts writes even when the underlying devices are dead
(offline or transport-offline)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2084979/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
