[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: A stern warning of things to come

On 08/03/2010 01:37 PM, clumens redhat com wrote:
>>> (1) It's possible some PXE implementations will not like downloading a single
>>> 100+ MB image.  I'm hoping the number of machines affected is decreasing every
>>> year and we can rapidly stop caring.
>> This is actually of some concern, primarily that downloading within PXE
>> (of any type) is quite slow.  It's doable, but there are a few PXE
>> stacks that will barf on something that big.  Some of those can be
>> "fixed" by chaining first to gPXE then to the install.
> Any ideas how common these implementations are, and on what kinds of
> machines?

I'd have to run through the stack of network cards in my closet (and
probably ask a few of the gPXE and iPXE guys to do the same to get an
exhaustive list).  I would have to verify it, but I'm pretty sure some
of the 3com's I've got (older 10, 10/100 cards) have problems above 64M
I think.  That said, I haven't seen a problem on anything I would
consider modern.

Again though, if there's problems the older cards likely have good
[gi]PXE drivers and thus the problem can likely be gotten around that
way too.

>> http://boot.kernel.org/bko/pxeknife/linux_boot_disks/rip/tftpboot/rootfs.cgz
>> is an initrd of roughly the size your proposing, and one I know works.
>> Various download times:
>> the above link with wget across the internet to my home:
>> 69s - 1.37 MB/s
>> With tftp from a server in my house to my laptop (with a wifi link involved)
>> 6:15.60 - 262 KB/s
>> Same tftp server only only wired (100mbps)
>> 43.034s - 2.1 MB/s
> The test installs I've done here haven't seemed to take this long (they
> definitely don't take six minutes, they may take 43 seconds) across a
> wired network.  There's also a sizeable delay when the kernel gets to
> unpacking the image.

Well the 6 minute download looks like a worst case scenario, it is
something that should be noted that users are going to be waiting longer
at a point where there's no good way to explain why there's a big delay
going on though.

>>> (3) Memory requirements may be increased.
>> It would effectively kill off anything with less than 256M of ram from
>> doing an install.  I wouldn't think this is common anymore, but I know
>> machines with 512M of ram are still in production today, and running Fedora.
> These are basically dead anyway, and getting moreso all the time:
> #if defined(__powerpc64__) || defined(__sparc__)
>   #define MIN_RAM                 1024*1024 // 1 GB
>   #define GUI_INSTALL_EXTRA_RAM   512*1024  // 512 MB
> #else
>   #define MIN_RAM                 256 * 1024 // 256 MB
>   #define GUI_INSTALL_EXTRA_RAM   128 * 1024 // 128 MB
> #endif
> #define URL_INSTALL_EXTRA_RAM   128 * 1024 // 128 MB
> #define EARLY_SWAP_RAM          512 * 1024 // 512 MB
> I kind of think MIN_RAM in the normal case is a lie anyway.

Probably, the boxes I know that have 512MB of ram in them are old [READ:
~500mhz range old].  The big question here is do you want to raise the
minimum amount of ram for a system beyond what is defined already?
Modern machines are shipping with at least 1GB of ram these days, but
how many people are still running on old kit?

>> Just some thoughts, I'm not sure if this kind of change would ultimately
>> be good or bad.  The biggest problem I can see if the want for an ever
>> increasing initrd.
> It's such a massive improvement in maintainability and reliability that
> I think it's definitely for the best.  Just removing the state machines
> in loader alone would drastically cut down on the number of weird method
> selection bugs we've got.  This is the kind of stuff that end users
> aren't directly going to notice, but they'll experience fewer bugs and
> we'll have more time to work on other stuff.
> I understand the problem about the magic growing initrd.  I'm not sure
> how we can address that (especially given our desire to use system stuff
> - see Martin's other thread on the list).  We'll need to be careful.

Anything that makes the maintainability and reliability better is
definitely a good thing, the big question is are the downsides, that may
be inherent with this, ok?  I'm just trying to raise the yellow caution
flags where I see them, but that said I don't think this is a bad idea.
 This would unify the install image type, and probably even make dealing
with the live isos easier (mainly that you've already got an initrd that
has everything in place to talk to any storage mechanism).

If you've got any images built up using a larger, more inclusive, initrd
I'd be more than happy to give them a go on anything I've got lying
around here for testing, particularly on the network cards I've got in
the drawer.

- John 'Warthog9' Hawley

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]