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

Re: A stern warning of things to come

> > (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

> 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.

> > (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
  #define MIN_RAM                 256 * 1024 // 256 MB
  #define GUI_INSTALL_EXTRA_RAM   128 * 1024 // 128 MB
#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.

> 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.

- Chris

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