Bug#380226: NTFS (partition) not recreated correctly after resize:incorrect start sector
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 [cjwatson@debian.org]
Reply to: