| === Keybuk [n=scott@descent.netsplit.com] has joined #ubuntu-boot | ||
| Keybuk | Mithrandir: yo | 10:02 |
|---|---|---|
| Mithrandir | dude! | 10:02 |
| Keybuk | right, so yes | 10:02 |
| Keybuk | readahead | 10:02 |
| Mithrandir | so, what's your plans for readahead? | 10:02 |
| Keybuk | mdz gave me this to overhaul as part of streamlined-boot | 10:02 |
| Keybuk | so my general problems with it were | 10:03 |
| Mithrandir | (and what does mean?) | 10:03 |
| Keybuk | 1) wayyy out of date lists | 10:03 |
| === Kamion [n=cjwatson@83-216-156-196.colinw664.adsl.metronet.co.uk] has joined #ubuntu-boot | ||
| Keybuk | 2) insufficient runs | 10:03 |
| Keybuk | 3) doesn't block-order its lists at the right time | 10:03 |
| Keybuk | (shutdown is not a point to do important things) | 10:03 |
| Keybuk | etc. | 10:03 |
| Keybuk | so my basic design for it was | 10:04 |
| Keybuk | - each package that includes an init.d script includes a file in /var/lib/readahead or similar listing the files it reads from | 10:04 |
| Keybuk | - readahead includes an audit tool that you can drop into a script to generate these files (using strace-parent, maps, etc. magic) | 10:04 |
| Keybuk | - each package also runs update-readahead in postinst | 10:04 |
| Keybuk | - that looks at rcS.d/rc2.d, picks the files from /var/lib/readahead, joins them together, and orders by block number | 10:05 |
| Mithrandir | I was thinking just having something in initramfs which uses inotify to record everything which is opened. List is saved at the end of the boot (or after five minutes) and reused next time. | 10:05 |
| Keybuk | inotify can't record when files are opened, and how they're opened? | 10:05 |
| Keybuk | and can only monitor one filesystem at a time | 10:06 |
| Mithrandir | #define IN_OPEN0x00000020/* File was opened */ | 10:06 |
| Mithrandir | huh? You can monitor as many file systems as you want? | 10:06 |
| Keybuk | Mithrandir: doesn't say whether it's for reading, writing, etc. | 10:06 |
| Keybuk | Mithrandir: yes, but then you need to monitor each filesystem as it's mounted | 10:06 |
| Keybuk | and there's no "filesystem mounted" event | 10:06 |
| Mithrandir | true, but that's possible to work around. | 10:07 |
| Mithrandir | the readahead might need to do multiple passes anyway. | 10:07 |
| Keybuk | yeah, I want to do a "very early" readahead pass | 10:08 |
| Keybuk | one after /usr is probably mounted | 10:08 |
| Keybuk | and maybe a final "gdm is up, now what?" push | 10:08 |
| Keybuk | and it's harder to split results of a single monitor if you do that | 10:08 |
| Keybuk | also on LiveCD where would you save the lists? :p | 10:09 |
| Keybuk | and where would you get the initial list? | 10:09 |
| Mithrandir | boot initially, upload it somewhere and we'd use a sample to decide what to put into the list. | 10:09 |
| Keybuk | but they won't be in anything like the right order for a real install | 10:09 |
| Mithrandir | not really, if you have a list of files to be readahead, do readahead on the ones which exist, then wait for some more to come into existence, then readahead those, repeat until all files have been read. | 10:09 |
| Kamion | I think I prefer Keybuk's approach - less likely to drift over time | 10:10 |
| Keybuk | which means the first boot (only boot for reviewers) is evily slow | 10:10 |
| Kamion | stuff that requires us to kick it every so often has a history of bitrotting (e.g., er, readahead) | 10:10 |
| Mithrandir | you'll end up readahead-ing the entirely wrong files in a lot of cases, though. Like, if you change your language, the localised files should be read ahead, not the english ones. | 10:11 |
| Kamion | for init scripts? | 10:11 |
| Mithrandir | huh? | 10:11 |
| Kamion | they aren't localised at the moment | 10:11 |
| Kamion | and what remains sounds like a relatively small number of files | 10:11 |
| Kamion | if need be, just readahead all the alternatives? | 10:12 |
| Mithrandir | well, I was going to reuse my hack for faster gnome startup. | 10:13 |
| Mithrandir | so you just say "record" at the start of the session, then "stop, give me the list of files" at the end | 10:13 |
| Mithrandir | and then use that list next time aroud. | 10:13 |
| Mithrandir | around, even | 10:13 |
| Keybuk | that's what we did to get the current useless lists though | 10:14 |
| Keybuk | they need more filtering than inotify provides | 10:14 |
| Keybuk | readinf /var/log/Xorg.0.log is kinda pointless, for example | 10:14 |
| Keybuk | as with things like the font caches, etc. | 10:14 |
| Mithrandir | you can see if the file was opened rw or not on close, though.. | 10:17 |
| Keybuk | it's also a bitch to find out _what_ opened it ;) | 10:17 |
| Mithrandir | why do we care, really? | 10:17 |
| Mithrandir | about who opened something | 10:17 |
| Keybuk | if we have multiple readahead phases | 10:17 |
| Mithrandir | well, I would advocate not having that | 10:19 |
| Keybuk | why not? | 10:19 |
| Keybuk | during the boot, we have three useful points where there's no disk I/P | 10:19 |
| Keybuk | uh, I/O | 10:19 |
| Keybuk | those seem the best bits to do readahead blips | 10:19 |
| Mithrandir | if we do readahead right, we should end up with about zero I/O outside readahead anyway, shouldn't we? | 10:21 |
| Keybuk | not necessarily | 10:23 |
| Keybuk | e.g. fsck ;) | 10:23 |
| Mithrandir | true, but that's a no-op in the usual case today. | 10:23 |
| Mithrandir | (in the usual case that you don't run a full fsck, which you usually don't) | 10:25 |
| Keybuk | depends on the fs | 10:27 |
| Keybuk | ext3 seems to use a lot of io to check its journal, for example | 10:27 |
| Mithrandir | isn't readahead prioritised below other I/O ops anyway? If not, can we make it? | 10:28 |
| Keybuk | I still don't like your solution though ;) | 10:29 |
| Keybuk | it doesn't do anything for LiveCD | 10:29 |
| Keybuk | because by its very definition, you have nowhere to write the updated lists | 10:30 |
| Keybuk | and I think it'll actually slow up the ordinary system boot by reading files that aren't necessary | 10:30 |
| Mithrandir | because it'll readahead Xorg.log? | 10:31 |
| Keybuk | because it'll readahead things at the wrong times | 10:33 |
| Keybuk | you can very easily over-readahead | 10:33 |
| Keybuk | so it takes longer to do that, then it would to read them normally | 10:33 |
| Mithrandir | I just think maintaining those lists by hand is going to suck and be based on a bunch of guesses more than anything else. | 10:35 |
| Keybuk | ie. if the time to do the readahead is greater than the benefit of doing so, then you lose | 10:35 |
| Keybuk | thom and I find when first doing it that you had to write them by hand | 10:35 |
| Keybuk | because the automatic ones didn't give you much benefit | 10:35 |
| Keybuk | they just shifted the I/O about | 10:36 |
| Mithrandir | well, it really is about shifting the I/O about. :-) You'll always end up reading at least the same amount as before. | 10:37 |
| Keybuk | another problem I can forsee with your idea is failed boots | 10:40 |
| Keybuk | the next boot, you'll end up readaheading all the things you used to fix the last boot | 10:40 |
| Keybuk | etc. | 10:40 |
| Mithrandir | possibly, yes. | 10:40 |
| Keybuk | or switching between kernels will have similar issues | 10:40 |
| Mithrandir | it reduces the stability of the boot lenght. | 10:40 |
| Mithrandir | length, even | 10:40 |
| Keybuk | to me, this really does cry out to be a package-level thing ;) | 10:40 |
| Keybuk | here's my (automatically generated and manually weeded) list of things I cause to be read in each package | 10:41 |
| Keybuk | lang packs would include those too | 10:41 |
| === fabbione [i=fabbione@gordian.fabbione.net] has joined #ubuntu-boot | ||
| === makx [n=max@213.239.196.228] has joined #ubuntu-boot | ||
| === JanC [n=janc@lugwv/member/JanC] has joined #ubuntu-boot | ||
| Mithrandir | Keybuk: we can try with your method, I guess. When will you have it ready? :-) | 12:53 |
| === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-boot | ||
| Keybuk | Mithrandir: been playing all afternoon so far <g> | 05:36 |
| Keybuk | I like yours now, much easier to code than mine | 05:37 |
| Keybuk | in fact, I have a cunning idea for a "profile" command-line option that enables both readahead profiling and boot charting | 05:37 |
| Keybuk | so we could ship bootchart by default <g> | 05:37 |
| Mithrandir | you do know that bootchart doesn't do anything by default now? | 05:59 |
| Keybuk | this might explain something | 05:59 |
| Keybuk | you know we have a mailing list? ubuntu-devel-announce | 06:00 |
| Keybuk | for when you change that kind of thing <g> | 06:00 |
| Keybuk | users have been complaining at me for the last few days that bootchart stopped working, haven't got around to investigating yet | 06:00 |
| Keybuk | you could've had a small nuke thrown at you :p | 06:00 |
| Mithrandir | you know, it's in the bloody changelog. | 06:00 |
| Keybuk | who reads those?! :p | 06:00 |
| Mithrandir | I, at least. | 06:00 |
| Mithrandir | especially if I wonder why something changes. | 06:01 |
| Keybuk | meh, any particular reason you disabled it? | 06:01 |
| Mithrandir | yes, it's on the live cd. | 06:01 |
| Keybuk | why always? | 06:01 |
| Mithrandir | because there's no way to know you're on a live cd when bootchart runs. | 06:01 |
| Mithrandir | it's just adding a small bootchart=enable to run it. | 06:01 |
| Keybuk | oh, of course, you can't add it to the live cd | 06:02 |
| Keybuk | lol | 06:02 |
| Mithrandir | or bootchart=upload to upload the graph. | 06:02 |
| Keybuk | upload the graph where? :p | 06:02 |
| Mithrandir | bootchart.err.no | 06:02 |
| Mithrandir | _that_ on the other hand, should probably have gone to u-d-a. :-P | 06:02 |
| Keybuk | heh, given the amount of stuff I'm doing with boot charting right now .... | 06:02 |
| Keybuk | it would've been nice if you'd at least told _me_ about that :p | 06:02 |
| Keybuk | but yes, that should go to u-d-a | 06:02 |
| Keybuk | could you mail it? :p | 06:02 |
| Mithrandir | I did this change a month or so ago. | 06:02 |
| Mithrandir | sure | 06:02 |
| Keybuk | I guess they can't be tagged distro/not-distro ? | 06:03 |
| Keybuk | err | 06:03 |
| Keybuk | live/real | 06:03 |
| Mithrandir | sure | 06:03 |
| Keybuk | otherwise it's hard to keep track | 06:03 |
| Mithrandir | bootchart=enable,$tag | 06:03 |
| Mithrandir | iirc | 06:03 |
| Mithrandir | sorry, upload,$tag | 06:03 |
| Keybuk | :) | 06:04 |
| Keybuk | now, send that mail, bitch :D | 06:04 |
| Mithrandir | bootchart (0.9-0ubuntu5) dapper; urgency=low | 06:06 |
| Mithrandir | * Add bootchart=disabled and bootchart=upload,$type arguments which will | 06:06 |
| Mithrandir | respectively disable bootcharting and upload charts to | 06:06 |
| Mithrandir | bootchart.err.no. | 06:06 |
| Mithrandir | -- Tollef Fog Heen <tfheen@ubuntu.com> Mon, 19 Dec 2005 13:52:35 +0100 | 06:06 |
| Mithrandir | so, about a month ago wasn't that bad. | 06:06 |
| Mithrandir | you haven't touched bootchart since Nov 30th. :-P | 06:06 |
| Mithrandir | but sure, I'll send da mail | 06:06 |
| Keybuk | I haven't updated my laptop properly since before xmas, no | 06:08 |
| Keybuk | so hadn't picked up that new version yet | 06:08 |
| Keybuk | is it enabled or disabled by default? | 06:09 |
| Mithrandir | hmm | 06:09 |
| Mithrandir | it's enabled by default | 06:09 |
| Mithrandir | grep -q "bootchart=disable" /proc/cmdline && exit 0 | 06:09 |
| Mithrandir | so it's not my fault. :-P | 06:10 |
| Mithrandir | doko's probably broken gcj or something | 06:10 |
| Keybuk | you're so going in the dry dock <g> | 06:10 |
| Mithrandir | I can't remember random changes I did a month ago | 06:10 |
| Mithrandir | (without looking at changelogs, etc) | 06:10 |
| Keybuk | I do, perhaps, think that holding a distro team sprint in an area with amble bodies of still water is a *bad* idea | 06:11 |
| Mithrandir | why? :-) | 06:11 |
| Keybuk | amble opportunity for solving grudges <g> | 06:19 |
| Keybuk | you did *what* to initramfs?! *splash* | 06:19 |
| Mithrandir | well, I did suggest paintball. | 06:20 |
| Mithrandir | I'm sure there are shops in London renting out gear. | 06:20 |
| Keybuk | that'd rock | 06:21 |
| === Keybuk [n=scott@descent.netsplit.com] has joined #ubuntu-boot | ||
| === Kamion [n=cjwatson@83-216-156-196.colinw664.adsl.metronet.co.uk] has joined #ubuntu-boot | ||
| === mc76 [n=mcaamano@200.91.139.154] has joined #ubuntu-boot | ||
| mc76 | hi, I am trying to install breezy in a Dell Dimension 3100 and the installer hangs right after launching syslogd kdlogd. Has anyone seen this before or know how to get pass this? I already tried all the boot options in the disk and searched google for it (other people report the same issue but none report a fix) any suggestions where I can look for more info? | 10:34 |
| === mc76 [n=mcaamano@200.91.139.154] has left #ubuntu-boot ["Leaving"] | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!