Re: CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB: not harmless?
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
Reply to: