Re: [prepatch] address_space-based writeback

Alexander Viro (viro@math.psu.edu)
Wed, 10 Apr 2002 07:34:30 -0400 (EDT)


On Wed, 10 Apr 2002, Andrew Morton wrote:

>
> This is a largish patch which makes some fairly deep changes. It's
> currently at the "wow, it worked" stage. Most of it is fairly
> mature code, but some conceptual changes were recently made.
> Hopefully it'll be in respectable state in a few days, but I'd
> like people to take a look.
>
> The idea is: all writeback is against address_spaces. All dirty data
> has the dirty bit set against its page. So all dirty data is
> accessible by
>
> superblock list
> -> superblock dirty inode list
> -> inode mapping's dirty page list.
> -> page_buffers(page) (maybe)

Wait. You are assuming that all address_spaces happen to be ->i_mapping of
some inode. Which is less than obvious - e.g. putting indirect blocks into
private per-inode address_space is not unreasonable.

What's more, I wonder how well does your scheme work with ->i_mapping
to a different inode's ->i_data (CODA et.al., file access to block devices).

BTW, CODA-like beasts can have several local filesystems for cache - i.e.
->i_mapping for dirty inodes from the same superblock can ultimately go
to different queues. Again, the same goes for stuff like
dd if=foo of=/dev/floppy - you get dirty inode of /dev/floppy with ->i_mapping
pointing to bdev filesystem and queue we end up with having nothing in common
with that of root fs' device.

I'd really like to see where are you going with all that stuff - if you
expect some correspondence between superblocks and devices, you've are
walking straight into major PITA.

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