[HOWTO...] LUFS, readpage and large files

[Eduard Bloch]

Hello,

while writting a new LUFS plugin (to emulate large file support on
FAT32;) I stumbled over a problem with it's kernel communication module.
The symptoms were the same as with broken programs that use int or long
int instead of size_t (or even long long) for storing file offsets.
However, here the broken offsets (modulo 4GB) came from kernel so I
traced it down to this method:

static int lu_file_readpage(struct file *f, struct page *p)
{
    int res;
    struct iovec siov[3], riov;
    long long offset;
    unsigned long count;
    struct server_slot *slot;

    TRACE("in\n");

    if((slot = lu_getslot(GET_INFO(f->f_dentry->d_sb))) == NULL)
    	return -ERESTARTSYS;

    get_page(p);

    if((res = lu_getname(f->f_dentry, slot->s_buf, LU_MAXDATA)) < 0){
      WARN("lu_getname failed!\n");
      goto out;
    }

    offset = p->index << PAGE_CACHE_SHIFT;
    count = PAGE_SIZE;

The problem is, page->index indeed contains a short datatype for offset -
...but where to get the correct data? (the long long offset).

I tried to look at how other filesystems manage it but they become too
complex when it comes to details. Unfortunately, most documentation
about VFS and filesystems (found on Internet) simply sucks when it comes
to such details, especially for Large Files.
The autors simply refer to "block lockup methods" or similar things but
nobody gives an example explanation or correct description of how the
way of the data should like (complete - all steps between the request,
page allocation, translation of addresses etc.pp.).

Regards,
Eduard.
-- 
Eine Freude vertreibt hundert Sorgen.
-
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/