From: Eduard Bloch <blade@debian.org>
To: linux-kernel@vger.kernel.org
Subject: [HOWTO...] LUFS, readpage and large files
Date: Fri, 4 Jun 2004 17:51:03 +0200 [thread overview]
Message-ID: <20040604155103.GA15021@zombie.inka.de> (raw)
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.
next reply other threads:[~2004-06-04 15:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-04 15:51 Eduard Bloch [this message]
2004-06-05 4:50 ` Andrew Morton
2004-06-04 16:46 Miklos Szeredi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040604155103.GA15021@zombie.inka.de \
--to=blade@debian.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®