[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#474698: partman-base: Inconsistent output if sector size != 512 bytes

On Wednesday 30 April 2008, Otavio Salvador wrote:
> Because ramdisks cannot be opened with O_DIRECT and lastest parted
> needs it. This has been done long time ago to avoid some sync problems
> with disks.

Ferenc: can fdisk open /dev/ram devices and report its sector size?

If it can then I'd say closing #477378 was not correct. If fdisk can do it 
then shouldn't parted also be smart enough to just not use O_DIRECT when 
accessing a ramdisk?

> We could hack parted to allow it for testing but it's not a "real" test.

What makes you say that this is not a "real" test?
Seems to me that RAID over ramdisk is sufficient abstraction from the fact 
that a ramdisk is being used that parted should do the right thing, 
especially if fdisk handles it correctly.

You also have not really answered the question whether the use of 
PED_SECTOR_SIZE_DEFAULT in parted_server is correct at all.

If that is hardcoded to a value of 512 in libparted (which seems to be the 
case [1]), then using it whenever _existing_ devices are being read or 
modified seems fundamentally broken to me and parted_server should be using 
whatever variable has the actual sector size of the device (which in most 
cases will probably be identical to PED_SECTOR_SIZE_DEFAULT).

From my layman's perspective adding some debug code to parted_server to 
check whether that variable has sane values in all cases where we currently 
use PED_SECTOR_SIZE_DEFAULT would seem to make sense (the alternative being 
a code review of libparted). If that does not turn up anything strange 
after testing on a couple of architectures, I'd be quite comfortable with 
making a switch in partman.


[1] In both 1.7.1-5 and version in experimental I see:
    include/parted/unit.h:35:#define PED_SECTOR_SIZE_DEFAULT   512LL

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: