> > > (And the other limitations make incremental writing > > > through the OS cumbersome except for DVD-RAM) > > > > Hmm, formatted DVD+RW media also has no such > > restrictions, you can read/write individual 2048 byte blocks, > > just like DVD-RAM. > > This is not true. > > DVD+RW has more restrictions than a formatted CD-RW or DVD-RW
Can you give me a hint what kind of restrictions there are for DVD+RW media, which I missed so far (and that are worse than CD-RW or DVD-RW) ? Or are you confusing it with the restrictions that exist for DVD-RW media that is formated into "restricted overwrite" mode? The MMC-5 standard explains the restrictions for the WRITE(10) command for various CD/DVD formats. For DVD+RW is says: »6.54.3.6 DVD+RW Since DVD+RW has the Random Writable Feature, there are no special considerations for address translations or loss of streaming.« Note: "DVD+RW has the Random Writable Feature". That is exactly the same text that is included for DVD-RAM. And in section 4.4.8.3.2, writing to DVD+RW media is explained: »4.4.8.3.2 Writing Since the Initiator"s perception is that the media is sector readable, then in order to maintain compatibility with other block devices, a DVD+RW Logical Unit shall be able to also write single sectors for its Initiator. The Logical Unit is required to write DVD+RW media only in complete ECC blocks. So, the Logical Unit shall often perform a read/modify/write function in order to place the Initiator"s data in the correct position within the ECC block. That works when the ECC block to be written has already been written. When the ECC block has never been written and the Logical Unit shall write less than a full ECC block, then the Logical Unit shall create data. The correct method is to zero fill sectors for which no data is available.« So the dvd writer device is supposed to use read/modify/write to update data on DVD+RW media that is not aligned on ECC 32k block boundaries. But exactly the same must be implemented in the firmware for a dvd writer device for DVD-RAM media: DVD-RAM is random writable in ECC block (32k) increments, and the firmware in the drive must use read/modify/write to update smaller portions. Or are you talking about firmware bugs in dvd writer devices, that claim to include mmc dvd+rw support, but have bugs in their firmware when you write data that is not aligned on ECC block boundaries? That shouldn't stop us from implementing DVD+RW write support in the sd driver. Just tell us which devices are buggy (and cannot be fixed by firmware upgrades), so that we can avoid buying them. > > Solaris' sd driver could be extended to allow R/W access to > > formatted DVD+RW media, just like DVD-RAM. The main part of the fix would be to allow a "profile code" of 0x1a (DVD+RW) in addition to 0x12 (DVD-RAM) in sd_check_for_writable_cd(): http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/io/scsi/targets/sd.c#3138 3135 /* 3136 * We have good information, check for writable DVD. 3137 */ 3138 if ((out_data[6] == 0) && (out_data[7] == 0x12)) { 3139 un->un_f_mmc_writable_media = TRUE; Plus some additional code to set "un_f_dvdram_writable_device == TRUE" for a DVD+RW device (or add a new flag un_f_dvdplusrw_writable_device == TRUE"), otherwise sdopen() refuses to open the device in READ/WRITE mode. Using two binary kernel patches (in sd_check_for_writable_cd() to allow profile code 0x1a instead of 0x12, and forcing un_f_dvdram_writable_device == TRUE), allows me to do this, using a Pioneer DVD writer device with a (formatted) DVD+RW media inserted into the drive: # iostat -En ... c3t0d0 Soft Errors: 2 Hard Errors: 3 Transport Errors: 0 Vendor: PIONEER Product: DVD-RW DVR-108 Revision: 1.14 Serial No: Size: 4.70GB <4700372992 bytes> Media Error: 0 Device Not Ready: 3 No Device: 0 Recoverable: 0 Illegal Request: 2 Predictive Failure Analysis: 0 ... # cdrw -M -d /dev/rdsk/c3t0d0p0 Device : PIONEER DVD-RW DVR-108 Firmware : Rev. 1.14 () Track No. |Type |Start address ----------+--------+------------- 1 |Data |0 Leadout |Data |2295104 Last session start address: 0 # newfs -t 512 -c 512 -n 1 -i 32768 /dev/rdsk/c3t0d0s0 newfs: construct a new file system /dev/rdsk/c3t0d0s0: (y/n)? y Warning: 256 sector(s) in last cylinder unallocated /dev/rdsk/c3t0d0s0: 9180416 sectors in 17931 cylinders of 512 tracks, 1 sectors 4482.6MB in 88 cyl groups (205 c/g, 51.25MB/g, 1664 i/g) super-block backups (for fsck -F ufs -o b=#) at: 32, 105008, 209984, 314960, 419936, 524912, 629888, 734864, 839840, 944816, 8188160, 8293136, 8398112, 8503088, 8608064, 8713040, 8818016, 8922992, 9027968, 9132944 # fsck /dev/rdsk/c3t0d0s0 ** /dev/rdsk/c3t0d0s0 ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3a - Check Connectivity ** Phase 3b - Verify Shadows/ACLs ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cylinder Groups 2 files, 9 used, 4570469 free (13 frags, 571307 blocks, 0.0% fragmentation) # mount /dev/dsk/c3t0d0s0 /mnt2 # df -h /mnt2 Filesystem size used avail capacity Mounted on /dev/dsk/c3t0d0s0 4.4G 4.4M 4.3G 1% /mnt2 # umount /mnt2 # eject /dev/rdsk/c3t0d0p0 > > OK, there's still the issue with "fewer than 1000 write cycles", > > and DVD+RW doesn't verify what it's writing... > > > > Shouldn't Solaris sd allow write access to formatted DVD+RW, > > anyway? > > Solaris sd does not know about the specific additional commands that > you need in order to be able to eject the tray after you did write to a > DVD+RW. What commands? CLOSE TRACK, to stop DVD+RW background formatting and / or write temporary lead-in / lead-out? Do we really need this? If I (well, the sd driver) do not CLOSE TRACK, I can eject and re-insert the media and continue writing to the DVD+RW media, just like DVD-RAM. My "PIONEER DVD-RW DVR-108" is able to eject the tray just fine after writing data to a DVD+RW media. And AFAIR, the same is true for LG and NEC dvd writer devices with DVD+RW support. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
