[lkml]   [2002]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] delayed disk block allocation
On Thu, Mar 07, 2002 at 08:47:24AM -0600, Steve Lord wrote:
> On Thu, 2002-03-07 at 06:06, Etienne Lorrain wrote:
> > > With "allocate on flush", (aka delayed allocation), file data is
> > > assigned a disk mapping when the data is being written out, rather than
> > > at write(2) time. This has the following advantages:
> >
> > I do agree that this is a better solution than current one,
> > but (even if I did not had time to test the patch), I have
> > a question: How about bootloaders?
> >
> > IHMO all current bootloaders need to write to disk a "chain" of sector
> > to load for their own initialisation, i.e. loading the remainning
> > part of code stored on a file in one filesystem from the 512 bytes
> > bootcode. This "chain" of sector can only be known once the file
> > has been allocated to disk - and it has to be written on the same file,
> > at its allocated space.
> >
> > So can you upgrade LILO or GRUB with your patch installed?
> > It is not a so big problem (the solution being to install the
> > bootloader on an unmounted filesystem with tools like e2fsprogs),
> > but it seems incompatible with the current executables.
> The interface used by lilo to read the kernel location needs to flush
> data out to disk before returning results. It's not too hard to do.

Also, GRUB shouldn't have this problem since it reads the filesystems
directly on boot.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:24    [W:0.036 / U:13.696 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site