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: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
