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.