Package: parted Version: 3.2-5 Severity: grave Hi,
I found during d-i testing, that ZFS pools sometimes suffer I/O errors and go offline; this causes partman-zfs to hang. I suspect that in non-interactive situations, using parted to merely view the partition table could crash active, mounted filesystems on that disk. This took *many* hours to figure out but simplifies to: * parted's interface is designed so that a disk is 'opened' once, various get/set operations can happen, changes may be committed and then the fd is closed; therefore, disks are always opened with O_RDWR mode in case a set operation might need to make changes * opening O_RDWR and closing a disk device on FreeBSD, causes its partition tables to be rescanned (so, a 'commit' is implied - this also seems to be the cause of major slowness of partman in kfreebsd d-i, because it does this 'about' a hundred times in total) * the CAM layer handles this as a MEDIACHANGE event, it will DESTROY /dev devices for the disk partitions, and when scanning is complete, CREATE them again (perhaps similar to udev?) * an active ZFS pool may be doing things asynchronusly and try to read or write one of these devices when it disappears; I/O fails and the disk will be marked as faulty; if there is no redundancy, the entire pool will be offlined; I/O on these devices will hang until the fault is cleared and pool manually onlined * parted shouldn't be *able* to open a disk with O_RDWR if there are mounted filesystems; it uses kern.geom.debugflags "foot shooting" mode in order to do this unsafely * in the d-i partman use-case, "foot shooting" mode doesn't seem to be needed, because the disks are not active at the partitioning step so they can be opened O_RDWR anyway; the partition table is finalised when partman-zfs configuration starts; it is already assumed you cannot go back and make changes after this (partman-zfs is modelled on partman-lvm; you cannot set up LVM or a RAID then expect to repartition the component disks) * in non-interactive situations, an administrator could modify kern.geom.debugflags before using parted on an active disk, if they still really want to carry out risky operations So what I'm suggesting is that we just don't use kern.geom.debugflags to set "foot shooting" mode in parted any more - unless someone can give a really good reason why we do need to (and then help me find another solution to all of the above ;). I did test this in a jessie d-i install onto ZFS. I found only two problems: * when opening O_RDWR fails, it falls back to O_RDONLY but calls this an 'exception' with 'warn' severity that we would need to inhibit (or d-i will be interrupted by an Ignore/Cancel dialog when partman next looks at the partition table) * if some partman component does try to make changes after partman-zfs, that will now fail with an Ignore/Cancel dialog, but I'd consider it a bug if something does try to do this; update.d/swap was the only example I found, and that is in fact due to a bug which I'll file a separate report for Thanks for reading! -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org