5

I'm doing some tests involving data corruption from unsafely removing a usb drive, but I need a way to consistently remove the drive at a specific time. Is there a command that's equivalent to physically yanking the drive out without flushing any buffers or caches?

Daffy
  • 395
  • 2
    That may not be like physically unplugging it, but (assuming that the bus-devicepath of the device is 1-2.3): echo -n 1-2.3 > /sys/bus/usb/drivers/usb/unbind as root is similar to yanking it and it will even trigger a warning on your desktop if the device is a usb drive. Generally you better do this kind of testing on a virtual machine like qemu. –  Sep 17 '21 at 08:50
  • 2
    And btw: echo -n 1-2.3 > /sys/bus/usb/drivers/usb/bind to put it back in. –  Sep 17 '21 at 08:58
  • 1
    https://unix.stackexchange.com/questions/7412/how-to-reconnect-a-logically-disconnected-usb-device is kind of the opposite problem, but the answers there are likely to be helpful here as well. – Gilles 'SO- stop being evil' Sep 17 '21 at 12:33

3 Answers3

4

Some (but few) USB hubs have hardware support for port power control. If you're lucky enough to have one that implements that feature, then you could power off an individual port to mimic removing the device that is plugged into that port.

See the follow repo for the source code for a program that would enable you to control that feature (if present): https://github.com/codazoda/hub-ctrl.c

Andy Dalton
  • 13,993
4

A block device simulator might work better than a real USB device for this type of research.

It should be possible to set up a virtual block device, create a file system on it, copy some files to it or do other write activity, and take snapshots of the device at random times.

The trick is that you need to reach into the device and freeze it and then take a snapshot, rather than reading the device while the writes are occurring.

It may also help if you can limit write speed to the device.

It is possible some of the filesystem authors have already created a testbed for this sort of corruption. (Thanks @Austin Hemmelgam) The dm_log_writes device mapper component goes a step beyond a virtual block device and gives you a stream of writes. You could easily snip this stream at any (all?) point and replay it to get your yank corrupted filesystem.

user10489
  • 6,740
  • 1
    Using a virtual block device is an excellent idea – Daffy Sep 17 '21 at 02:21
  • 1
    For this case specifically, possibly look at the dm-log-writes device mapper target for the snapshot functionality. It’s designed for exactly this type of testing (albeit oriented more towards filesystem developers). – Austin Hemmelgarn Sep 17 '21 at 16:06
0

A (DIY) hardware solution would be to put a switch the 5V line of a USB extension cable programmatically. I'd use either:

  • a normally-closed reed relay with a 5V coil voltage, and drive it with my usual trick when I need 1-2 bits of hardware IO: the status lines of a USB-232 adaptor. That's easy to write to from pretty much any programming language.
  • an optoisolator, though the ones I use in this project to fire a camera (the circuit would easily adapt) may not handle the current drawn by a USB stick.
Chris H
  • 175
  • note that USB-GPIO adapters also exist – user253751 Sep 17 '21 at 13:50
  • @user253751, yes, I've got a couple. You could even use an Arduino if you've got one handy. The serial adaptors are often cheaper, and I've normally got a spare on hand, plus coding is trivial – Chris H Sep 17 '21 at 13:53