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@xxxxxxxxxx> 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@xxxxxxxxxx | 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@xxxxxxxxxx > http://www.redhat.com/mailman/listinfo/fedora-devel-list >
