Boot poster challenge

[Daniel Veillard]

On Sun, Nov 21, 2004 at 04:55:47PM +0100, Arjan van de Ven wrote:
> 
> On Sun, Nov 21, 2004 at 10:42:45AM -0500, Alan Cox wrote:
> > On Sat, Nov 20, 2004 at 11:50:49PM +0100, Ziga Mahkovec wrote:
> > > This chart includes data from iostat (sysstat package).  Notice how the
> > > disk is fully utilized (%util) during readahead, but the throughput
> > > (rkB/s) is *really* low.  This could very well be a problem with my hard
> > > disk.  hdparm seems fine though (and I checked the parameters before
> > > running readahead).
> > 
> > Disks are very very seek constrained. You get wonderful performance reading
> > linear data. The moment you read a lot of scattered files or a file with a
> > lot of segments you will get low performance - even more so on laptops than
> > desktops
> 
> yeah we saw that; sorting the list on disk sector shaved 2 seconds off...
> if we want to save more we'll have to fix the on disk layout to be less
> spread out. That's not going to be fun...

  Let's see ... Suppose we isolate all the resources we need to load quickly,
we have a list of files, hopefully all from the same / partition, while in
single user mode and without concurrent activity:

for foo in $list:
  cp $foo $foo.new
for foo in $list:
  rm $foo
for foo in $list:
  mv $foo.new $foo

We could expect filesystems to allocate the new blocks (data and possibly
metadata) more or less sequentially on disk. What would led the filesystem
code to not be sequential (most of the time assuming a single block device
underneath) ?

 Just wondering...

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/