lkml.org 
[lkml]   [1999]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectdelayed allocation of fs blocks. (was: pagecache-2.3.9-H3)

On Mon, 28 Jun 1999, Rogier Wolff wrote:

> > > oh, i see. (i was used to setting this in the fs, this is why i missed it)
> > > I think encoding holes in this way is bad, it will prevent legitimate uses
> > > of the very same bit-combination: (!Mapped && Uptodate) will be useful if
> > > we'll ever do 'delayed allocation' of filesystem blocks, it will represent
> > > pretty ordinary blocks which are not yet mapped to the filesystem.
> >
> > Give me one valid reason to ever do that, please..
>
> XFS?
>
> A high-performance FS might want to postpone allocating file blocks
> until it knows the filesize. Sure, it will have to start allocating
> anyway if the file grows above a certain size, but by that time you
> at least know it's not going to stay a small file.

i think any FS can do it - i've got plans for implementing this in the
near future, it's rather easy with the new pagecache. And we can do it
with minimum lowlevel-fs support. [basically the only thing to protect
against is over-allocation of filesystem resources - thus the lowlevel fs
has to export a free space estimator (doesnt have to be exact, it only
must prevent overallocation) - constructing such an estimator isnt too
hard for most local filesystems. In the quota case it can be a bit more
complex but i dont expect there to be big problems.] The point is that we
only have to allocate filesystem blocks when we write out dirty data. This
means quickly created and destroyed temporary ext2fs files will be
super-fast and involve no lowlevel-fs. (apart from creating/destroying an
inode and calling the [trivial] free-space estimator)

-- mingo


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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