2010/4/27 Matthias König <mk@xxxxxxxxxxxx>: > Kay Sievers <kay.sievers@xxxxxxxx> wrote: >> On Tue, Apr 27, 2010 at 13:07, Karel Zak <kzak@xxxxxxxxxx> wrote: >> > On Mon, Apr 26, 2010 at 02:43:06PM +0100, Tony McConnell wrote: >> >> I've started using 2.17.2, and discovered that there is now a large >> >> delay before mount returns when there is no medium in the optical >> >> drive. Version 2.14.1 didn't have this delay. >> >> >> >> Question: Is it possible to make CRDOM_NOMEDIUM_RETRIES (from >> >> blkdev.h) configurable via parameter? Or is there a better way to >> >> detect presence of media? >> > >> > I don't want to add an extra option for this thing. >> > >> >> This now adds 15 seconds onto my apps startup-time... >> > >> > Maybe we can use something more sane, 3 retries with 1 second delay >> > (= whole delay 3 seconds). Or we can remove this "feature" at all. >> >> People optimize things that are used on bootup for sub-seconds, and >> now we possibly do a 15 seconds delay, tsss :) >> >> I'm sure mount(8) is absolutely the wrong place to do anything like >> this. It should just fail when there is nothing to read. > > Orly!? ;) > Well, I remember this one very clearly, because I also tried to reject > this with the same argument. So please, before reinventing the discussion > from scratch, here is the original bug report which enforced this fix: > https://bugzilla.novell.com/show_bug.cgi?id=390204 > > And I guess you'll have to deal with bugs like this if you remove this > "feature" (of course, I am *not* saying my specific fix was the best way > to get rid of the problem and I am also not sure how things are now in > Kernel land, so it might be worth reinvestigating this ;) Yep, I think that's fine. It needs to be fixed in Yast, not in mount(8). There is usually no point in making low-level system tools wait for something that might never happen. Kay -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
