Boot poster challenge

David Corrigan lightingisfun at gmail.com
Tue Nov 23 06:22:26 UTC 2004


If each individual file is unfragmented then why not create a loop
back device with all the necessary files for booting, copy it into
memory, and mount it? As long as that one file remains unfragmented
then there will be a minimal amount of drive seeking involved.

David


On Sun, 21 Nov 2004 17:41:38 -0500, Daniel Veillard <veillard at redhat.com> wrote:
> On Sun, Nov 21, 2004 at 05:51:49PM +0100, Arjan van de Ven wrote:
> > On Sun, 2004-11-21 at 11:28 -0500, Daniel Veillard wrote:
> > > while in
> > > single user mode and without concurrent activity:
> > >
> > > for foo in $list:
> > >   cp $foo $foo.new
> [...]
> > > 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)
> >
> > nope this doesn't work; while each file individually will be sequential,
> > they are not sequential on disk. Note: teh files already aren't
> > fragmented, at least on my testsystem.
> 
>   yeah, but why does ext3 allocator doesn't allocate consecutive blocks
> for such a pattern ? Directory locality ? Still wondering :-)
> It must be possible one way or another to do this without going though
> very complex reservation interfaces. The problem is not to 100% garantee
> we will not seek at all while going though this bunch of files but
> to have only a reasonable amount of seeks. Suppose there is only 10 seeks
> instead of a single block that would amount only for 1 tenth of a second
> delay on "normal" hardware.
> 
> 
> 
> 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/
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>




More information about the fedora-devel-list mailing list