>
>
> On Mon, 1 Nov 1999, Jeff Garzik wrote:
>
> > (moved to linux-fsdevel)
> >
> > SGI's XFS white paper[1] describes
> >
> > > XFS delays allocation of user data blocks when possible to
> > > make blocks more contiguous; holding them in the buffer cache.
> > > This allows XFS to make extents large without requiring the user
> > > to specify extent size, and without requiring a filesystem
> > > reorganizer to fix the extent sizes after the fact. This also
> > > reduces the number of writes to disk and extents used for a file.
> >
> > Is this sort of manipulation possible with the existing buffer cache?
>
> AFAICS it is possible with the 2.3 page cache.
I agree with this, it feels closer to the linux page cache, the terminology in
the XFS white paper is a little confusing here.
XFS on Irix caches file data in buffers, but not in the regular buffer cache,
they are cached off the vnode and organized by logical file offset rather
than by disk block number, the memory in these buffers comes from the page
subsystem, the page tag being the vnode and file offset. These buffers do
not have to have a physical disk block associated with them, XFS allows you
to reserve blocks on the disk for a file without picking which blocks. At
some point when the data needs to be written (memory pressure, or sync
activity etc), the filesystem is asked to allocate physical blocks for the
data, these are associated with the buffers and they get written out.
Delaying the allocation allows us to collect together multiple small writes
into one big allocation request. It also means that we can bypass allocation
altogether if the file is truncated before it is flushed to disk.
Steve
------------------------------------------------------------------------------
Steve Lord voice: +1-651-683-5291
Silicon Graphics Inc
655F Lone Oak Drive email: [EMAIL PROTECTED]
Eagan, MN, 55121, USA
------------------------------------------------------------------------------
