Thanks Mulyadi,
On Wed, 26 Jan 2011 01:19:52 +0700 Mulyadi Santosa wrote:
> Hi Miguel...
>
> Tough questions, let's see if I can made it :D
>
> On Tue, Jan 25, 2011 at 19:56, Miguel Telleria de Esteban
> <miguel@xxxxxxxxxxxxx> wrote:
> > MY INTERPRETATION (please correct me if I am wrong)
> >
> > Q1 ÂWhat is a "buffer page"?
> >
> > A "buffer page" is a "struct page" data describing a page allocated
> > to hold one or more i/o blocks from disk.
>
> I agree...in other word, they are pages that hold data when the I/O
> are still in flight. But since it's part of page cache, they aren't
> thrown away after the I/O is done...for few moment they are held in
> RAM, in case they're subsequently read...thus, I/O frequency toward
> physical discs are reduced
>
> I think, we know call it page cache....
>
> > Q2 ÂIs the whole page cache content organized as buffer pages?
> >
> > YES, there is no other way to link memory-mapped disk i/o data to
> > the struct page pointed by address_space radix-tree entries.
>
> Not so sure, but it's something like that IMHO.
>
> > ---
> >
> > Q3 Âblock device buffer_pages vs file buffer_pages
> >
> > This I really don't understand. ÂFrom what UTLK page 614 says:
> >
> > * ÂFile buffer_pages ONLY refer to non-contiguous (on disk layout)
> > file contents.
> >
> > * Âblockdev buffer_pages refer to single-block or continuous (on
> > disk layout) portions of block.
> >
> > My question is: Âwhat happens with non-fragmented medium size files
> > that do not contain "disk holes" or non-adjancent block submissions?
>
> Here's my understanding:
> 1. when you're dealing with file in raw, e.g using "dd" on /dev/sda1
> or "dd" with direct I/O command, you use block buffer cache
> 2. when you deal with files using read()/write facility of filesystem
> (thus via VFS), you use file page cache...
This makes sense. Looking through LXR at the do_generic_file_read()
function (actually do_generic_mapping_read() ), the address_space used
is the one of the file, not the dev.
Maybe dd goes also through this same path since you directly specify
the devfile to read from.
The other read path (bread() function) seems to be used when looking
for metadata (inode, superblocks) which are not requested by the
user-space read() call.
>
> to experiment with it, simply start "top" and examine which field
> increases when you do "dd", cat, etc....
Uhhmm I don't have this clear. I would like to check on which
adress_space object I am using (the block device or the file) so I
guess I need more deep tools (maybe ftrace??) to see it.
>
> I hope I help you instead confusing you :D
>
Thanks, you have helped. On my side I continue (re)reading :).
--
(O-O)
---oOO-(_)-OOo-----------------------------------------------------
Miguel TELLERIA DE ESTEBAN http://www.mtelleria.com
Email: miguel at mtelleria.com Tel GSM: +34 650 801098
Tel Fix: +34 942 280174
Miembro de http://www.linuca.org Membre du http://www.bxlug.be
ÂUsuario captivo o libre? http://www.obtengalinux.org/windows/
Free or captive user? http://www.getgnulinux.org/windows/
-------------------------------------------------------------------
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
