Hi, Jens Jorgensen: > > > Could it be that there was a defect and things were relocated? me : > > It should be transparent to the reader in any > > case. > > ... > > So this could be a failure of the firmware > > to correctly perform Defect Management. Rob Bogus: > Is it possible that this is caused by a relocated block, and for some reason > the read is returning the bad block in stead of the relocation? In other > words, did this mount somehow tell the device to ignore relocation?
It would be a severe firmware bug or failure of the media to properly record the correction mapping of physical records. I am not really convinced of such a failure yet. > Might this be fixed with only a mount option > (which I certainly didn't see)? One possibly can disable the effect of Defect Management by the Streaming Bit of SCSI command 28h READ(12). At least i read MMC-5 6.16.2.6 that way: "If the Streaming bit is set to one, linear replacements shall not be performed." One would have to search in the kernel whether command 28h is used and whether bit 7 in byte 10 of the command can be set. But i would be astounished if that was the default with BD mounting resp. with the involved device driver. Also it does not explain why the zeroed block at address 8 MB causes a mountable empty UDF filesystem with no error messages in the kernel log. Jens: > > > Then I mount this filesystem, and copy all of the files into the > > > filesystem. Unmount the filesystem, now I'm ready to go. Is there any way how after umounting of the filesystem the content is still not up to date for subsequent reading of the file ? The image file got opened by growisofs via open64(O_DIRECT|O_RDONLY). Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
