On Fri, 5 Mar 2010 16:46:26 -0500 nixlists <nixmli...@gmail.com> wrote:

> On 3/5/10, J.C. Roberts <list-...@designtools.org> wrote:
> 
> >
> >  look for the `-p` flag.
> >
> 
> Know all about it. The problem is the kernel won't even get to that
> point - it hangs on "syncing disks..." stage.

Though the archive link from Frank Bax is interesting and possibly
related (covered below), you gotta understand your hardware.

Many types of flash storage are *PAINFULLY* slow when they're brand
new, and only continue to get slower over time/use. If you're using an
old CF card, you most certainly have a contributing factor to the
amount of time it will take to sync the disk on shutdown.

Though the typical USB 2.0 marketing claims "480 MiBit/s" (a.k.a.
"high speed"), the claims are bullshit. If you do the rough calculation
of 480/8, you get 60 MiByte/s, but the thing they never bother to tell
you is they are *including* the overhead of the encoding and protocol.
USB 2.0 uses 8b/10b encoding, so there's 20% overhead right there. With
everything included, you actually lose about 33% or more, so the
interface can move about 40 MiByte/s or slower of real data.

USB is a long way from "fast" for a disk interface but the above tells
you that USB is *seems* to not be the issue. Also, your dmesg data shows
EHCI, so you at least it *seems* you're running at USB 2.0 "high speed"
rather than the much slower "Low Speed" (1.5 MiBit/s) or "Standard
Speed" (12 Mbit/s), which are denoted by UHCI or OHCI. 

Yes, the "*seems*" is important. Some devices can (and sadly will)
silently downgrade to lower speeds, so the output of `usbdevs -vvv` can
be very handy. Though `usbdevs` should be accurate, cheap USB devices
(such as a CF reader) can do very ugly things and `usbdevs` may not
catch everything.

OK. We've got your storage media, CF Disk, covered. We've got your
interface, USB, covered. We even have your card reader, possibly cheap
and downgrading, covered.

So what's next?

The next bus stop is reality. Better known as testing your own hardware
to see what it does. The following results are from tests I was doing
this morning with brand name (Corsair) but typical USB 2.0 Flash
Disk/Stick/Thumb or whatever the hell you want to call it. Though
a CF Disk is a different beast, it's still roughly similar tech
internally, so the following results are at least somewhat comparable to
your situation.

***********************************************************************
# dd if=/dev/rsd0c of=corsair.dump count=8011776
8011776+0 records in
8011776+0 records out
4102029312 bytes transferred in 7363.861 secs (557049 bytes/sec)

# dd of=/dev/rsd0c if=iodisk.dump              
493568+0 records in
493568+0 records out
252706816 bytes transferred in 1575.815 secs (160366 bytes/sec)
***********************************************************************

Ya, with USB 2.0, the read speed is roughly 0.5 MiByte/s, and the write
speed is roughly 0.125 MiByte/s without ANY file system overhead. If
you were actually writing to a file system, it would be even slower.

Cheap/typical platter based hard drives write at 40 MiByte/s or *much*
better... YES, A CHEAP HARD DISK IS AT LEAST 320 TIMES FASTER!

If someone with a cheap hard drive has to wait 10 seconds for a
shutdown, by comparison, you would have to wait 53 MINUTES.

When you `halt` your system, it preforms a `sync` to make sure all data
is written (flushed) to disk. If your write speed is miserable like the
above Flash Stick numbers, then you will have to wait some time until
the `sync` finally completes.

Now getting back to the link/problem posted by Frank which mentions
firefox, as well as your complaint about the speed of firefox... Yep,
the final stop on the reality tour is most likely the fact that firefox
might be *STILL* trying to shut down because the disk write speed sucks
so bad. This of course means, sync is waiting on it. If you use a
bloated "Desktop" like kde or gnome, they may also be a contributing
factor to your shutdown times and for the same reason.

Configure firefox to not use a disk cache at all (e.g. run from RAM
only), or better look into the "read-only" CD-ROM installations since
newer firefox crap does a lot of sqlite database crap. Also, running a
light desktop like cwm or scrotwm might help.

There are lots of different "tricks" for using CF cards and similar
slow media, so if you insist on using them, be prepared to do a whole
lot of searching and reading.

        jon

Reply via email to