Am Donnerstag, 18. August 2016 schrieb Didier Kryn:
> Le 18/08/2016 16:59, Simon Hobson a écrit :
> > OT, but there seem to be a few people who understand such in-depth stuff here ;-)
> >
> > I'm in the process of recovering (with ddrescue) files of a failing drive - no backups as "it's only TV" recordings and I can't afford the disk space anyway. It's going better than I expected with most of the files (typically anything between 1G and 4G in size) reading without any errors - retries on the disk, but no actual read errors.
> > Tedious because when the drive warms up, it "goes titsup*" (producing lots of DID_BAD_TARGET errors) and I have to unplug it and let it cool down before restarting the recovery process.
> >
> > But, mounting the source drive read-only doesn't seem to actually mean read-only as I see errors in syslog related to write errors on the disk. After a dig around, I came across "blockdev --setro <device>" which as I read things means the device itself should be set as read-only.
> >
> > But I still see things like this in syslog (when I unmount the filesystem) :
> >> end_request: I/O error, dev sdf, sector 3037143616
> >> Buffer I/O error on device sdf5, logical block 352878592
> >> lost page write due to I/O error on sdf5
> >> JBD2: Error -5 detected when updating journal superblock for sdf5-8.
> > Is it me not understanding things, or is it still trying to write to the disk ?
> > Or is it just that the filesystem code still tries to write, but fails either because the filesystem is mounted read-only or the device is set read-only ?
> >
> >
> > * Total Inability To Support Usual Performance
> >
> > _
>

>      Not sure, but could you try to also mount the disk with the noatime 
> option. I don't know if ro implies noatime.

I remember an article in german "Linuxmagazin" ~ 10 Jears ago where it said that the stock kernel drivers for all journaling file systems on linux are broken for forensic analysis due to the fact that these drivers always update the journal despite the filesystem mounted read only. Looks like that statement is still true.

The workaround given that time was to make a image of the whole device, make that image immutable, and mount the partions of that image.


Nik


--
Please do not email me anything that you are not comfortable also sharing with the NSA.