Messages in this thread |  | | Date | Mon, 18 Sep 2000 12:23:43 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: The INN/mmap bug |
| |
On Mon, 18 Sep 2000, Chris Mason wrote:
> When reiserfs_get_block is called on the packed data (with create == 1), we > unpack it to a full block, so the generic functions can handle > dirties/writes from then on. If the data in the page cache isn't up to > date, we need to copy the packed data into the page cache so it doesn't get > lost in the conversion.
<boggle> why bother with bh in that case? You can do all this work on the ->writepage()/->readpage()/->prepare_write()/->commit_write() level.
> This isn't for writing directly to the tail, I'm only doing that in > writepage, where I always overwrite the tail data with page data.
Well, duh. Now I can see where the complaints about VFS being ext2-friendly at expense of other filesystems come from. Sure thing, if you bend your code so that it would use helper functions written for different layout model... It will hurt. The question being: what for? These functions do not belong to VFS API - they are convenient to implement the real thing (address_space_operations) for a class of filesystems, but that's it.
Look how 'no-holes' filesystems are doing that - yup, different layout, different helper functions. It would hurt like hell if we would try to do e.g. FAT on get_block() level. So that stuff was done on ...page() level, originally in fs/fat/inode.c. When it became obvious that there are other filesystems that might share the code - well, into fs/buffer.c it went. You are in the same situation.
Moreover, right now I'm testing yet another class (fragment support). Currently it's UFS only, but ext2 also might eventually win from that. Yup, also work on ..._page() level, doing that in ufs_get_frag() would be a horrible PITA.
I don't see why are you trying to squeeze everything into get_block() - it's not even a method anymore...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |