svn commit: r241053 - in head/sys/boot: common i386/libi386 uboot/lib userboot/userboot

[John Baldwin]

On Monday, October 01, 2012 11:22:39 am Andrey V. Elsukov wrote:
> On 01.10.2012 15:53, John Baldwin wrote:
> >>   Introduce new cache layer to resolve this problem. It is independent
> >>   and doesn't need initialization like bcache, and will work by default
> >>   for all loaders which use the new DISK API. A successful disk_open()
> >>   call to each new disk or partition produces new entry in the cache.
> >>   Even more, when disk was already open, now opening of any nested
> >>   partitions does not require reading top level partition table.
> >>   So, if without this cache, partition table metadata was read around
> >>   20-50 times during boot, now it reads only once. This affects the booting
> >>   from GPT and MBR from the UFS.
> > 
> > ...and removes support for removable media like floppies.  That may be the
> > proper thing to do at this stage (though I think that affects PC98 still
> > perhaps?)  However, removing suppot for removable media should be an
> > intentional decision, not a side effect.  The bcache was simplistic
> > precisely to support floppies.
> 
> Hi, John,
> 
> I think it shouldn't affect floppies support. I'm unable to test this,
> and I don't remember exactly, but floppies don't have partition tables,
> or just have simple MBR. So, when  access to the floppy will be
> performed first time, the following cache entry will be created
> "disk0: -> some_offset", probably an offset will be zero. And when you
> change the floppy this offset still remain the same. There is a lot of
> other places in the libstand, where similar behavior still remain (i
> mean, one operation initiates several unneeded reads):

The floppies used in BSD either have BSD labels or are a DOS floppy with no
partition table.

> * Each open() call initiates read file system metadata.
> 
> * We have the support of  different file systems. Some of those are real
> file systems, other aren't - gzip, bzip, split. During boot loader tries
> to open several files, which don't exists by default. Each this attempt
> initiates reading of metadata of each file system several times. Why?
> When we do first read we can determine that we have UFS on this media,
> why do we trying search msdos or ext2fs here?

Think about removable media.  If you have replaced the media (such as a
floppy), then what was once UFS may now be FAT16.

> Ok, when we fail to open this file on the all of file systems,  we are
> going to try them again with ".gz" extension...

Yes, the current code is not very optimal.  The focus on it to date has been
to make sure it works.  It is only used for bootstrapping, not once the main
system is up and running, so at least in the past performance has been less
important than correctness.

One could perhaps differentiate removable vs non-removable media (and allow
more caching on non-removable media) so long as one distinguish a USB stick
so as to mark it as removable media.

(Either that or we say that we no longer support swapping removable media
during the boot process.)

-- 
John Baldwin