9627 No longer need 32-bit boot_archive

Review Request #1120 — Created June 27, 2018 and submitted

citrus
illumos-gate
master
9627, 9628
ecaf22c...
general
citrus

9627 No longer need 32-bit boot_archive / 9628 UFS boot archives are too large

Tested by creating HSFS and UFS archives with both old and new code, comparing the contents and test booting a server with the new archives.

Also fixed a bug with UFS archives where too much space was being reserved (issue 9628)

Before: boot archive is almost twice as big as necessary due to reserving far too much space for directories.

bloody# /boot/solaris/bin/create_ramdisk --nocompress
updating /platform/i86pc/amd64/boot_archive
updating /platform/i86pc/boot_archive
bloody# gzip -dc /platform/i86pc/amd64/boot_archive > /tmp/l
bloody# ls -l /tmp/l
-rw-r--r--   1 root     root        175M Jun 27 00:49 /tmp/l
bloody# mount `lofiadm -a /tmp/l` /mnt
bloody# df -h /mnt
Filesystem             Size   Used  Available Capacity  Mounted on
/dev/lofi/1            163M  76.8M      70.2M    53%    /mnt
bloody# du -hs /mnt
75.8M   /mnt

and after:

bloody# /boot/solaris/bin/create_ramdisk.new --nocompress
updating /platform/i86pc/amd64/boot_archive
bloody# gzip -dc /platform/i86pc/amd64/boot_archive > /tmp/l
bloody# ls -l /tmp/l
-rw-r--r--   1 root     root       91.7M Jun 27 00:55 /tmp/l
bloody# mount `lofiadm -a /tmp/l` /mnt
bloody# df -h /mnt
Filesystem             Size   Used  Available Capacity  Mounted on
/dev/lofi/1           85.8M  76.8M      8.98M    90%    /mnt
bloody# du -hs /mnt
75.8M   /mnt
  • 0
  • 0
  • 3
  • 0
  • 3
Description From Last Updated
citrus
yuripv
  1. 
      
  2. usr/src/cmd/boot/bootadm/bootadm.c (Diff revision 1)
     
     

    Do we need this enum and all arguments of this type at all now? e.g. dircache_updatefile(path, FILE64) below -- the second argument is useless IMO.

    1. I chose to leave the multi-archive framework in place rather than strip it out. A framework that (currently) handles only one archive type is still valid but I'm interested in opinions here and am happy to go with the concensus.

    2. OK. My opinion is "rip it out, multi-arch is useless and unhelpful" :-)

  3. usr/src/cmd/boot/bootadm/bootadm.c (Diff revision 1)
     
     

    Guess we should print loud warning now so that everyone is aware thir 32bit modules aren't going to do anything anymore?

    1. I can change that to an unconditional WARNING. The debug print is not triggering on any of my test systems so we should not expect any 32-bit objects.

  4. usr/src/cmd/boot/bootadm/bootadm.c (Diff revision 1)
     
     

    We are no longer?

    1. Still paranoid in that we include the object in the archive "just in case".
      Again this is not triggering on any of my test systems.

  5. usr/src/cmd/boot/bootadm/bootadm.c (Diff revision 1)
     
     

    This for looks a bit useless now, doing exactly one iteration.

    1. See my reply to your first comment - the framework has been left in place.

  6. 
      
igork
  1. Ship It!
    1. Is there any chance you could test that this doesn't break illumos on SPARC?

    2. nope :)
      i have fixed it a long time ago on my DilOS tree - i have no 32bit Intel kernel and did update bootadm.c by myself in the same/similar ways. if changes will break SPARC - i'll let you know.

  2. 
      
kmays
  1. Ship It!
  2. 
      
citrus
yuripv
  1. Thank you.

  2. 
      
citrus
yuripv
  1. 
      
  2. usr/src/cmd/boot/bootadm/bootadm.c (Diff revision 3)
     
     

    Not ELF probably?

    1. Well, whatever it is, the first 4 bytes match the ELF magic number..

    2. Indeed.

  3. usr/src/cmd/boot/bootadm/bootadm.c (Diff revision 3)
     
     

    This could be:

    if (strstr(path, "/amd64") != NULL && has_cachedir())
    

    to reduce indentation.

  4. 
      
yuripv
  1. Looks good except for some nits and the red ugliness (doesn't updated cstyle whine about it?) -- don't HAVE to fix those, so in any case, ship it!

    1. That's just <space><tab> in a couple of places. I can fix those before RTI (just didn't want to make the diff larger than necessary)

    2. you can post it as separate update (rbt -u). If we could have decent RTI process, cstyle fix could be just separate commit...

  2. 
      
citrus
citrus
yuripv
  1. 
      
  2. usr/src/cmd/boot/scripts/create_ramdisk.ksh (Diff revisions 4 - 5)
     
     

    Should it be compress=no instead of removing the line?

    1. No. compress is set to yes at the top of the script and can be set to no during options parsing if the user provided --nocompress. This block should not change compress for x86.

  3. 
      
yuripv
  1. Ship It!
  2. 
      
citrus
Review request changed

Status: Closed (submitted)

Loading...