On 14-06-17 06:20 PM, Andrew Morton wrote: > On Wed, 4 Jun 2014 14:01:35 -0400 Paul Gortmaker > <paul.gortma...@windriver.com> wrote: > >> Currently rootdelay=N and rootwait behave differently (aside >> from the obvious unbounded wait duration) because they are >> at different places in the init sequence. >> >> The difference manifests itself for md devices because the >> call to md_run_setup() lives between rootdelay and rootwait, >> so if you try to use rootdelay=20 to try and allow a slow >> RAID0 array to assemble, you get this: >> >> [ 4.526011] sd 6:0:0:0: [sdc] Attached SCSI removable disk >> [ 22.972079] md: Waiting for all devices to be available before autodetect >> >> i.e. you've achieved nothing other than delaying the probing >> 20s, when what you wanted was a 20s delay _after_ the probing >> for md devices was initiated. >> >> Here we move the rootdelay code to be right beside the rootwait >> code, so that their behaviour is consistent. >> >> It should be noted that in doing so, the actions based on the >> saved_root_name[0] and initrd_load() were previously put on >> hold by rootdelay=N and now currently will not be delayed. >> However, I think consistent behaviour is more important than >> matching historical behaviour of delaying the above two operations. > > hm. There may be good reasons for inserting a delay between scsi init > and MD init - give things time to settle down before MD starts playing > with the disks? And I think your patch takes away that option?
In theory, md should never need that, since as per the message above, MD does a wait_for_device_probe(). I was trying to get a wait inserted between md0 creation and mount of root, which failed as noted. > > The kernel-parameters.txt documentation for these things is rather > vague. We have three distinct phases, I think? > > a) scsi init > b) [md init] > c) root mount > > It's not terribly clear where rootdelay and rootwait are operating and > I expect there are gaps in the implementation anyway. > > Do you think it's worth cleaning and clearing all this up in some fashion? Sure. Not clear how though. One option would be to deprecate rootwait in favour of rootdelay=-1 (or rootdelay=0) as an indication that the user wants infinite wait. That still means only one delay point in your a-b-c chain above though, but I'm hoping that is OK. Other ideas? > > The whole thing is a bit of an admission of failure anyway, isn't it? > Why should the kernel ever need to perform arbitrary dopey delays like > this? Are we working around unresolved underlying bugs? Well to be fair, I'd agree with the above. I was trying it as a last ditch attempt to fix an unrelated issue (and imagine that, it failed to fix anything) but in that attempt, I noted the glaring inconsistency between rootdelay= and rootwait. Paul. -- > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
