Hello,
I would appreciate any feedback or suggestions regarding the scenario below.
Thanks again
On 05/12/2016 11:02 PM, Frkuska, Joshua wrote:
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
--
_______________________________________________
Joshua Frkuska | Embedded Software Engineer
Mentor Graphics Japan Co., ltd. | +81-3-6866-7611
PRIVACY AND CONFIDENTIALITY NOTICE
This email and any attachments may contain confidential or privileged information for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
