That's largely because they do more than traditional file systems. Some of the ZFS functionality Linux would put in other layers, for instance. Once the IO is issued to the block layer, there's no difference.
It depends on what you need to schedule. If your drive does queuing and only one process IO is active, then the OS can do very little to help. The OS usually has a larger depth of ios to work with, so it's still often beneficial to do some sorting at that level as well.
IO scheduling is a lot more than that, however. If you have several active processes issuing IO, the IO scheduler can make a large difference to throughput. I actually just did a talk at LCA 2007 with some results on this, you can download the slides here:
That is correct, like a "y", rhymes with "mens". I saw another question on the lastname, I typically tell foreigners that it is pronounced ax-bow. Europeans often think the 'oe' is like the Danish "ø", however that is not the case.
sendfile is not yet a call to splice, it will be a little later. It was deemed too risky for 2.6.17. The point of doing it, btw, is not to increase sendfile() performance which is already as good as it can be - it's a specialized case and not very powerful, hard to make faster. So you wont get a performance increase from that. The perfomance increase will have to come with a program designed around splice.
You are correct in assuming you don't need ide-scsi to emulate a SCSI host for burning cdroms in 2.6, but it has nothing at all to do with the IDE rewrite.
2.6 has support for queueing "generic scsi" commands through the block layer, using the same mechanism and transport as the regular read/write file system requests. So we can overload the sg (scsi generic) SG_IO and provide the same functionality for non-scsi attached devices (such as atapi burners). With a recent cdrecord, you can give the device with -dev=/dev/hdc for instance.
Additionally, cd burning is now zero copy. The user space data buffer is mapped directly into the kernel for the dma operations. DMA is supported on a 4-byte boundary, where 2.4 and previous has required sector alignment (512 bytes) for any atapi dma operations.
What a load of crap. All the general file systems in Linux are endian-safe, and can thus be moved between little and big endian machines without any problems. Anything else would be just plain stupid.
The I/O problems are fixed in 2.4.0-test2, which is what the announcement is about. VM is still shaky (which has an impact on I/O, naturally), but that is not related to block I/O.
2.4.0-test2 contains a largely reworked I/O scheduling layer and several elevators to pick and choose from.
I can't even remember when I sent the DVD stuff to Linus - sometime prior to 2.3.15 (the oldest patch I have on my discs). So don't worry, 2.4 will support the CSS ioctls.
Oh please, DVD for Linux is progressing nicely and (provided you have a fast enough computer) you can view any movie you want to. So get you facts straight.
I think you are fooling yourself if you think that Alan has to report that much to Red Hat. It's not that uncommon for vendors to pay individuals to do their stuff and get paid at the same time. I should know - I'm involved in the same kind of deal (no, not Red Hat!).
Another comment - I know that reiserfs is being submitted for 2.3, but nobody knows whether Linus decides that it goes in at this time. It would be very nice to have for 2.4, though.
And 2.3 is not as simple as you think - although it is "just" ext2 with a journal, you have to consider stuff write ordering, for instance.
I talked to Stephen at the Expo in London and is not his intention to push this into 2.3. So unless he (and Linus) changes his mind, it won't be going into 2.3.
The usual DVD drives conform to the Mtfuji or MMC spec, which is basically just a beefed up ATAPI. It will understand exactly the same packets as those defined in ATAPI 2.6 and then some. There are other differences as well, but these all relate to DVD _specific_ features, such as reading of DVD structures, CSS authentication, etc. So saying the Linux sees it as just any other CD-ROM drive is correct - indeed it should.
The only problem you'd see by inserting a DVD movie (for instance) and copying files from it, is if the disk is encrypted. You'd then get an error in your logs stating that a "read of scrambled sector without authentication". For your run-off-the-mill porn, you could probably get by without any problems:)
After having read the many comments here, it's apparent that there is some confusion with regards to what patch you need for what kernel and what type of drives it works on. Let me attempt to clarify that a bit.
The original DVD patch was done by Andrew T. Veliath and this is the patch linked on the HOWTO page. While it only worked on ATAPI drives, his interface and structure was good and I decided to integrate this in the standard Linux kernel but in a bus independent way. Current 2.3 kernels contain this code and it works equally well on ATAPI as well as SCSI drives (which is an important point, IMO).
In summary, if you are running a recent 2.3 kernel you are all set and there is no need to patch your kernel. If you are on a 2.2 kernel, get the patch from my page to get support for both ATAPI and SCSI drives.
Slashdot Mirror
That's largely because they do more than traditional file systems. Some of the ZFS functionality Linux would put in other layers, for instance. Once the IO is issued to the block layer, there's no difference.
It depends on what you need to schedule. If your drive does queuing and only one process IO is active, then the OS can do very little to help. The OS usually has a larger depth of ios to work with, so it's still often beneficial to do some sorting at that level as well.
IO scheduling is a lot more than that, however. If you have several active processes issuing IO, the IO scheduler can make a large difference to throughput. I actually just did a talk at LCA 2007 with some results on this, you can download the slides here:
LCA2007 CFQ talk
Hi John!
That is correct, like a "y", rhymes with "mens". I saw another question on the lastname, I typically tell foreigners that it is pronounced ax-bow. Europeans often think the 'oe' is like the Danish "ø", however that is not the case.
sendfile is not yet a call to splice, it will be a little later. It was deemed too risky for 2.6.17. The point of doing it, btw, is not to increase sendfile() performance which is already as good as it can be - it's a specialized case and not very powerful, hard to make faster. So you wont get a performance increase from that. The perfomance increase will have to come with a program designed around splice.
Do note that patches that have come from some other person but ends up in Linus tree via the -mm tree get attributed to Andrew.
:)
Andrew does kick ass, but don't fool yourself into thinking he hacked all of that by himself
You are correct in assuming you don't need ide-scsi to emulate a SCSI host for burning cdroms in 2.6, but it has nothing at all to do with the IDE rewrite.
2.6 has support for queueing "generic scsi" commands through the block layer, using the same mechanism and transport as the regular read/write file system requests. So we can overload the sg (scsi generic) SG_IO and provide the same functionality for non-scsi attached devices (such as atapi burners). With a recent cdrecord, you can give the device with -dev=/dev/hdc for instance.
Additionally, cd burning is now zero copy. The user space data buffer is mapped directly into the kernel for the dma operations. DMA is supported on a 4-byte boundary, where 2.4 and previous has required sector alignment (512 bytes) for any atapi dma operations.
What a load of crap. All the general file systems in Linux are endian-safe, and can thus be moved between little and big endian machines without any problems. Anything else would be just plain stupid.
IDE supports that too, at least some drives: IBM deskstars and WD Expert series. Linux 2.5 and FreeBSD supports queueing on these drives.
The I/O problems are fixed in 2.4.0-test2, which is what the announcement is about. VM is still shaky (which has an impact on I/O, naturally), but that is not related to block I/O.
2.4.0-test2 contains a largely reworked I/O scheduling layer and several elevators to pick and choose from.
Real Soon Now (tm). I expect an alpha release within the next week, but this is not 2.3/4 material.
I can't even remember when I sent the DVD stuff to Linus - sometime prior to 2.3.15 (the oldest patch I have on my discs). So don't worry, 2.4 will support the CSS ioctls.
Oh please, DVD for Linux is progressing nicely and (provided you have a fast enough computer) you can view any movie you want to. So get you facts straight.
I think you are fooling yourself if you think that Alan has to report that much to Red Hat. It's not that uncommon for vendors to pay individuals to do their stuff and get paid at the same time. I should know - I'm involved in the same kind of deal (no, not Red Hat!).
Another comment - I know that reiserfs is being submitted for 2.3, but nobody knows whether Linus decides that it goes in at this time. It would be very nice to have for 2.4, though.
And 2.3 is not as simple as you think - although it is "just" ext2 with a journal, you have to consider stuff write ordering, for instance.
I talked to Stephen at the Expo in London and
is not his intention to push this into 2.3. So
unless he (and Linus) changes his mind, it won't
be going into 2.3.
Sure, there's no problem booting off a DVD
ATAPI/SCSI drive - if your BIOS supports booting
off an ordinary CD-ROM drive, it will handle
DVD too.
The only problem you'd see by inserting a DVD movie (for instance) and copying files from it, is if the disk is encrypted. You'd then get an error in your logs stating that a "read of scrambled sector without authentication". For your run-off-the-mill porn, you could probably get by without any problems :)
Andre Hedrick included a somewhat mangled patch
in his IDE patch set. Get a patch for 2.2.13
at my page: http://www.kernel.dk
The original DVD patch was done by Andrew T. Veliath and this is the patch linked on the HOWTO page. While it only worked on ATAPI drives, his interface and structure was good and I decided to integrate this in the standard Linux kernel but in a bus independent way. Current 2.3 kernels contain this code and it works equally well on ATAPI as well as SCSI drives (which is an important point, IMO).
In summary, if you are running a recent 2.3 kernel you are all set and there is no need to patch your kernel. If you are on a 2.2 kernel, get the patch from my page to get support for both ATAPI and SCSI drives.
http://www.kernel.dk