Alan Cox wrote:
hd.c:(.init.text+0x44a7d): undefined reference to `drive_info'
hd.c:(.init.text+0x44a89): undefined reference to `drive_info'
hd.c:(.init.text+0x44a95): undefined reference to `drive_info'
hd.c:(.init.text+0x44aa1): undefined reference to `drive_info'
Alan Cox wrote:
hd.c can drive MFM and RLL disks and drivers/ide cannot. Although it
really wants burying further down the config tree the ability to read MFM
and RLL disks when recovering ancient data is useful and people do
actually use this driver now and then rescuing stuff like twenty
Alan Cox wrote:
I believe the technical description for the comment is bullshit 8)
Almost all MFM controllers and RLL controllers will only run at the
standard primary and secondary ATA address.
Yes, but that doesn't (necessarily) apply to the controller that is
likely to be the primary
Alan Cox wrote:
The question I'm asking is: do you think it's better to remove this from
hd.c, or do you think it's better to add it back boot code BIOS
detection (and take the risk of poking an ST-506 disk with legacy data
with parameters which may belong to another disk -- keep in mind this
Theodore Tso wrote:
In any case, the reason why I bring this up is that it would be really
nice if there was a way with a single laptop drive to be able to do
snapshots and background fsck's without having to use initrd's with
device mapper.
This is a major part of why I've been trying to
Ric Wheeler wrote:
We still have the following challenges:
(1) read-ahead often means that we will retry every bad sector at
least twice from the file system level. The first time, the fs read
ahead request triggers a speculative read that includes the bad sector
(triggering the error
Andreas Dilger wrote:
And clearing this list when the sector is overwritten, as it will almost
certainly be relocated at the disk level.
Certainly if the overwrite is successful.
-hpa
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to
