I would not mind this approach:
a) if the logical blocks are multiples of 16 bytes, then just
increment it normally:
I = 10000h + (LBA * block size / 16) + (0..(block size - 1))
e.g.
I = 10000h + (LBA * 20h) + (0..19h) for 512 byte logical blocks
I = 10000h + (LBA * 40h) + (0..39h) for 1024 byte logical blocks
I = 10000h + (LBA * 80h) + (0..79h) for 2048 byte logical blocks
I = 10000h + (LBA * 100h) + (0..FFh) for 4096 byte logical blocks
The logical block size is only used to set the initial count value;
it's not really used after that (effectively just
10000h + initial value + 0..n
for the entire range being accessed).
b) if the logical block is not a multiple of 16 bytes, then add some
jumps based on the block size:
I = 10000h + (LBA * int (block size / 16) * 2) + (0..(block size - 1))
e.g.
I = 10000h + (LBA * 40h) + (0..20h) for 520 byte logical blocks
+ (21h..3Fh) go unused
I = 10000h + (LBA * 80h) + (0..40h) for 1032 byte logical blocks
+ (41h..7Fh) go unused
I = 10000h + (LBA * 100h) + (0..80h) for 2056 byte logical blocks
+ (81h..FFh) go unused
I = 10000h + (LBA * 200h) + (0..100h) for 4104 byte logical blocks
+ (101h..1FFh) go unused
This way only implementations that have the alignment issue are required
to know the logical block size and implement the jump.
--
Rob Elliott, [EMAIL PROTECTED]
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of [EMAIL PROTECTED]
> Sent: Wednesday, December 14, 2005 5:22 PM
> To: [EMAIL PROTECTED]
> Subject: RE: LBA to I mapping
>
> A typical LBA size is (going to be) 4KB, a multiplier of 32 is not
> universal. You could use ceil(LBA_size_in_bytes/16), but it sometimes
> leads to odd multipliers, and still there is no contiguous LBA
> processing with other ugly sizes. -Laszlo
>
> > -------- Original Message --------
> > Subject: LBA to I mapping
> > From: "Colin Sinclair" <[EMAIL PROTECTED]>
> > Date: Wed, December 14, 2005 12:09 pm
> > To: <[EMAIL PROTECTED]>
> >
> > There is still some confusion on this mapping:
> >
> > The minutes (and Rob just now) said "offset by 64K" which
> to me means
> >
> > I = 2^16 + LBA*32 + (0..31) for 512 byte sectors
> > and I = 2^16 + LBA*33 + (0..32) for 520 byte sectors
> >
> > but Laszlo said:
> >
> > "C. I also agree with the proposal to count
> > the cipher blocks as I = LBA*2^16+(0,1,2...)."
> >
> > which is clearly different, and contiguous sector
> processing is not possible.
> >
> > I'm guessing the former was the intention.
> >
> > > Rob said:
> > > I would prefer that I increment without knowledge of the
> underlying
> > > block size; let the unaligned devices take the hit of a
> full adder,
> > > since they already have to stall to do the CTS (as you mentioned).
> >
> > The LBA size is required to be known with whatever scheme
> is chosen, because to get the initial I
> > value for a random access sector you have to do a multiply
> of LBA * sector_size_in_blocks. My
> > mapping approach which works for any sector size avoids an
> awkward multiply by 33 for odd-sized
> > sectors. It allows a contiguous increment for consecutive
> nice-sized sectors as you desire, but
> > makes odd-sized sectors only slightly more painful (reset
> bottom n bits to zero and add 2^n).
> >
> > > LBAs in both SCSI logical units and ATA devices start at 0.
> >
> > This is important. I am slightly worried that I values of 0
> are not allowed (since T is then 0) and
> > I think this is perhaps why the current spec defines a key
> scope starting at 1. The offset by 64K
> > proposal eliminates this problem; with my mapping scheme I
> would just set the MS bit of I (add
> > 2^127), which shouldn't interfere with the 30 or so LBA bits at all:
> >
> > I = 2^127 + LBA<<n + (0,1,2...j-1), where n = ceil(log2(j))
> >
> > Colin.
>
