> > > 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/