2.5.29 IDE 110
Quoted 6 lines · Marcin Dalecki
- Eliminate support for "sector remapping". loop devices can handle stuff like that. All the custom DOS high system memmory loaded BIOS workaround tricks are obsolete right now. If anywhere it should be the FAT filesystem code which should be clever enough to deal with it by adjusting it's read/write methods.
Hi Marcin,
I'm using this on one system here - it has BIOS without LBA32, and
without support for >30GB disks, but I needed to put large disk with already existing system to it, and using some disk manager was only choice (EZDrive, using 0_to_1 remap)... I know that 0_to_1 remap is broken for nr_sectors > 1, but it is hard to use loop device if system does not come up without boot manager at all.
Best regards,
Petr Vandrovec [email protected]
Uz.ytkownik Petr Vandrovec napisa?:
Quoted 9 lines · Marcin Dalecki
Quoted 6 lines
- Eliminate support for "sector remapping". loop devices can handle stuff like that. All the custom DOS high system memmory loaded BIOS workaround tricks are obsolete right now. If anywhere it should be the FAT filesystem code which should be clever enough to deal with it by adjusting it's read/write methods.
Quoted 7 lines
Hi Marcin,
I'm using this on one system here - it has BIOS without LBA32, and
without support for >30GB disks, but I needed to put large disk with already existing system to it, and using some disk manager was only choice (EZDrive, using 0_to_1 remap)... I know that 0_to_1 remap is broken fornr_sectors> 1, but it is hard to use loop device if system does not come up without boot manager at all.
Maybe not a loop device? But how about handling this at partition scan time then? Partitions are after all nothing else then devices with remapped sectors in first place. Could you manage to insert at the proper place in paritions/*.c the magical + 1.
It could then be turned in no instant in to a global kernel option - whch it what it is after all.
Quoted 6 lines · Marcin Dalecki
Maybe not a loop device? But how about handling this at partition scan time then? Partitions are after all nothing else then devices with remapped sectors in first place. Could you manage to insert at the proper place in paritions/*.c the magical + 1.
It could then be turned in no instant in to a global kernel option - whch it what it is after all.
Is there any reason this can't be dumped on LVM2 and/or EVMS whichever gets in ?
Quoted 10 lines · Użytkownik Alan Cox
Quoted 6 lines · Marcin Dalecki
Maybe not a loop device? But how about handling this at partition scan time then? Partitions are after all nothing else then devices with remapped sectors in first place. Could you manage to insert at the proper place in paritions/*.c the magical + 1.
It could then be turned in no instant in to a global kernel option - whch it what it is after all.
Quoted 2 lines
Is there any reason this can't be dumped on LVM2 and/or EVMS whichever gets in ?
Lets not forgett that the code removed would allow to read behind the partion in question and was broken therefore. However the real world example from Petr worries me and makes me thinking that the partition scanning time solution could turn out to be most adequate -> we have the FAT partition ID there at hand and could adjust the partition parameters in question properly with ease. Both of them: offset *and* size.
Petr would you mind dumping the dd=/dev/hdx count=10 of the disk in question at me? Or do you preferr to go after this blotch yourself?