Using scp to copy wolverine ISO images to a vfat filesystem with magicdev
running causes the kernel to chew up CPU (up to about 93% as write cache
approaches full), rendering the system painfully slow. Same test with ext2
fs shows (the expected) negligible impact. For folks using multi-boot (for
evil-empire OSs), this is pretty much a show stopper. (Sorry, Alan.)
does this also show without magicdev ?
(not to blame magicdev but to find if there is an interaction)
I ran 4 tests: vfat + magicdev (slow); vfat - magicdev (ok); ext2 + magicdev
(ok); ext2 -magicdev (ok). So, yes, there is an interaction with vfat &
magicdev. Just FYI, here's the /etc/mtab in question (since magicdev reads it
once per loop; why not just stat() it, and open if st_mtime changes?):
[mshannon@beast mshannon]$ cat /etc/mtab
/dev/hda5 / ext2 rw 0 0
none /proc proc rw 0 0
usbdevfs /proc/bus/usb usbdevfs rw 0 0
/dev/hda1 /boot ext2 rw 0 0
/dev/hda7 /export/home ext2 rw 0 0
/dev/hda2 /mnt/nt4c vfat rw,uid=500,gid=500 0 0
/dev/hda3 /mnt/w98c vfat rw,uid=500,gid=500 0 0
/dev/hdc1 /b0 vfat rw,uid=500,gid=500 0 0
/dev/hdd1 /b1 vfat rw,uid=500,gid=500 0 0
none /dev/pts devpts rw,gid=5,mode=620 0 0
automount(pid753) /misc autofs rw,fd=5,pgrp=753,minproto=2,maxproto=3 0 0
The vfat target was /b0; the ext2 target was /export/home. If I can supply any
other info, please let me know!
This defect is considered MUST-FIX for Florence Gold release
What kind of hardware is this?
Could you give us a summary report (processor, chipset,
disk controller) and the output of "lspci -v" please? Thanks!
If you are still seeing this with Red Hat Linux 7.1, please try the
errata kernel 2.4.3-12. If you are still seeing it with the errata
kernel please re-open this bug report. Thanks!