Hello,
I have two questions regarding the behavior for hot-plugging SD card in
USB SD card reader relating to the scsi sub system.
Before the questions, the background and my understanding:
On the 3.14.y branch and later (not sure about 4.2+), when using a USB
SD card reader with sd card inserted and filesystem mounted, there are 4
possible cases for physical removal of the sd card. The first is when
the card (not usb reader) is removed and the scsi device is not busy
(being accessed). The second is with the sd card busy (being accessed)
and then the sd card is removed. The 3rd and 4th are the similar but
with the usb reader itself being removed with the sd card inserted. This
mail focuses on the behavior of the second case where the sd card is
busy and then removed.
If my understanding is correct, in the scenario above, access of the
scsi disk block device keeps the reference count positive. This is
followed by the removal of the sd card which in the non-busy case would
make the reference count zero and allow the disk partitions to be
unmounted. However in the busy case any new sd card inserted into the
card reader should recalculate the geometry and allow the disk
partitions to be discovered and be auto-mounted. However, it seems that
the scsi disk reference count does not go to zero and we are unable to
unmount the partition. A lazy unmount appears to occur leaving a stale
device node. Similar behavior can be seen on inserting a USB flash based
storage device and executing the same problem case. In the case of a USB
flash drive, after hotplug and re-insertion, a new block device node
gets assigned as the previous one is still busy. In the case of the SD
card, a new block device node does not get created.
A simple recreation case is to use 'tail -f' on any file on the
auto-mounted sd card file system, then remove the SD card and then
insert a second different SD card. The second SD card does not
auto-mount as one would first think. The device is not listed in MP
shadow fblock nor mounted at all.
In the case of the USB flash drive, the host adapter is created, scsi
bus scanned, finding the scsi device controller on the bus. The device
controller responds to the scan and the scsi disk is populated with
appropriate geometry sizes. This is provided to the block layer, then to
the vfs which the auto-mounter picks up on and mounts the partitions. In
the case of the USB SD card reader, when the card reader is plugged in
without SD card populated, the scsi device controller is still found,
root scsi disk node still created, but its geometry is 0 and the device
is put in a NO_MEDIUM_INSERTED state. Any open attempts on the device
node will fail with a NOMEDIUM error. Insertion of an SD card changes
the reported geometry of the SCSI disk during a periodic scan, the
NOMEDIUM state removed and disk information updated. As far as kernel
events go, a 'change' and 'add' events are provided to up to userland.
When a USB flash drive is busy (being accessed) when hotplugged
(removed), the partition remains mounted and root and subsequent
re-insertion creates a new root scsi device node in sequential
alphabetical order (e.g. /dev/sdb). The reason re-population of the scsi
disk works in the USB case is due to the entire virtual host being
destroyed and repopulated. This repopulates the parent device node after
the device controller is scanned and found on the virtual scsi bus. In
the case of the sd card, removal of the SD card only changes the medium
inserted state and does not result in a scsi disk root node re-population.
I have two questions.
1. In the case of a USB card reader sd card being hotplugged while busy,
is the current behavior desired? If so, why? An embedded system where
the sd card reader is physically locked/mounted to the usb hub could see
such a scenario if the sd card is being accessed during removal from the
user. Such a usecase is possible on PC as well.
2. If this behavior should be more similar to a USB flash drive during
hotplug what layer modifications would be necessary? (mass storage
driver, scsi disk, scsi layer, block, etc)
I have a few ideas how this could be done but I would appreciate any
additional thoughts or feedback regarding creating similar behavior to a
usb hotplug.
The current thoughts I have are:
a.) change the behavior of the scsi disk layer in the case when the
media is ejected with its user count not equal zero. The idea is to
force drop (up and down the layer stack) the existing references to the
disk so that it can be properly cleaned up and removed. This is a little
different than the usb case above as the scsi device node will be re-used.
b.) Use a notifier chain to notify the usb mass storage driver to reset
and re-instantiate the virtual host adapter. This would be the
equivalent to what usb is doing at hotplug.
c.) let userspace handle the change events and handle it accordingly. (a
number of ways, re-enumerate the hub, terminate offending apps using
node and force unmount, etc.)
Thank you in advance
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
