Re: data corruption: revalidating a (removable) hdd/flash on re-insert
- From: "Kay Sievers" <kay.sievers@xxxxxxxx>
- Date: Fri, 31 Oct 2008 19:49:59 +0100
On Fri, Oct 31, 2008 at 18:39, Michael Tokarev <mjt@xxxxxxxxxx> wrote:
Kay Sievers wrote:
On Fri, Oct 31, 2008 at 16:38, Michael Tokarev <mjt@xxxxxxxxxx> wrote:
To make a long story short: is there a way to force kernel
to re-validate a replaced usb-connected hard drive (or a
flash) *automatically*?
Insert the media, and force a validation:
$ touch /dev/sdb
With a newly inserted flash (removed some irrelevant stuff):
DEVTYPE=disk SUBSYSTEM=block MINOR=16 ACTION=change MAJOR=8
DEVTYPE=partition SUBSYSTEM=block MINOR=17 ACTION=add MAJOR=8
DEVTYPE=scsi_device SUBSYSTEM=scsi DRIVER=sd SDEV_MEDIA_CHANGE=1
ACTION=change
DEVTYPE=disk SUBSYSTEM=block MINOR=16 ACTION=change MAJOR=8
Access the device:
$ touch /dev/sdb
Nothing should happen, as the reader/kernel knows it is still valid.
Yes nothing happens.
Now remove the media and insert it immediately again.
Access the device:
$ touch /dev/sdb
UEVENT[1225468868.803950] change
/devices/pci0000:00/0000:00:1d.7/usb5/5-2/5-2:1.0/host8/target8:0:0/8:0:0:0
(scsi)
and you see the reader told to kernel (scsi unit attention) to
revalidate the device.
Ok. So in my case, nothing happens here just like
if it were not removed/inserted.
I replaced the card with another one, and nothing
happened as well.
Only when touch'ing after REMOVING the flash, I see:
DEVTYPE=scsi_device SUBSYSTEM=scsi DRIVER=sd SDEV_MEDIA_CHANGE=1
ACTION=change DEVTYPE=partition SUBSYSTEM=block MINOR=17 ACTION=remove
MAJOR=8
DEVTYPE=disk SUBSYSTEM=block MINOR=16 ACTION=change MAJOR=8
Every access to removable media is guarded by this revalidation check.
If you don't see these events, you should not trust this reader, and
at least never change the media while it is connected.
Ok. So.. 3 questions.
1) how it worked before (i yet to find which kernel worked)?
I can only guess that some older kernel never cached the
"validity".
The kernel does not cache, it's the device itself that reports a media
change, and the kernel asks every removable device before it is
accessing it.
2) 'doze notices the insertions/removals just fine. Again I
can only guess that it constantly pools for changes.
It polls the device every few secomds, just like HAL does on most
Linux desktop installations. But in your case, when the reader does
not report the change correctly, even that might go wrong, just like
without polling.
3), and the most important one. I think there should be a
way to stop "caching" of the media information, i.e. to force
revalidation events on EVERY access, for certain hardware at
least.
That's how it already is. We just rely on the device to tell us. There
is no way to revalidate anything otherwise.
Because corruption in such cases is much worse than
any positive effects of caching etc... Maybe some unusual_devs.h
way or somesuch?..
I can't think of a way to make that working, there is no cache in the
kernel, only a state in the device. You would need to checksum the
device to find out that it isn't the same media, even that might not
work, and it's definitely nothing you want to do.
You could trace with usbmon, or something and investigate the scsi
packets if the scsi unit attention really does not signify a media
change, which is what I expect.
Now I see the device is somewhat(?) broken. But as I said before
in another email, it's a great device (as in, two epochs connected
to each other), and it'd be sad to lose it. A nostalgie, sort of.. ;)
If it works otherwise, use it, but I wouldn't change media while it is
connected.
Ok, maybe actually polling for devices sometimes makes sense... ;)
And there can be a workaround, using a tiny daemon that constantly
accesses the device, in order to catch removals... 'hwell.
That would still not work with your device, if you change the media
during the polling interval, which is usually between 2 and 16
seconds. If the device does not report any change, like it seem in
your case, you can not do anything. Polling helps only to reflect the
current state of a device while it is not accessed, to get the state
of the device into the kernel. Like on a desktop, where you want to
auto-mount card reader/cdrom media on insertion.
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- data corruption: revalidating a (removable) hdd/flash on re-insert
- From: Michael Tokarev
- Re: data corruption: revalidating a (removable) hdd/flash on re-insert
- From: Kay Sievers
- Re: data corruption: revalidating a (removable) hdd/flash on re-insert
- From: Michael Tokarev
- data corruption: revalidating a (removable) hdd/flash on re-insert
- Prev by Date: Re: alpha: undefined reference to `save_stack_trace'
- Next by Date: [PATCH] Re: alpha: undefined reference to `save_stack_trace'
- Previous by thread: Re: data corruption: revalidating a (removable) hdd/flash on re-insert
- Next by thread: build issue #576 for v2.6.28-rc2-385-g721d5df :'boot_cpu_id' undeclared
- Index(es):
Relevant Pages
|
