Messages in this thread |  | | Date | Sat, 30 Sep 2000 00:29:01 +0100 | From | Anton Altaparmakov <> | Subject | Re: reading 1 hardsector size, not one block size |
| |
At 23:59 29/09/2000, Andries Brouwer wrote: >On Fri, Sep 29, 2000 at 05:36:48PM -0500, Matt_Domsch@Dell.com wrote: > > > >But the question was about reading from disk, not about reading > > > >from partition. > > Actually, that's next. In EFI, all partitions have a starting LBA and > > ending LBA on the disk. So, it would be easy to have an "odd sized" > > partition. In my current case, I would care about reading/writing to a FAT > > file system on that partition, or potentially any type file system. My > > fdisk enhancement will guarantee that only "even sized" partitions are > > created, but if someone else's partitioning program weren't so careful, I'd > > still have to live with the consequences. > >I don't think there is any reason for such a restriction. >If you happen to make a partition with an odd number of sectors >and someone creates a filesystem there with 2-sector blocks >then the last sector will not be used by the filesystem. >Nothing wrong there, happens all the time.
What about the case that the partition was formatted by another OS though and that other OS put something on the last sector? (eg. copy of bootsector) Would that be accessible just by setting the block size to 512?
And what about user space utilities? They can't read the last sector on an odd sized partition either even if the partition's fs had a block size of 512 due to the vfs blockdevice support using 1024 bytes blocks. [Yes I know you can cheat and read it from the disk device file rather than the partition device file.]
All those problems disappear as soon as you change BLOCK_SIZE to 512. And yes, I know this is the default and not necessarily the actual size. - But that is irrelevant since it effectuates a minimum blksize_size of BLOCK_SIZE on most devices. - If BLOCK_SIZE was just a default and a smaller hardsectsize would result in a smaller than BLOCK_SIZE blksize_size then I wouldn't be complaining but as it is this doesn't happen and in fact hardsectsize is often 0 so that the default BLOCK_SIZE is used. - It just happens that the default is not quite compatible with devices where it should be 512.
Again, if there is a simpler solution which makes both kernel and user mode apps behave correctly then I would be glad to hear it...
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/
|  |