[haiku-development] Re: Slow Alpha Installation
- From: Izomiac <haikulist@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 10 Sep 2009 22:01:50 -0400
Well, I just tried the latest ISO, and installation speed has improved
significantly. I was clocking it, but didn't get to record the time since
it took >4 minutes for the first thousand files, but when I returned in 20
minutes it'd finished all 16,837. So, in an attempt to be more precise, I
re-initialized the volume and installed again. It took 98 seconds.
Therefore, the DVD random read speed was by far the limiting factor. OTOH,
it only took 2:50 to burn the disk (< 2 minutes actually writing data), and
took 1:20 to go from BIOS to (functional) installer prompt. Ninety-eight
seconds is a far cry from what it'd be with an image based install (strange
that I didn't know Vista did that, I use vLite all the time), but I guess we
aren't trying to reach an instant install time. I wouldn't dismiss the
idea, but at this point it seems like a needless increase in complexity.
That said, I think my second suggestion stands to cut installation times by
quite a bit more than my first. To recap, that's: load the entire
filesystem into RAM, boot from RAM. Roughly estimating, that would entail:
~2:00 to load the CD into RAM, ~5 seconds to boot, ~1:30 to install VS 1:20
to boot from CD, >15 minutes to install.
Someone else mentioned OpenBFS and SSD support... For the ones that use
SATA there aren't any problems. There could be some SSD-specific
performance improvements, but there are no compatibility issues. I use a
Core V2 from OCZ, which is already EOL'd because it can get down to 4 IOs
per second with small random writes.
As for BFS resizing, I'm guessing initializing the volume on a 20+ GB
partition, then shrinking it to CD size would allow resizing back to <=
20GB. Making a backwards incompatible OpenBFS doesn't seem like a very good
idea though. Ext4 and likely others include every feature in the BFS, plus
a fair bit more, so it'd be mostly reinventing the wheel. (I realize that
Haiku does quite a bit of that for various reasons, but I'm unconvinced that
making a new filesystem would be worth it.)
On Wed, Sep 9, 2009 at 7:07 PM, Izomiac <haikulist@xxxxxxxxxxxxxxxx> wrote:
> I recently installed the Alpha on real hardware using a CD. It took a very
> long time (I didn't keep track but probably well over half an hour).
> Fortunately, the reason is fairly obvious: I'm using a first generation SSD
> with extremely slow random write speeds. For this specific case, it's a
> niche scenario that I honestly don't think any developer should waste their
> time with. I was well aware of the flaw when I bought the drive, but
> maintain that the benefits far outweigh the defect.
>
> That said, no drive is terribly fast at random writes; it's far slower than
> sequential writting. So, forgive me if the filesystem doesn't allow this,
> but during my wait a method for dramatically decreasing installation time
> occurred to me. First, do a sector-by-sector copy of the installation media
> to the front of the partition. Next, expand the BFS volume to fill the
> partition. Finally, do makebootable and whatever else that's needed to make
> it a valid and bootable partition.
>
> Of course, the old method should be available, since one might want to use
> an existing BFS volume or tweak the filesystem options. No GUI option is
> necessary, just use the old method for existing volumes and the proposed
> method for unformatted partitions.
>
> The speed benefit for an SSD like mine would be (maximum) 72 minutes down
> to (minimum) ~5 seconds. For a normal harddisk with 4KB random write speeds
> of 3 MB/sec and sequential write speeds of 60 MB/sec, the difference is ~3
> minutes VS 8 seconds. I'm working based off of worst (4KB random writes) VS
> best (sequential) case scenarios. Obviously my Haiku installation took less
> than half the maximum theoretical time, but I think the real world
> performance benefit on all drives would still be unignorable.
>
> The installation media would become the limiting factor, which is probably
> already the case for CDs to magnetic disks, but other types of installations
> would greatly benefit. Unless, of course, the CD filesystem is copied onto
> a ~500 MB ramdisk prior to booting (for systems with >=1GB of RAM)... It
> should even be faster overall since there's less CD seeking for random files
> during the boot/install process.
>
Other related posts:
