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.
Cheers,
FJP
[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.