Re: [RFC] fsblock

On Tue, Jun 26, 2007 at 08:34:49AM -0400, Chris Mason wrote:
On Tue, Jun 26, 2007 at 07:23:09PM +1000, David Chinner wrote:
On Tue, Jun 26, 2007 at 01:55:11PM +1000, Nick Piggin wrote:

[ ... fsblocks vs extent range mapping ]

iomaps can double as range locks simply because iomaps are
expressions of ranges within the file. Seeing as you can only
access a given range exclusively to modify it, inserting an empty
mapping into the tree as a range lock gives an effective method of
allowing safe parallel reads, writes and allocation into the file.

The fsblocks and the vm page cache interface cannot be used to
facilitate this because a radix tree is the wrong type of tree to
store this information in. A sparse, range based tree (e.g. btree)
is the right way to do this and it matches very well with
a range based API.

I'm really not against the extent based page cache idea, but I kind of
assumed it would be too big a change for this kind of generic setup. At
any rate, if we'd like to do it, it may be best to ditch the idea of
"attach mapping information to a page", and switch to "lookup mapping
information and range locking for a page".

Well the get_block equivalent API is extent based one now, and I'll
look at what is required in making map_fsblock a more generic call
that could be used for an extent-based scheme.

An extent based thing IMO really isn't appropriate as the main generic
layer here though. If it is really useful and popular, then it could
be turned into generic code and sit along side fsblock or underneath
fsblock...

It definitely isn't trivial to drive the IO directly from something
like that which doesn't correspond to filesystem block size. Splitting
parts of your extent tree when things go dirty or uptodate or partially
under IO, etc.. joining things back up again when they are mergable.
Not that it would be impossible, but it would be a lot more heavyweight
than fsblock.

I think using fsblock to drive the IO and keep the pagecache flags
uptodate and using a btree in the filesystem to manage extents of block
allocations wouldn't be a bad idea though. Do any filesystems actually
do this?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [RFC] fsblock
    ... Well it is the metadata used to manage the filesystem block for the ... I'm not fixed on fsblock, but blkmap doesn't grab me either. ... is a map from the pagecache to the block layer, ... Extent based block mapping is entirely independent of block size. ...
    (Linux-Kernel)
  • Re: Review of Mueckenheims book.
    ... mapping does or does not exist. ... It is not excluded "a priori" that a model of ZFC might not map '0' to ... Geometry is USED for physics. ... than your tree. ...
    (sci.math)
  • Re: Enumerating all expression trees (not Catalan)
    ... The mapping that would enumerate each tree with unique ... integer would be ideal for my purposes. ... Here is asymptotics: ...
    (sci.math)
  • Re: Two results of set geometry
    ... >>> There is a bijection between the set of all paths representing real ... The mapping you gave is from nodes to paths. ... traversal of the tree still differs by some finite amount from 2/3. ... at which the approximation to 2/3 is closer than epsilon. ...
    (sci.math)
  • Enumerating all expression trees (not Catalan)
    ... The mapping that would enumerate each tree with unique ... corresponds to the tree or expression like this ... time would be wasted wading through the list of mostly useless codes. ...
    (sci.math)