> Hi All,
> I recently read that all fs codes actually do I/O to and from the
> pagecache and then the dirty pages are synced to the disk later using
> the bdflush daemon.This approach has some performance problems when I/O
> is done thru write calls rather than mmap. I was just curious whether
> this path was modified when XFS was written ( ie how cud such a approach
> even work in case of jounalled file system when log operations are
> needed bfore the data gets written out).
> I am kinda newbie into kernel hacking and so i am sorry if my question
> sounds dumb.
Hi Arun, well filesystem I/O is divided into two chunks - file data
which is definitely page cache based, and metadata which is done through
various means depending on:
o which kernel you are running
o which filesystem
All filesystems that I am aware of except for XFS use buffer heads and the
block cache for metadata I/O. bdflush is responsible for flushing the data
unless the filesystem makes explicit requests. XFS does its own thing
using pagebufs because we came from a totally different buffer cache
architecture, and because we got a little ambitous with our implementation.
XFS needs to lock variable sized objects, everyone else uses fixed sizes
for the most part. XFS also wants some other behaviors from its buffer
cache. This is where pagebuf came from.
Having said that, recent linux kernels have the buffer cache layered on top
of an address space in a similar manner to how pagebuf does it. I am working
on making the two address spaces the same one because 2.4.13 seems to have
changed things sufficiently to break some tests on xfs - our user space
utilities and the kernel are not agreeing on the state of the filesystem.
Steve
> Cheers,
> Arun.
>
> --
> Arun Ramakrishnan
> Graduate Research Assistant / Sys Admin
> Linux Cluster I/O Lab
> The Ohio State University
>
> Ph : (614)-294-5523 (H)
> (614)-292-4634 (O)
>
|