On Wed, Feb 22, 2012 at 01:32:15PM +0200, Alexey Vatchenko wrote:
> On Wed, Feb 22, 2012 at 12:10:28PM +0100, Otto Moerbeek wrote:
> > On Wed, Feb 22, 2012 at 12:07:11PM +0100, Otto Moerbeek wrote:
> > > On Wed, Feb 22, 2012 at 11:25:44AM +0200, Alexey Vatchenko wrote:
> > > > On Tue, Feb 21, 2012 at 01:25:40PM -0500, Kenneth R Westerback wrote:
> > > > > On Tue, Feb 21, 2012 at 12:55:36PM -0500, Ted Unangst wrote:
> > > > > > On Tue, Feb 21, 2012, Kenneth R Westerback wrote:
> > > > > > > On Tue, Feb 21, 2012 at 03:15:29PM +0200, Alexey Vatchenko wrote:
> > > > > > >> Reading 512 bytes from raw device with 2048 sector size fails.
> > > > > > >> If i read
> > > > > > >> 512 bytes from block device the problem is not reproduced.
> > > > > >
> > > > > > > This is intentional. You cannot read from a raw device fewer bytes
> > > > > > > at a time than the minimum the device provides per i/o. On block
> > > > > > > devices the buffer cache does the correct size i/o and extracts
> > > > > > > just the number of bytes you requested.
> > > > > >
> > > > > > That's backwards from what I thought. The raw device should let you
> > > > > > read byte by byte, the block device only lets you read block by
> > > > > > block,
> > > > > > as it were.
> > > > >
> > > > > Block/Sector based devices can only provide entire blocks/sectors,
> > > > > at block/sector addresses. The buffer cache and standard i/o routines
> > > > > provide the abstraction that you can start and stop at any byte.
> > > > >
> > > > > Doing I/O to raw devices means you are taking full responsibility for
> > > > > paying attention to the boundaries and sizes of the i/o.
> > > >
> > > > I thought that it was bug because it's a character device.
> > > >
> > > > Anyway, the problem is fsck that execv fsck_msdos with raw device.
> > > > Maybe better to keep device name from the calling process (fsck)?
> > >
> > > No that is not correct. fsck should not work via the buffer cache.
> >
> > Why should find out why fsck thinks this is a 512 device. Please post
> > your dmesg and disklabel.
>
> fsck_msdos/boot.c
> readboot(int dosfs, struct bootblock *boot)
> {
> u_char block[DOSBOOTBLOCKSIZE];
> u_char fsinfo[2 * DOSBOOTBLOCKSIZE];
> u_char backup[DOSBOOTBLOCKSIZE];
> int ret = FSOK;
> off_t o;
> ssize_t n;
>
> if ((n = read(dosfs, block, sizeof block)) == -1 ||
> ^^^^^^^^^^^^^^ - here is whs0 at
> n != sizeof block) {
> xperror("could not read boot block");
> return (FSFATAL);
> }
>
> fsck_msdos/dosfs.h
> #define DOSBOOTBLOCKSIZE 512
So that's the real bug: fsck_msdos isn't capable of handling anything
other than 512.
-Otto
>
>
> uhub0 port 3 configuration 1 interface 0 "Apple iPod" rev 2.00/0.02 addr
> 2
> umass0: using SCSI over Bulk-Only
> scsibus1 at umass0: 2 targets, initiator 0
> sd0 at scsibus1 targ 1 lun 0: <Apple, iPod, 1.62> SCSI0 0/direct
> removable
> sd0: 7744MB, 2048 bytes/sec, 3964928 sec total
>
>
> # /dev/rsd0c:
> type: SCSI
> disk: SCSI disk
> label: iPod
> duid: 0000000000000000
> flags:
> bytes/sector: 2048
> sectors/track: 63
> tracks/cylinder: 255
> sectors/cylinder: 16065
> cylinders: 246
> total sectors: 3964928
> boundstart: 0
> boundend: 3964928
> drivedata: 0
>
> 16 partitions:
> # size offset fstype [fsize bsize cpg]
> c: 3964928 0 unused
> i: 48132 63 unused
> j: 3916732 48195 MSDOS
