Description of problem: During install the filename "none" is looked up 9544 times, usually in this sequence (from strace): ----- 719 stat("rootfs", 0x7fff3f67cd00) = -1 ENOENT (No such file or directory) 719 stat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 719 stat("/dev", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=2820, ...}) = 0 719 stat("/dev/pts", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 719 stat("/sys", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 719 stat("none", 0x7fff3f67cd00) = -1 ENOENT (No such file or directory) 719 stat("none", 0x7fff3f67cd00) = -1 ENOENT (No such file or directory) 719 stat("/proc/bus/usb", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 719 stat("/tmp/cdrom", 0x7fff3f67d3b0) = -1 ENOENT (No such file or directory) 719 stat("/tmp/loop0", {st_mode=S_IFBLK|0600, st_rdev=makedev(7, 0), ...}) = 0 719 stat("/selinux", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 ----- where 719 is the pid of the main anaconda process. This looks like an obnoxious workaround for not being able to handle a null string. Version-Release number of selected component (if applicable): anaconda-11.3.0.45-1 How reproducible: always Steps to Reproduce: 1. as soon as vtty2 becomes available: strace -f -o '|gzip' -p <pid-of-anaconda> > strace.out & (you have to provide strace on a USB flash memory device before boot, and mount the device yourself.) 2. inspect strace.out (63MB compressed, 1GB uncompressed) for ENOENT of "none" 3. Actual results: "none" is looked up 9544 times. Expected results: "none" is never looked up. Additional info:
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Does this persist in Fedora 9?
Yes, it persists in Fedora 9. A likely cause is iterating over the lines of /proc/mounts without removing the "none" tokens. Example: ===== $ cat /proc/mounts rootfs / rootfs rw 0 0 /dev /dev tmpfs rw 0 0 /dev/root / ext3 rw,nodiratime,data=ordered 0 0 none /selinux selinuxfs rw 0 0 [snip] =====
We never actually read /proc/mounts, at least not in directly anaconda. It'd be interesting to correlate the strace output with the /tmp/anaconda.log so we could get some sort of clue as to where this is going on.
I just did a minimal graphical install (unchecked "Office and Productivity") of Fedora 9 from DVD. There were 216 lookups of "none", and they were all the result of reading lines from /proc/mounts or /etc/mtab [alternating] by anaconda itself. Here's one relevant strace output: ----- 1505 open("/proc/mounts", O_RDONLY|O_LARGEFILE) = 15 1505 fstat64(15, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 1505 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e0b000 1505 read(15, "rootfs / rootfs rw,relatime 0 0\n"..., 1024) = 447 1505 stat64("rootfs", 0xbf9d0b38) = -1 ENOENT (No such file or directory) 1505 stat64("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 1505 stat64("/dev", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=3960, ...}) = 0 1505 stat64("/dev/pts", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 1505 stat64("/sys", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 1505 stat64("none", 0xbf9d0b38) = -1 ENOENT (No such file or directory) 1505 stat64("/dev/sr0", {st_mode=S_IFBLK|0640, st_rdev=makedev(11, 0), ...}) = 0 1505 stat64("/dev/loop0", {st_mode=S_IFBLK|0640, st_rdev=makedev(7, 0), ...}) = 0 1505 stat64("/selinux", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 1505 stat64("/dev/sdc1", {st_mode=S_IFBLK|0640, st_rdev=makedev(8, 33), ...}) = 0 1505 read(15, "", 1024) = 0 1505 close(15) = 0 -----
Oh I see now. If you look, we always go try /proc/mounts, then /proc/swaps, then /etc/mtab in that order. There's nowhere in anaconda where we open /proc/mounts in this kind of loop, and we never open /etc/mtab in read-only mode. So, it must be happening elsewhere. Well the obvious place to look is parted and if you check out libparted/arch/linux.c, you will see the following block of code: static int _partition_is_mounted_by_dev (dev_t dev) { return _mount_table_search( "/proc/mounts", dev) || _mount_table_search( "/proc/swaps", dev) || _mount_table_search( "/etc/mtab", dev); } AH, the same order we were seeing over and over again in the strace output. So, parted's _mount_table_search function should probably be made smarter to not try to read 'none' over and over again.
This is just parted checking to see if the file actually exists. Guess there could be a function that checks to see if the string is correct, but I would not hold my breath for it.
*** Bug 354931 has been marked as a duplicate of this bug. ***
mmmm. This is worse than I thought. I not only checks for the none, but also for the other first appearances of none files in mtab and the others (like tmpfs, sunrpc...) The best thing to do here to avoid these unnecessary IO searches is to not consider a string that is not a full path. That is, ignore everything that does not have a '/' at the beginning of the string. Will come up with a patch shortly :)
Created attachment 322324 [details] don't open strings that dont start with "/". Here is a patch, but going to hold it up until the f10 branch comes out. So we don't inadvertently break something in the process.
Should be in rawhide.