lkml.org 
[lkml]   [2002]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: (fwd) Re: [RFC] mount flag "direct"
Date
On Thursday 05 September 2002 16:24, Peter T. Breuer wrote:
> Fine, but where is the log/phys translation done?

It's done here:

http://lxr.linux.no/source/mm/filemap.c#L438

> I presume that the
> actual inode contains sufficient info to do the translation,

The inode, plus an arbitrary amount of associated, on-disk metadata.

> because
> the inode has a physical location on disk, and it is also associated
> with a file, and what we do is generally start from the inode and trace
> down to where the inode says the logical block shoul dbe, and then look
> it up. During this time the inode location on disk must be locked
> (with a read lock). I can do that. If you let me have "tag
> requests" in the block layers and let me generate them in the VFS
> layers. Yes, I agree, I have to know where the inode is on disk
> in order to generate the block request, but the FS will know,
> and I just want it to tell VFS .. well, too much detail.

Actually, while much of this seems simple when thought of in abstract
terms, in practice it's quite involved. You'll need to allocate at
least a few months to code study just to know what the issues are, and
that is with the help of the various excellent resources that are
available.

I'd suggest starting here, and figuring out how the ->get_block
interface works:

http://lxr.linux.no/source/fs/buffer.c#L1692

--
Daniel
-
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/

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