On Fri, Mar 02, 2007 at 06:11:27PM +0100, Frans Pop wrote: > On Friday 02 March 2007 03:11, Ben Hutchings wrote: > > What is the intended difference in semantics between RESIZE_PARTITION > > and VIRTUAL_RESIZE_PARTITION? In the resize_partition() function these > > are distinguished by the open_filesystem flag which implied to me that > > in the latter case we wouldn't expect to find a filesystem in the > > partition at all. Clearly that's not the case here. > > I have no idea to be honest. There is a comment with the functions > VIRTUAL_RESIZE_PARTITION and GET_VIRTUAL_RESIZE_RANGE that says they > "are undocumented and should disappear", but I have no idea beyond that. > > Could it be that a virtual partition is one that has been created or > modified, but has not yet been committed to disk? This happens quite a > lot in partman.
Frans is correct. Specifically, a virtual partition is one whose geometry does not match any of the partition geometries existing on disk. You can modify things like a partition's mount point without rendering it virtual. Resizing a partition is (at present) committed immediately and so doesn't produce a virtual partition, at least not at any time when the rest of partman is in a position to notice. However, if you've just created a partition in partman and then resize it, there is clearly no filesystem there and it can be resized simply by changing the geometry of the partition in parted_server (and the associated files in /var/lib/partman/devices) without having to worry about any filesystem resizing. *However*, all of this is complicated by the handling of NTFS in partman (and I'm currently contemplating handling ext2 and ext3 the same way since parted can't handle the resize_inode feature on those filesystems, but that's another story). The VIRTUAL_RESIZE_PARTITION and GET_VIRTUAL_RESIZE_RANGE functions implement equivalents of RESIZE_PARTITION and GET_RESIZE_RANGE, but force parted_server to resize only the partition and not the filesystem. The reason that they were introduced is that parted can detect the presence of NTFS (probe succeeds), but it has no idea how to resize it. partman-partitioning/resize.sh therefore forcibly disables any attempts by parted_server/libparted to resize the filesystem; instead they need to resize the partition but leave it up to ntfsresize to resize the filesystem. Thus, open_filesystem is to be interpreted as a verb in the imperative voice; if it's false, resize_partition is being instructed not to attempt to ped_file_system_open the filesystem (a prerequisite for ped_file_system_resize). At this point you might ask (and I did) how shrinking an NTFS partition manages to work with Ben's patch. The answer is that there's some unbelievably nasty code in partman-partitioning/resize.sh which checks whether it's shrinking or expanding the filesystem. If it's expanding it, it does VIRTUAL_RESIZE_PARTITION, COMMIT [0], ntfsresize; if it's shrinking it, it does COMMIT, ntfsresize --size, VIRTUAL_RESIZE_PARTITION, and then another ntfsresize without --size just to make sure it's right. [0] Unnecessarily, since VIRTUAL_RESIZE_PARTITION already does a ped_disk_commit. This is probably a leftover from something or other. So, given these required semantics, I think Ben's analysis is correct. The business about possibly detecting the broken remnants of a filesystem is true, but in practice (and somewhat counterintuitively) VIRTUAL_RESIZE_PARTITION is only ever called when a filesystem is known to be present on disk, i.e. when VIRTUAL returns false. Some of this should probably end up as comments in the code. > > It should be clear that all the new code (aside from the error check) > > only runs in the currently broken case, so this does not affect > > resizing ext2 etc. And none of it is running below > > maximize_extended_partition(). > > This new patch works again. I've asked Colin Watson if he can review your > patch. Within the D-I team he currently has the best grasp of what > happens in this area of partman. The above is about the best I can do. I don't know the ped_alignment_*, ped_geometry_*, or ped_constraint_* functions well enough to review the specifics of the calls to those functions, but I believe the logic is correct. Incidentally, I noted to Frans on IRC that his call to sleep in partman-partitioning should be replaced with update-dev, which is the proper way in d-i to wait for udev to settle or to ask userdevfs to update itself. (The latter is of course not very relevant in the case of NTFS.) Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]