For the purposes of this project (new boot SPARC), we can avoid this problem by not placing editable files into the boot_archive. kobj_open() would be modified to read read any files it fails to find in the archive (if they exist at all) from the filesystem via the firmware. This has the up-side that it keeps all these files from invalidating the archive. The down-side is that it's one more place the kernel will continue to call into OBP. It's also a SPARC only solution. It should however fully address these concerns for the sake of this project on SPARC.
Beyond this project we can investigate more drastic approaches that eliminate this issue on all architectures. We could have the boot-loader (a modified and extended GRUB on x86 and the bootblock or more likely a standalone on SPARC) read all the files that would ordinarily make up the archive into memory at the time of boot, and then boot that data-structure (which basically contains everything the archive contains today). This not only avoids the out of sync issues, but also saves the work currently being done to commit the archive to the filesystem when it is updated. This approach has potential performance implications (many seeks as opposed to one big read) that need to be investigated, but could be addressed with a hybrid approach. The hybrid places only the static files into a maintained, on-disk archive loading all editable files dynamically. -jan > On Thu, 2007-08-02 at 15:58 -0700, Jan Setje-Eilers wrote: > > It sounds like it would be acceptable for whatever tool is used to > > update these files to do whatever sync is needed atomically as part of > > the update. Sadly for most of these files this tool is still a text > > editor and we don't get to fix that in a patch release. :( > > I don't think it's necessary to use this case to fix *this* problem -- > solaris administrators have had to deal with this all along, and you're > not going to make things worse if solaris continues to read these > manually-edited files individually at boot time. > > > However it seems like the files of concern fall into a category of > > their own that is currently being dealt with in a manner that should > > actually be reserved for out of sync kernel binaries. This suggest we > > have the following three types of files in the archive: > > > > 1) Kernel binaries (including modules and drivers) > ... > > 2) Files that are either caches or only grow or can be safely re-read > > later. > .... > > 3) Files that etc/system that contain information that can't always > > be usefully processed later during boot, but if out of date _do > > not_ leave the system in a dangerously unstable state. > > > Ideas, thoughts, comments? > > First, I don't believe we have proof that editable/volatile files > present in the boot archive fall only into categories (2) and (3), nor > sufficient controls to prevent files outside (2) & (3) from being added. > > I believe it's unreasonable to have files of type (3) in the boot > archive used when a solaris system boots from its own root file system. > > I believe that a change to force the administrator to run "bootadm > update-archive" after editing files of type (3) is a change not > compatible with the Patch binding requested for this case. While it is > true that this exact change was inflicted on solaris x86 in solaris 10 > update 1, there were mitigating business reasons why this appeared to be > the least bad option open to us at the time. These reasons do not > appear to be present for sparc. > > The main architectural benefit of newboot is that it reads in all files > needed to mount the root filesystem before the kernel is started. This > benefit would still be present if these files weren't packed into a > single boot archive on disk but were read individually from the root > filesystem. > > I believe most if not all of the operational problems with the boot > archive would go away if, in a default install of solaris booting from > its own root filesystem, a list of critical configuration files of type > (2) and (3) were read individually from the root filesystem into memory > to supplement the boot archive before the kernel starts. (I > specifically do not want a system where the kernel reads them in on > demand). > > With 20:20 hindsight, I can now say that the operational instability > inherent in putting volatile/editable files in the boot archive should > never have been inflicted on administrators of solaris on x86. I will > not stand by and see the instability inherent in the current monolithic > boot archive system inflicted on sparc systems as well. > > This must change or else I will derail so I can vote against this > proposal. > > - Bill > > > > > >
