Messages in this thread | | | Date | Mon, 28 Jun 1999 09:21:25 +0200 (CEST) | From | Ingo Molnar <> | Subject | delayed 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/
| |