Subject: Re: Main CPU- I/O CPU interaction
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Valdis.Kletnieks@vt.edu
Cc: tony osborne <tonyosborne_a@hotmail.com>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
In-Reply-To: <200501032227.j03MRocl008354@turing-police.cc.vt.edu>
References: <BAY14-F83B94FD7D13C5D19883F795900@phx.gbl>
	 <200501032227.j03MRocl008354@turing-police.cc.vt.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1104857088.17176.27.camel@localhost.localdomain>
Mime-Version: 1.0
Date: Tue, 04 Jan 2005 22:03:45 +0000
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 997
Lines: 25

On Llu, 2005-01-03 at 22:27, Valdis.Kletnieks@vt.edu wrote:
> What sort of I/O device processor is (a) supported by Linux *and* (b) filesystem
> aware?  Unless it meets both criteria, the main CPU(s) will still have to do
> all the work of block allocation, inode creation, and all the rest of that
> stuff.

NetApp 8)

The offloading file system stuff has been proposed and kicked around and
failed repeatedly in different circles. What has had some success is
offloading layout so that the I/O device thinks in terms of

	handle = allocate(blocks, near_this, and_this, ....)
	data = read(handle, offset, len)
	write(handle, offset, len, data)
	free(handle)

type API's, allowing the storage subsystem to do physical
mirror/relocation/HSM in private.

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