Domain: t10.org
Stories and comments across the archive that link to t10.org.
Comments · 16
-
Re:Most albums have index marks, unlike Amarok
-1 Modded wrong. With your 6 digit UID you must have registered when you were 6.
CD's are a continuous stream with the option of having track pauses. This information is stored in the TOC -
End-to-End Protection
http://www.t10.org/ftp/t10/document.03/03-224r0.pdf Storage systems have standards in place where every data path is protected by CRC to ensure data integrity. Short of keeping cost low, there should be no reason not to implement something similar to automotive applications.
-
Hardware solution
Inspired by this thread, I have been thinking about some AoE designs.
My current single channel IDE design consists of
DM9000B + ATmega 8515 + GAL16V8
As the harddisk and the ethernet chip can be made to basically talk directly to each other (with the GAL doing the MDMA handshake), it should be possible to nearly saturate 100Base-T. The ethernet chip can do jumbo frames as well.
To now expand this to several channels, one just has to follow the recommentations about "dual port cabling" from the ATA standard. You can find it as well in Annex C.2.8 of the ATA 4 draft. Given enough drivers and multiplexers, a lot of channels should be possible. One has to weigh the cost of these drivers/multiplexers against the cost and additional bandwidth of more units.
Old small CPLDs might be an alternative to GAL+multiplexer+driver. -
Re:Vastly?(there is a distinct lack of SAS flash drives BTW). "Flash drives" could mean anything, but USB flash drives use the SCSI command protocol. SAS is very nice, but SCSI's contribution to that is rather slim SAS *is* SCSI, defined by the same international standards body. SCSI Parallel bus is a SCSI transport. SAS is a SCSI transport. Fibre Channel is often a SCSI transport. IP can be a SCSI transport. USB can be a SCSI transport.
SCSI is everything the INCITS T10 working group defines. You seem to be confusing the transport with SCSI as a whole. -
Re:SCSI??
scsi absolutely is not serial, duh
While he did screw up the second 'S' in SCSI, you cannnot seriously expect anyone who knows anything about the evolution of SCSI to take you seriously after you stated the above.
I will prove your statement false with a single counterexample: Serial Attached SCSI (PDF). Note the date of the document.
Remeber that with SCSI-3, the standard became more modularized in order to do things like separate the SCSI command set and the SCSI physical interface.
Here's the SAS FAQ from the SCSI trade association. -
Re:SCSI??
You people are really showing your (inadvanced) age!
And you are showing your senility:
Don't forget what SCSI stands for - Small Computer (Serial|Standard) Interface.
Heh. Wrong.
Small Computer System Interface. -
Re:No SCSI emulation in Linux
Well, but it looks like MMC *is part* of the SCSI architecture...
-
Re:More Information
Karma whore. But I'll also add T10, the SCSI and Serial-SCSI guys and T13, the ATA and S-ATA guys Draft standards and other documents galore!
-
Re:Hey, they're innovating again
A subset of the SCSI-3 standard, also known as IEEE 1394, Firewire is a new high speed data exchange protocol developed at Apple. Occasionally it is referred to as "serial SCSI" because it is a serial protocol and conforms to SCSI standards as well.
They stated that in a fashion that is, at best, a bit confusing. This draft specification for the SCSI architectural model shows on page 10 a diagram showing that there are several interconnect layers for SCSI, including the classic parallel SCSI bus (SPI), and three count 'em three serial layers, namely Fibre Channel (FC-PH), FireWire ("IEEE 1394 High Performance Serial Bus"), and IBM SSA (SSA-PH), with each interconnect layer having a protocol used to implement SCSI on that layer.
Then there are the SCSI commands, which are mostly if not entirely independent of the interconnect layer and protocol. They can be sent over parallel SCSI, Fibre Channel+FCP, FireWire+SBP, SSA-PH+SSP, {pick your link layer}+IP+TCP+iSCSI, Ethernet+HyperSCSI, or the Serial ATA link layer+serial attached SCSI, and, apparently USB+some way of sending SCSI commands over USB. (There certainly don't seem to be many bit-serial links over which you can send SCSI commands and replies....
:-))FireWire isn't "SCSI", it's an interconnect over which you can send SCSI commands and replies. It's also an interconnect over which you can send stuff that has nothing to do with SCSI, e.g. IP datagrams (we ignore here the possiblity of IP datagrams containing TCP segments that make up iSCSI PDUs
:-)), just as Fibre Channel is an interconnect over which you can send SCSI commands and replies, as well as stuff that has nothing to do with SCSI, e.g. IP datagrams, and just as USB is an interconnect over which you can send SCSI commands and replies, as well as stuff that has nothing to do with SCSI, including network packets. -
Serial ATA & Serial SCSI
While not a solution today, the Serial Attached SCSI (SAS) specification allows for adding Serial ATA devices to a SAS system. They both use the same physical layer, so support will only depend on whether companies support STP (Serial ATA Transport Protocol). Both the HBA and expander (a.k.a. switch) need to support STP for this to work.
I expect we'll see many companies offering scary things like enterprise-class RAID boxes with your option of SAS or SATA drives. As other posters have already observed, ATA isn't reliable enough for this kind of thing and the added maintenance doesn't offset the cost difference for your average RAID installment. -
Serial communications & SCSI
I just wanted to address two types of comments I've seen posted here:
* Encoding / decoding speeds are done at the speed of the medium. Encoding and decoding optical signals doesn't have any more overhead than PCI or IDE. The spec. writers and endec designers are well aware of these issues. That's why technologies like 10Gb Fibre Channel or Eithernet aren't ready yet -- not because we can't transmit at that speed, but that we can't build an entire NIC to sustain those speeds. (Give us some time: we'll be there soon enough.)
* Serial interfaces like Fibre Channel and Infiniband (and even Gigabit Eithernet) aren't replacing SCSI. They are replacing what you think of as SCSI: the 50 or 68-pin cable in your case. But SCSI is the protocol being used to talk to all those FC & Gig-E storage devices. SCSI over FC is called FCP (see T11's specs for more on FC). For Gig-E, most companies are looking into iSCSI, iFCP or FCIP (SCSI over IP or SCSI over FC over IP) for SAN-to-SAN communications. I forget the name of the spec for SCSI over Infiniband, but it pretty much rips it's ideas from the above specs. (sorry, no links for Gig-E and Infiniband at the moment: start at T10 or The SCSI Trade Association)
BTW, I refer to "serial interfaces" above instead of "optical interfaces" because a lot of this is actually copper. Most likely, Infiniband on the motherboard will be copper and off the motherboard it will be optical. Most of the Fibre Channel equipment I have isn't "fibre" but copper. -
Protocol for DVD-R drives
Since you worked on one of these drives, do you happen to know where one might find documentation on the SCSI commands used to control them? There is a proprietary version of cdrecord that is supposed to be able to control DVD-R drives, so this implies that there are some additional commands necessary beyond what is normally used to drive a CD-R drive. My hope is that this is documented somewhere on t10.org.
-
Two other ~$600 DVD recorders, Linux support
If you want a ~$600 DVD recorder, you already have a couple of other choices.
At $629 on PriceWatch, the Pioneer DVR-A03 that a number of posters have already mentioned writes DVD-R at 2X, DVD-RW at 1X, as well as CD-R and CD-RW.
At $535 on PriceWatch, the Panasonic LF-D311 writes DVD-R at 1X and DVD-RAM (1X for 2.6GB, 2X for 4.7GB), as well as reading the usual CD formats, but apparently not writing any CD format whatsoever.
Currently, to the best of my knowledge, the only Linux software that can drive DVD writes is proprietary (sorry, there really is no good link for it). I am not sure whether complete information on how to drive these DVD writes is given in the SCSI-3 standards on www.t10.org or whether some additional information is needed. Any pointers to this information would be appreciated, as I might get ambitious one of these days and try to hack cdrecord or cdwrite to control these drives if nobody beats me to it.
-
Two other ~$600 DVD recorders, Linux support
If you want a ~$600 DVD recorder, you already have a couple of other choices.
At $629 on PriceWatch, the Pioneer DVR-A03 that a number of posters have already mentioned writes DVD-R at 2X, DVD-RW at 1X, as well as CD-R and CD-RW.
At $535 on PriceWatch, the Panasonic LF-D311 writes DVD-R at 1X and DVD-RAM (1X for 2.6GB, 2X for 4.7GB), as well as reading the usual CD formats, but apparently not writing any CD format whatsoever.
Currently, to the best of my knowledge, the only Linux software that can drive DVD writes is proprietary (sorry, there really is no good link for it). I am not sure whether complete information on how to drive these DVD writes is given in the SCSI-3 standards on www.t10.org or whether some additional information is needed. Any pointers to this information would be appreciated, as I might get ambitious one of these days and try to hack cdrecord or cdwrite to control these drives if nobody beats me to it.
-
Post-Edit replyI edited the reply a bit to make it more, well, sensible. I hope the content is retained, yet a bit more accesible.
How voluntary is voluntary?
by squiggleslashIs making the CPRM spec a feature that can be turned off truly making it voluntary, given that presumably some content will not be supplied to users who fail to leave CPRM enabled? Would it not end up being as "optional" as DVD CSS encyption and non-zero region encoding?
Andre:
SHALL != MAY
:: REQUIRED == OPTIONALBecause no one in the industry wants to be caught out of sync, "optional" tends to be the same as "required." CPRM, however, may be the first "optional" feature that would remain truly "optional."
Choices...
by cnladdI apologize for the open-endedness of this question, but I have to ask it anyways.
:)If this copy protection were to become mandatory, I can definately imagine the effects that it would cause. But what effects - both long and short term - do you feel this would cause?
Andre:
The software you keep as "backup" would become worthless.
How to defeat it?
by sulliIf this is forced through the industry, how would one write a DeCSS-like tool to defeat it? Is it in some way bypassable in software?
Andre:
Unlike DeCSS that has media with seed keys that can not be updated, ATA devices (not ATAPI) can be updated as old keys are hacked.
After creating my proposal, it was deemed too complex to use,but I reefused to withdraw it unless we were to use the simple rules of Word0 Bits 6/7 to define FIXED/REMOVABLE as the boundary. Thus ATA-Devices supporting Word0 Bit6 set to ONE are not going to be allowed to have CPRM support.
This may in the end mean we have finally won the removal of CPRM from hard drives. This is good. However, it looks like removable ATA is still going to be bound to CPRM rules. This includes Compact FLASH, IBM MicroDrives, Sony Mem-Stick.... Things that are defined as "media" and not fixed.
Better solution?
by RareHeintzThe hard-drive copy protection scheme seems to me to be yet another attempt (in the vein of DVD/CSS, DPMI, etc.) to maintain a legal structure (that of multinational corporations with scarcity-based proprietary information models) with a technical fix. On
/., it may be taken as an article of faith that such efforts are doomed - smart people solve legal problems with lawyers, and technical problems with technology, and know the difference.My question, though, stems from the fact that (like it or not) software companies are within their rights to get paid for software they write, and to set up their own price structure, and to prosecute those who steal their software.
So the question is: If this misguided idea of hardware-based copy protection gets successfully scuttled (and I hope it does), what better solution might there be for proprietary-model software companies that has the benefit of providing them superior protection from pirates without screwing the rest of the world out of the benefits of the currently open hardware model, such as "fair use" under copyright law?
My US$.02: Coming up with such a "third way" solution could go a long way toward killing media-based copy protection - give them an out, and they might take it.
Andre:
Media serial number command proposal (e00163r0) by Microsoft is surprisingly good. It also uses stuff that is already in the market.
This new command could be used a seed for encrypting content, but this command is only reporting sections of the IDENTIFY page command, so it will be easy to circumvent.
It is particularly useful for Linux. Imagine that you want automatic hotswap to de/re-register the device.This command is passive, so it will not hang the system.
How does 4C justify their position?
by ploverWhat is 4C's reponse to "why don't you push for enforcement of the current copyright laws instead of an unpopular techno "fix" that will be thwarted upon release?" How do they justify their position?
Andre:
Most likely the law passed 2 years ago that provides and supports copyright encryption. Ask John Gilmore of the EFF. I think they are doing that with this model.
(Politics) If people will get off their butts and follow what their government is dumping on the country, you would be able to prevent this from ever coming to life.
Re:How does 4C justify their position?
by SnowfoxHow does the 4C justify their position to the consumer? How is this in the consumer's best interest?
Andre:
[reply omitted as -1, offtopic]
I'm still confused
by HuskyDogI gain the impression that compliant (presumably closed source) software encrypts data as it flows on and off the drive using keys which are specific to each drive. So, if the file is moved to a different drive it won't decrypt any longer? Have I got the right idea? If so, its only applicable to those prepared to run closed source software, right?
Andre:
Exactly right.
Enforcement on Open Source platforms
by TWX_How can copy protection of data be maintained on hard disks and other media if the operating system has the ability to use partition types that encrypt? Wouldn't a layer in an OS kernel be able to circumvent a good portion of the measures if the data does not reach the drive in its original form?
Andre:
No, now the work is done in user-space and the file is written with standard commands. Originally the drive would have done the work.
Is this already approved for SCSI and Firewire?
by VValdoLast week we read that a copy-control scheme similar or identical to CPRM has been already approved for SCSI and Firewire (without objection...probably because no one knew about it.)
First off, is it true? Secondly, why hadn't we heard about this before? Can we expect this technology to be built into all new SCSI and Firwire hardware, or is "optional" there too?
Andre:
It is my impression that the game is over there, but if you're concerned, consider joining T10.
What can we do to help you?
by rhoThis proposal is a tragedy to personal liberties and freedoms (and rates pretty high on the Suck-o-Meter), and your efforts thus far are admirable.
So, I want to know, what can we do to help? Letter writing, calls, faxes? Stand around and go "Brrbbrrbb" with our lips?
How can we aid your efforts in the most effective way?
Andre:
Send email to cprm@linux-ide.org. I won't reply, but I will forward comments to the members of the committee.
Cheers,
Andre Hedrick
Linux ATA Development
-
Re:Is this already approved for SCSI and Firewire?
Don't know about SCSI, though...
SCSI has them as part of MMC. As far as I know, it is only implemented in DVD players at the moment (to support CSS).
spec