Benefits from computing physical IDE disk geometry?
Quoted 11 lines · Nick Piggin
Quoted 6 lines
Any good SCSI drive knows the physical geometry of the disk and can therefore optimally schedule reads and writes. Although necessary features, like read queueing, are also available in the current SATA spec, I'm not sure most drives will implement it, at least not very well.
The "continuous" nature of drive addressing means that the kernel can do a fine job seek-wise. Due to write caches and read track buffers, rotational scheduling (which could be done if we knew geometry) would provide too little gain for the complexity. I would say that for most workloads you wouldn't see any difference. (IMO)
OTOH you can come up with scenarios like, say, a DBMS doing 16K page
aligned IO to raw devices where you might see big gains from making sure those 16K chunks didn't cross a physical cylinder boundary.
--
Chuck
Quoted 3 lines · * Chuck Ebbert ([email protected]) wrote:
OTOH you can come up with scenarios like, say, a DBMS doing 16K page
aligned IO to raw devices where you might see big gains from making sure those 16K chunks didn't cross a physical cylinder boundary.
Maybe true; but figuring out where the drive really puts your sectors these days ain't that easy; what with remapping and multiple different densities on the platter.
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.
Dave
---------------- Have a happy GNU millennium! ----------------------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex / \ _________________________|_____ http://www.treblig.org |_______/
Quoted 5 lines · Dr. David Alan Gilbert
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.
Ah, you have reinvented SCSI (which can copy without involving the host...), or reinvented the Object Based Storage (see Lustre).
Sincerely,
Lars Marowsky-Brée <[email protected]>
Signature · 4 lines
SuSE Labs - Research & Development, SuSE Linux AG "If anything can go wrong, it will." "Chance favors the prepared (mind)." -- Capt. Edward A. Murphy -- Louis Pasteur
Quoted 3 lines · * Lars Marowsky-Bree ([email protected]) wrote:
Ah, you have reinvented SCSI (which can copy without involving the host...), or reinvented the Object Based Storage (see Lustre).
Gee and I just thought I was being mad.....
Dave
---------------- Have a happy GNU millennium! ----------------------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex / \ _________________________|_____ http://www.treblig.org |_______/
Quoted 5 lines · Dr. David Alan Gilbert
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. It also allows the disk to do fairly major relayout of data as it learns usage.
Quoted 11 lines · Alan Cox
Quoted 5 lines · Dr. David Alan Gilbert
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
Quoted 5 lines
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.
Quoted 2 lines
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/
Quoted 3 lines · Chuck Ebbert
OTOH you can come up with scenarios like, say, a DBMS doing 16K page
aligned IO to raw devices where you might see big gains from making sure those 16K chunks didn't cross a physical cylinder boundary.
You couldn't even tell where such boundaries exist, or what the real block size of the underlying media is. Cyliners are all different sizes.
Quoted 10 lines · Alan Cox
Quoted 4 lines · Chuck Ebbert
OTOH you can come up with scenarios like, say, a DBMS doing 16K page
aligned IO to raw devices where you might see big gains from making sure those 16K chunks didn't cross a physical cylinder boundary.You couldn't even tell where such boundaries exist, or what the real block size of the underlying media is. Cyliners are all different sizes.
Yes this is getting very difficult as Alan said. Its also something that we can't do in kernel - the block io scheduler can only choose from what it is given. I wouldn't be surprised if big databases did try using some sorts of disk mapping systems to help optimise their IO however.