Re: Benefits from computing physical IDE disk geometry?

[Andreas Dilger <adilger@clusterfs.com>]

On Apr 13, 2003  23:14 +0100, Alan Cox wrote:
> On Sul, 2003-04-13 at 19:24, Dr. David Alan Gilbert wrote:
> > Now given these discs have processors on board isn't it about time
> > someone improved the disc interface standards to push some of the
> > intelligence drivewards?  I guess with enough intelligence the drive
> > could do free block allocation and could do things like copying blocks
> > around for you.
> 
> I wish it would. Most of the research and stuff so far has either put
> the file system into the disk firmware (upgrade hell). Having a disk
> which talked entirely about
> 
> 	read(handle,offset, length)
> 	write(handle, offset, length)
> 	alloc(handle, near_handle, length, otherhints...)
> 
> might well work out rather better.

This is essentially what the Lustre Object Storage Target (OST) protocol
looks like.  The client talks to the OST with "object IDs" and does simple
create/destroy/getattr/setattr operations on the objid.

The data I/O protocol (bulk read/write) can do scatter/gather vector I/O
on one or more objects at a time using objid/offset/range triplets, and
the internal data representation is totally opaque to the client (i.e. no
block numbers are passed around in the API).

One thing that is totally missing from the Linux client-side is the ability
to use a "copy" syscall to copy objects directly between OSTs instead of
having to go through the client.

> It also allows the disk to do fairly major relayout of data as it learns
> usage.

Yes, among other things.  We can do stacking of drivers (e.g. RAID, snapshot,
migration, read caching, etc) without having to change the protocol.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/