Recent searches
Search options
Lazyweb, what's a reasonable removable media filesystem to use for a ridiculously large number of smallish files, hundreds of GB total? FAT32 is just incredibly slow.
FFS, copying speed is like in the tens of MB/min range...
it's not the fs it's the actual drive being a piece of 
. dd from it to /dev/null is 5-7 MB/s... vs over 100 with a different drive.
@dalias dd to the drive or a file?
I've seen dd to external drives be bizarrely slow if you are dd'ing over the device node with the default tiny block size. When I want to do that then usually adding bs=128k makes it much faster.
Also adding oflag=direct is sometimes helpful to prevent Linux from just buffering the writes for a while instead of sending them out immediately.
@0x2ba22e11 *From* the drive (/dev/sdb1) with bs=64k.
@dalias ah I misread, my bad. Totally different situation.
@0x2ba22e11 Something is wrong with it. Not only new drives of different model, but another identical one from the same batch, are all orders of magnitude faster with same dd command. It's got to have done something stupid shuffling its blocks...
@dalias I would be suspicious that the drive might be on its way out.
But on the off chance, apparently there's a recent program called blkdiscard for issuing TRIM commands for whole drives, if you wanted to give the firmware a shot at untangling its data structures? https://superuser.com/a/645740
@0x2ba22e11 Yeah I'm worried about that too.
@0x2ba22e11 
could it just be messed up USB3 contacts in the drive's connector? It gets a USB3 bus address when it connects though so I kinda doubt that..
@0x2ba22e11 At least the whole thing copied without errors. At the rate it was going I was predicting 10-24 hours but it finished in under 10. I guess I could further verify that with hashes if I wanted since every single file's name is its sha3 hash.
@dalias heh nice. content addressed storage really is great for checking storage integrity :)