RE: Parted 1.5.5-pre4

[Matt_Domsch]

> dev->sector_size isn't hard-coded to 512, but the parted IO functions
> ignore it.
> 
> Should this be changed?

Maybe...
 
> 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.
 
> I think it's best that the user of the ped_device_* does the 
> calculation (dev->sector_size / 512, etc.)

/ PED_SECTOR_SIZE. :-)

> Perhaps byte addressing is better?

Maybe.  I prefer blocks, as that's what a device is, but that's just
semantics too.
glibc provides the illusion of a flat 64-bit address space (read/write
/dev/sda), and the kernel does all the fixups underneath.

> 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.

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.  That makes a flat 64-bit address space (>=9 bits of
offset, rest is block number) really unwieldy!

For the label layer, I like using sectors for GPT at least, probably msdos
LBA too.  FSs can do whatever is natural for them, and ped_device_* can do
the natural thing of just read/write().

Would that be too hard to write?

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer
Dell Linux Solutions
www.dell.com/linux
#1 US Linux Server provider with 24% (IDC Sept 2001)
#2 Worldwide Linux Server provider with 17% (IDC Sept 2001)
#3 Unix provider with 18% in the US (Dataquest)!