On Wed, Feb 22, 2012 at 02:25:59PM +0100, Otto Moerbeek wrote:
> 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
Correct. fsck_msdos has not been hacked to handle anything other than 512 byte
blocks/sectors. I was more interested in the path by which it could end up
using the non-raw device vs raw device. i.e. it seems wrong that fsck_msdos
does not use the raw device.
Also, when we ask for the dmesg, it's much better to post the entire dmesg.
.... Ken
> >
> >
> > 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
