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?

Improve this question
7
  • 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) Commented Oct 3, 2021 at 9: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 Commented Oct 3, 2021 at 9:31
  • 2
    Does this answer your question? How to prevent dd's progress from being meaningless on Linux? Commented Oct 3, 2021 at 9: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. Commented Oct 3, 2021 at 9: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. Commented Oct 3, 2021 at 12:02

1 Answer 1

Reset to default
0

Running eject before unplugging seems to neutralize the problem.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.