Re: Parted 1.5.5-pre4

[Andrew Clausen]

On Sun, Dec 02, 2001 at 08:28:14PM -0600, address@hidden wrote:
> > The thing is, file systems use these functions heavily, etc.
> 
> Sure, but they probably think in terms of 1k "blocks" (at least the kernel
> does).  Maybe a fs->block_size member could be helpful, and fs read/writes
> pass through an (inline) translation function.

It varies a bit.  A lot think in terms of 512 byte blocks.  (FAT
for example)

> > I think it's best that the user of the ped_device_* does the 
> > calculation (dev->sector_size / 512, etc.)
> 
> / PED_SECTOR_SIZE. :-)

Definitely not.  The file system depends on it being 512.
PED_SECTOR_SIZE indicates that the code is "decoupled", but that
would just be pretending.

> > Perhaps byte addressing is better?
> 
> Maybe.  I prefer blocks, as that's what a device is, but that's just
> semantics too.
> glibc

err, the kernel's syscall interface?

> provides the illusion of a flat 64-bit address space (read/write
> /dev/sda), and the kernel does all the fixups underneath.

Flat 64-bit address-space is nice and simple.

> > 64 bits is enough?
> 
> For the forseeable future.  But then again, SCSI now has 64-bit LBAs of
> sector_size.  IDE has 48 bits.  You'd want to treat them the same way, and
> unless you want to lop off the high 9 bits from SCSI (safe for now), it
> won't all fit in 64 bits.

And the high 9 bits actually get used?  My friend here... Ralf
Bächle said that no-one comes close to using them.  Not even EMC TM.

If I did the math right, we get 16 petabytes...

> Then there are the really odd 520-byte sector formatted disks (520
> byte/sector is a well known AS400 feature, HP also uses it to store a CRC
> for each sector).  Linux can't handle non-power-of-2 formatted disks yet,
> but maybe in 2.5.x.

Is this important to support?

> That makes a flat 64-bit address space (>=9 bits of
> offset, rest is block number) really unwieldy!

Huh?

> For the label layer, I like using sectors for GPT at least, probably msdos
> LBA too.

I think linear addressing would simplify it marginally.

> FSs can do whatever is natural for them, and ped_device_* can do
> the natural thing of just read/write().

"the label layer" uses ped_device_* ;)

> Would that be too hard to write?

What gets difficult is when you want to convert between different
systems.  Eg: if you have a 2048 byte interface, but want to use
512 byte sectors.  Imagine trying to write 1 sector... it involves
read 2048/overlay 512/write 2048... painful, not to mention
inefficient.

This is the main reason I want ped_device_* to do either 512 byte or
1 byte addressing.

Andrew