The Thursday 24 July 2008 15:27:01 Martin McCormick, you wrote : > I needed to reload the flash drive on a Zenstone 2-gig mp3 > player. I have noticed that when the drive is full, operations > all still work, but take much longer than one might expect which > probably has something to do with the fat32 file system and size > of the FAT table. > > I started by doing rm -r -f music which is the one and > only main directory. That took about 2 hours to complete and > then it was time to reload it from the Linux computer. > > The Linux computer is a 500-MHZ Pentium running a 2.6.5 > kernel and the usb2 port is, by definition 13 Mb so it is slow, > about 10-meg Ethernet slow under normal conditions. > > What actually happens is much worse. After doing the rm > -r -f, I started with an empty drive but the tar program started > running very slowly. It takes at times, 10 minutes to load one > tune that would normally play in 2 or 3 minutes. > > Just for fun, I let it plod slowly along and it has been > running now for about 36 hours and is 75% complete but what is > happening? > > If I look at the health of the system, it isn't that bad > all be it busy. > > $ uptime > > 07:21:58 up 2 days, 23:37, 2 users, load average: 4.00, 4.13, 4.19
Wow, a load average of 4 ? It should be that CPU hungry I think. It shouldn't need lots of CPU to make a transfert. Did you try with another key ? Try the dd command suggested by Elijah. If it's fast, then you'll be sure it's not a USB problem. Maybe a badly written driver ? I don't know, I never heard of something like that. > > It is July 24 and ps ax -Olstart shows me that tar has > been running a very long time: > > 22986 Tue Jul 22 23:35:01 2008 D pts/13 00:00:40 tar xf > /home/martin/musicmain.tar > > I tried renic-ing tar and the usb mass storage daemon > which has had no effect, either good or bad. > > I do remember once that if there is a time lapse of > several minutes between the rm -r -f command to wipe the FAT > table clean and the tar command that initial performance is much > better so there must be a cleanup routine going on somewhere. > > This is also true if you unmount the drive and remount it empty. > I seem to remember that it only took a couple of hours to reload > the entire drive when I did things that way. > > I did a top command and I am either missing something or nothing > much is wrong: > > Tasks: 42 total, 2 running, 40 sleeping, 0 stopped, 0 zombie > Cpu(s): 0.3% us, 0.0% sy, 0.0% ni, 0.0% id, 99.7% wa, 0.0% hi, 0.0% > si Mem: 126424k total, 124572k used, 1852k free, 1604k buffers > Swap: 377488k total, 0k used, 377488k free, 102308k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 23560 martin 16 0 2160 1084 1880 R 0.3 0.9 0:00.03 top > 1 root 16 0 1492 528 1336 S 0.0 0.4 0:07.26 init > 2 root 34 19 0 0 0 S 0.0 0.0 0:12.13 ksoftirqd/0 > 3 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 events/0 > 4 root 5 -10 0 0 0 S 0.0 0.0 0:04.02 kblockd/0 > 10 root 7 -10 0 0 0 S 0.0 0.0 0:00.00 aio/0 > 9 root 15 0 0 0 0 S 0.0 0.0 0:22.06 kswapd0 > 11 root 25 0 0 0 0 S 0.0 0.0 0:00.00 jfsIO > > I plan to let this tar command run its natural course to see > what happens, but is there anything I can do with the existing > system to optimise the performance? > > Thanks. > > Martin McCormick WB5AGZ Stillwater, OK > Systems Engineer > OSU Information Technology Department Network Operations Group -- Thomas Preud'homme Why debian : http://www.debian.org/intro/why_debian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
