0

When I boot my Linux and start writing to a USB-backed block device, everything goes fine for the first few times.

Afterwards, if I write to it once more, dd reports absurdly huge transfer rates (2.9 GB/s, which isn't possible), and it is seemingly successful. But when I plug it into any other computer, I can clearly see it holds the old data. Yet, my Linux reports the new data even when plugged back in (checked with xxd)! This should mean that it's holding the data in the cache and not ever flushing it. Only when rebooting does it finally work again.

I've tried many different things: running sync, passing conv=sync, conv=fdatasync, oflag=direct, writing 3 to /proc/sys/vm/drop_caches, turning off the USB nicely with udisksctl, waiting 30 seconds, trying to write zeroes with cat, etc. but none of them end up doing anything.

I even switched my Linux system to something else (something I almost never do) because the previous one was a buggy mess anyways, but, unsurprisingly, Linux is the buggy mess. This is a brand new, 1-day old Debian 11.

Any ideas?

Poopoo
  • 17
  • 1
    can you show us exact command use ? (start writing to a USB-backed block device is ambiguous) did you use cp to write file to a file system ? was it unmount ? if you use dd which device did you use ? (I suspect you use something like dd of=/dev/usba this would write to a file name /dev/usba) – Archemar Oct 03 '21 at 09:29
  • What I used was dd if=drive.bin of=/dev/sda bs=1M status=progress, and it worked fine until it suddenly didn't – Poopoo Oct 03 '21 at 09:31
  • 2
    Does this answer your question? How to prevent dd's progress from being meaningless on Linux? – Kusalananda Oct 03 '21 at 09:33
  • 2
    You have to run eject /dev/sdX before removing any usb storage device (or use whatever similar button in your GUI). Not only Linux is caching and lying, but the usb's device firmware does it too. I'm quite skeptical of some of the your claims, though. –  Oct 03 '21 at 09:43
  • The simplest explanation is you had written to /dev/sda before it was created as a block device file, so your USB got sdb. Or maybe it was already sdb for whatever reason. Or maybe this time it was not detected at the hardware level (one of my old laptops sometimes does not detect a USB drive until plugged in again). Anyway sda was a regular file with no connection to the USB whatsoever. You did not notice and worked with the regular file until the reboot. /dev is a virtual filesystem (in memory), the reboot destroyed the file and allowed the things to work as you expect. – Kamil Maciorowski Oct 03 '21 at 12:02
  • @KamilMaciorowski I doubt this is so, because I always check lsblk before any writing; the USB is always in /dev/sda – Poopoo Oct 05 '21 at 16:43
  • @UncleBilly So far, it works consistently. But it worked without eject the first few times, could you explain why? Feel free to write as an answer, and I'll mark it – Poopoo Oct 05 '21 at 16:44

1 Answers1

0

Running eject before unplugging seems to neutralize the problem.

Poopoo
  • 17