At 00:40 29/09/2000, [EMAIL PROTECTED] wrote:
>I'm writing some code to grok the Intel EFI GUID Partition Table structures.
>To to so, my partition reading code (in fs/partitions) needs to be able to
>read one physical sector at a time, particularly the first and last sectors
>on the disk. The bread() function ultimately calls ll_rw_block(), which
>checks that my read size is the same as the block size, which is 1024 for a
>SCSI disk, while the physical sector size is 512 bytes. The EFI Spec calls
>for reading/writing on the physical block size.
>
>In the case of reading the first sector, I could read 2 sectors and throw
>away the bottom half.
>In the case of reading the last sector, I have to read the last 2 sectors
>and throw away the top half (assuming the disk has an even number of
>512-byte sectors).
And if it has an odd number then you can't read the last sector at all! -
That's what prevents linear raid and proper NTFS support from working on
"odd sized" partitions...
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...
Regards,
Anton
>In the case of reading exactly one sector from the middle of the disk, it's
>similar to either the first or second case.
>To read say 32 sectors anywhere on the disk, I have to do 1024-byte aligned
>bread()s, possibly doing an unaligned first block, aligned middle, and
>unaligned last block.
>
>Is there an easier method?
>
>Thanks,
>Matt
>
>
>
>
>-
>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/
--
"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/
