Received:  by oss.sgi.com id <S553998AbQKFPYS>;
	Mon, 6 Nov 2000 07:24:18 -0800
Received: from perninha.conectiva.com.br ([200.250.58.156]:10001 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553995AbQKFPYA>; Mon, 6 Nov 2000 07:24:00 -0800
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id NAA10900;
	Mon, 6 Nov 2000 13:19:46 -0200
Date:   Mon, 6 Nov 2000 11:25:02 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     Nathan Scott <nathans@wobbly.melbourne.sgi.com>
cc:     Kallol Biswas <kallol@sprynet.com>, linux-xfs@oss.sgi.com,
        Chaitanya Tumuluri <chait@sgi.com>
Subject: Re: xfs file system
In-Reply-To: <10011061043.ZM111283@wobbly.melbourne.sgi.com>
Message-ID: <Pine.LNX.4.21.0011061026120.27112-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


On Mon, 6 Nov 2000, Nathan Scott wrote:

<snip>

> Its quite out of date, unfortunately, but could still be
> used as a very rough guide to items which remain to be
> done.  The last three items for example, I'm pretty sure
> noone is currently looking at.  Some of the other items
> listed as unassigned, are actually being pursued by SGI
> or external folk already.  The list is also no longer
> comprehensive - Steve has another version of this doc
> which has a number of additional items which need to be
> done, including O_SYNC, making XFS work with more recent
> gcc versions, and several other things.

Hi, 

One of the things which must done is kiobuf-aware block device drivers, as
listed on the TODO list.

In current XFS CVS tree, nothing except SCSI layer is aware. 

When the majority of the significant block drivers are kiobuf-aware, we
can change significant places in the VM code which currently are
buffer-head based to be kiobuf based.

Looking at latest XFS block layer, function ll_rw_kio:

    /*
     * Only support SCSI disk for now.
     *
     * ENOSYS to indicate caller
     * should try ll_rw_block()
     * for non-SCSI (e.g. IDE) disks.
     */
        if (!SCSI_DISK_MAJOR(MAJOR(dev))) {
        *error = -ENOSYS;
        goto end_io;
    }


I dont see any reason why we can't split the kiobuf request into buffer
heads and send via ll_rw_block here (brw_kiovec() can do that), making
compatibility issues transparent to ll_rw_kio callers.

Comments?