dmesg only says: [ 4274.426964] UDF-fs: No anchor found [ 4274.426967] UDF-fs: No partition found (1) In 2.6.29 all works fine, also there is a workaround (found on http://forums.opensuse.org/hardware/414912-dvd-automounting-udf-problems.html ) in 2.6.30 to mount with -o lastblock=1. This looks related to the LG drive mentioned in the link, as I recently bought one to replace my old one (also LG, but the old one was ATA and the new one is SATA).
Reassigned to Jan. This is a 2.6.29->2.6.30 regression.
I'd like to make sure of one thing: In 2.6.29 you mount the media as a UDF filesystem just fine. In 2.6.30, you are not able to mount the media without the lastblock=1 option, right? Could you run dvd+rw-mediainfo /dev/sr0 (or whatever your drive is) on the drive with the problematic media? The tool is in dvd+rw-tools package.
Yes, that's right. $ dvd+rw-mediainfo /dev/sr0 INQUIRY: [HL-DT-ST][DVD-RAM GH22NS30][1.02] GET [CURRENT] CONFIGURATION: Mounted Media: 2Bh, DVD+R Double Layer Media ID: MKM/003 Current Write Speed: 10.0x1385=13850KB/s Write Speed #0: 10.0x1385=13850KB/s Write Speed #1: 8.0x1385=11080KB/s Write Speed #2: 6.0x1385=8310KB/s Write Speed #3: 4.0x1385=5540KB/s Speed Descriptor#0: 00/16383983 R@8.0x1385=11080KB/s W@10.0x1385=13850KB/s Speed Descriptor#1: 00/16383983 R@8.0x1385=11080KB/s W@8.0x1385=11080KB/s Speed Descriptor#2: 00/16383983 R@8.0x1385=11080KB/s W@6.0x1385=8310KB/s Speed Descriptor#3: 00/16383983 R@8.0x1385=11080KB/s W@4.0x1385=5540KB/s READ DVD STRUCTURE[#0h]: Media Book Type: 00h, DVD-ROM book [revision 0] Legacy lead-out at: 2046976*2KB=4192206848 DVD+R DOUBLE LAYER BOUNDARY INFORMATION: L0 Data Zone Capacity: 2046976*2KB, can no longer be set READ DISC INFORMATION: Disc status: complete Number of Sessions: 1 State of Last Session: complete Number of Tracks: 1 READ TRACK INFORMATION[#1]: Track State: invisible Track Start Address: 0*2KB Free Blocks: 0*2KB Track Size: 4093936*2KB FABRICATED TOC: Track#1 : 17@0 Track#AA : 17@4093936 Multi-session Info: #1@0 READ CAPACITY: 4093936*2048=8384380928
Also for comparison, here's the output for the same disc, from my laptop, where mounting it works fine: $ dvd+rw-mediainfo /dev/sr0 INQUIRY: [TEAC ][DV-W28E-R ][S.0A] GET [CURRENT] CONFIGURATION: Mounted Media: 2Bh, DVD+R Double Layer Media ID: MKM/003 Current Write Speed: 6.0x1385=8310KB/s Write Speed #0: 6.0x1385=8310KB/s Write Speed #1: 4.0x1385=5540KB/s Write Speed #2: 2.4x1385=3324KB/s Speed Descriptor#0: 00/4093935 R@6.0x1385=8310KB/s W@6.0x1385=8310KB/s Speed Descriptor#1: 00/4093935 R@4.0x1385=5540KB/s W@4.0x1385=5540KB/s Speed Descriptor#2: 00/4093935 R@2.4x1385=3324KB/s W@2.4x1385=3324KB/s READ DVD STRUCTURE[#0h]: Media Book Type: 00h, DVD-ROM book [revision 0] Legacy lead-out at: 2046976*2KB=4192206848 DVD+R DOUBLE LAYER BOUNDARY INFORMATION: L0 Data Zone Capacity: 2046976*2KB, can no longer be set READ DISC INFORMATION: Disc status: complete Number of Sessions: 1 State of Last Session: complete Number of Tracks: 1 READ TRACK INFORMATION[#1]: Track State: partial/complete Track Start Address: 0*2KB Free Blocks: 0*2KB Track Size: 4093936*2KB FABRICATED TOC: Track#1 : 14@0 Track#AA : 14@4093936 Multi-session Info: #1@0 READ CAPACITY: 4093936*2048=8384380928
Thanks for the information. What catches my eye is that one drive reports a track state as partial/complete while the other one reports it as invisible. What does report the test program attached below please?
Created attachment 22989 [details] Program for detecting CD/DVD size You can run it as stat_cdrom /dev/sr0
On non-working DVDs it looks like this: Device size: 16375744 Device sector size: 2048 Device logical block size: 4096 Multisession: xa_flag = 0 addr = 0 Last written: 0 On the working ones "Last written" looks normal. Also I've done some tests now and it looks like it's got something to do with file sizes. A full (>4GB) dvd stuffed with small files work, but a DVD with one 2,2GB file doesn't.
I thought 2GiB was the file limit, but then I burned a 2147483649 byte file (2GiB + 1 byte) to a DVD and it mounted fine...
I also booted 2.6.29 kernel and ran your test app on a "non-working" DVD - in 2.6.29 it also said Last written: 0, but mounted fine there.
Ah, I see what's going on. This should be fixed in the latest Linus's kernel - does it work for you? I didn't know it was a regression. I'll push the fix also to 2.6.30 -stable tree. Thanks for your help.
here's another sample from a recent LG drive: (07/09 14:05) root@vmr45 /usr/src/linux # dvd+rw-mediainfo /dev/sr0 INQUIRY: [HL-DT-ST][DVD-RAM GH22NP20][1.04] GET [CURRENT] CONFIGURATION: Mounted Media: 2Bh, DVD+R Double Layer Media ID: MKM/001 Current Write Speed: 4.0x1385=5540KB/s Write Speed #0: 4.0x1385=5540KB/s Speed Descriptor#0: 00/16383983 R@8.0x1385=11080KB/s W@4.0x1385=5540KB/s READ DVD STRUCTURE[#0h]: Media Book Type: 00h, DVD-ROM book [revision 0] Legacy lead-out at: 1720000*2KB=3522560000 DVD+R DOUBLE LAYER BOUNDARY INFORMATION: L0 Data Zone Capacity: 1720000*2KB, can no longer be set READ DISC INFORMATION: Disc status: complete Number of Sessions: 1 State of Last Session: complete Number of Tracks: 1 READ TRACK INFORMATION[#1]: Track State: invisible Track Start Address: 0*2KB Free Blocks: 0*2KB Track Size: 3439984*2KB FABRICATED TOC: Track#1 : 17@0 Track#AA : 17@3439984 Multi-session Info: #1@0 READ CAPACITY: 3439984*2048=7045087232 mounting with lastblock=1 seems to work. is there a patch i could apply to my 2.6.30-r4 yet?
Created attachment 23035 [details] Patch overriding bogus number of recorded blocks This is a patch that should fix your problem.
thanks a lot jan, it works.
Yeah, mounting is fixed in 2.6.31, thanks a lot ;] However dvd+rw-mediainfo still shows "Track State: invisible" and your little app prints "Last written: 0". I also noticed, that I get i/o errors when writing double layer DVDs (during writing or at the end during fixating). It looks like your fix is just a workaround for a real problem somewhere in the driver for the drive. I'll file another bug, but I'm not sure where should I put it. I/O storage->block layer?
Yeah, possibly there's some change in the SATA handling code which causes this change so if you could report to I/O storage -> block layer (you can add Tejun Heo <htejun@gmail.com> to CC since he's been solving a similar problem lately) it would be useful. Thanks.