USB I/O draining my userspace (Ubuntu Natty 64b)

[guy keren]

On Wed, 2011-06-15 at 18:42 +0300, Ira Abramov wrote:
> Quoting Yedidyah Bar-David, from the post of Wed, 15 Jun:
> > 
> > Perhaps it uses USB1 and not 2?
> 
> nope, I had that problem when I accidentally switched ports to a USB1
> port, the 22 minute burn took over 113 minutes before I noticed it was
> still writing and killed it.
> 
> also, to answer Geoff - nothing else is on the USB, the M/K are on PS/2
> connectors. Maybe the same controller chip, but not the same bus or
> kernel module.
> 
> at least with oflag=dsync it doesn't get the entire userspace stuck,
> whatever that does.

a few side-notes:

1. what oflag=dsync does (oflag=direct will do it too) is bypass linux's
buffer cache. this means that it does not polute the buffer cache with
one-time garbage. dd without an oflag writes to the cache, and pages
stored there for other apps get dumped or flushed to disk - causing the
effects you see. using 'direct' is better for your flash (although it
could be that on a USB drive, dsync and direct map to the same
underlying operations).

2. regarding the block size - the optimal size will be the erase-unit of
your flash. check out the specifications of the unit you have (you care
about the flash controller it the unit - not about the flash memory
itself) - and supply this as the block size to DD. erase-units are
usually several 10s or 100s of KB. writes not done using these units,
will cause several data-copy operations per operating system write I/Os,
to be performed by the flash controller.

    note: since you already made writes using the old notion - which
probably caused fragmentation of the flash memory - it might be a good
idea to find whether you can reset your USB drive before doing the next
copy.

--guy


> 
> bs=8M is the next parameter I'll try, or maybe I should go for 32M?
> 
> > Can you rmmod all *hci_ucd modules except for ehci_hcd and see what
> > happens?
> 
> nope, I assumed Ubuntu would have taken precautions not to insmod
> anything useless for my hardware...
> 
> > 
> > Did you try cp (or cp --sparse=always if you really want to) and
> > see if it helps? I don't know of a similar option for dd.
> 
> I have here an image with partitions in it, which is why I use DD. cp
> can't help me, sadly.
>