New answers tagged

3

This drive isn't a USB device, but a SATA device which is accessed via the Genesys bridge (which is a USB device). Since it isn't itself a USB device, it doesn't show up in lsusb's output. USB thumb drives are USB devices without bridges (well, usually), so they do show up as-is on the USB bus and in lsusb's output.


1

Here is a way to check some default cache mode. Although it's also kind of documentation, it's "online" and you get the default cache mode of your current QEMU version. As @dokotr5000 said, it depends on the version. Run "qemu-img -h" and search for the "cache" part. You will find something like the following. 'cache' is the cache mode used to write the ...


2

iotop shows statistics from several different origins; take care when adding up stuff. This previous discussion covers the difference between per-process read/write amounts and the system total read/write amounts: they cover different stuff since the per-process amounts include all I/O (whether to disk, to cache, to network, etc.) whereas the system total ...


0

Here is my guess of what happened. Your .xsession-errors file got filled up with 650+MB worth of junk. This filled up your home partition. Lots of programs that are still running continue to run and attempt to write to files on the home partition. Some pointers below that describe some gotchas with his. Real Disk Space To check the disk usage on your ...


0

For over a year I have been fighting a battle with partitions and drives corruptiong on me without rhyme or reason. Even from a LiveCD I would hit snags as I struggled to get control and recover data. I was ready to turn to recovery tools, but found hope that gparted with gpart could manage what I really needed was just to get my data off to a backup, then ...


1

The read-only test only reads. That's basically the default testing method for just about everything and pretty much the same what disks do for SMART self-tests. The non-destructive read-write test works by overwriting data, then reading to verify, and then writing the original data back afterwards. The only way to verify that writing data works is by ...


0

Ypu can write your own FUSE filesystem (what you can do using almost any scripting/programming language, even bash) , that would just proxy filesystem calls to pointed filesystem (and eventually translate paths) plus monitor what you minght want to monitor. Otherwise you might investigate output of strace for programs performing I/O calls ofninterest, if ...


0

This script would do the trick, at least for most typical scenarios. It requires on blkid, lsscsi and sed: #!/bin/bash mkdir -p /dev/disk/by-{path,uuid} for dev in `blkid -o device | grep -v block`; do ln -s "$dev" "/dev/disk/by-uuid/$(blkid -o value -s UUID "$dev")" done lsscsi -v | sed 'N;s/\n//' |\ sed ...



Top 50 recent answers are included