[lkml]   [2000]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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 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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.036 / U:1.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site