Messages in this thread |  | | Date | Sat, 30 Sep 2000 00:50:05 +0100 | From | Anton Altaparmakov <> | Subject | Re: reading 1 hardsector size, not one block size |
| |
At 00:35 30/09/2000, Alexander Viro wrote: >On Sat, 30 Sep 2000, Anton Altaparmakov wrote: > > > All those problems disappear as soon as you change BLOCK_SIZE to 512. And > >Have you actually tried that? Go ahead, just do full backup before the >experiment...
I hope you don't mind me quoting my own email which I sent yesterday in this thread but that answers your question - but in one sentence yes I tried and no I didn't need a backup: --- quote from my own email from yesterday--- I don't see any Clean Way(TM) to fix this, as well as your "EFI Spec calling for physical block size" problem, apart from changing the kernel BLOCK_SIZE to 512 (from the current 1024) and picking up the pieces afterwards... - I would be very happy if someone tells me I am wrong! (-; Note that I don't think adding any form of hacks into partition table / file system code to allow low-level access to the underlying device can be considered a Clean Way(TM) since such code has no business dealing with what device it is on. The only thing that such code has business dealing with is logical access to the particular partition in question. This is all IMHO... I doubt that such a change would be accepted for 2.4 at such a late stage considering making the change breaks just about every block device driver and at least the ext2 file system (read: kernel doesn't boot if the change is done!). - Having said that, my development PC actually is running a kernel with BLOCK_SIZE = 512 but I had to do a few modifications to get it to work. (-: It became apparent that despite that the code in many source files in the kernel uses BLOCK_SIZE macro it at the same time assumes that it equals 1024, which is, IMHO, a strange thing to assume to say the least, but anyway, all those places have to be fixed first. - Ext2 is pretty much ok except for the fact that you need to start using the (already existing) MIN_EXT2_BLOCKSIZE macro in fs/ext2/super.c and you have to change the super_block location calculation in the same place. - My current tree (based on 2.4.0-test8+various patches) has fixed drivers/ide/hd.c, drivers/scsi/sd.c, drivers/scsi/scsicam.c(?), fs/ext2/super.c and fs/partitions/check.c so that the code works for any definition of BLOCK_SIZE (well, at least for any sane definition...) and this makes it work both with my IDE and SCSI hard disks and ext2 partitions as well as with my current devel tree version of NTFS, now being able to read the last sector on odd sized partitions. - Also reads (open(2)/read(2) on /dev/[hs]daX, for various X tested) now allow me to see all sectors. - The kernel also "feels" faster but that might be just wishful thinking/timing coincidence... no benchmarks available... What I am fairly certain is now broken due to changing BLOCK_SIZE to 512: ramdisk+initrd, floppy disk(?) and raid. I have started working on the latter but I haven't gotten it to work yet. )-: Note that all my above changes don't break anything if BLOCK_SIZE is left at 1024. I am planning on updating my patches when 2.5 comes out and start submitting them slowly to the various maintainers so that it should eventually be just possible to just change BLOCK_SIZE to 512 and recompile and it then all automagically works but that might be some time away... --- eoq ---
Regards,
Anton
--
"Education is what remains after one has forgotten everything he learned in school." - Albert Einstein
-- Anton Altaparmakov Voice: 01223-333541(lab) / 07712-632205(mobile) Christ's College eMail: AntonA@bigfoot.com Cambridge CB2 3BU ICQ: 8561279 United Kingdom WWW: http://www-stu.christs.cam.ac.uk/~aia21/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |