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

Bug#379835: NTFS (partition) not recreated correctly after resize: incorrect start sector



On Tuesday, 25 Jul 2006 21:35:05 +0200, Frans Pop wrote:
> As can be seen in the bug history, partman needs to create the new
> smaller/larger partition with the same start sector (not start cylinder)
> as the old partition.

I have investigated further what happens in partman.

The script that is called when resizing an NTFS partition is:
/lib/partman/active_partition/70resize/do_option

Before this script is executed, a partition dump in /var/log/partman shows:
Partitions: #	id					length		type     fs	path	name
(0,0,0)       (0,0,62)      -1	0-32255			32256		primary  label	/dev/scsi/host0/bus0/target0/lun0/part-1	
(0,1,0)       (0,32,31)     -1	32256-1048575		1016320		unusable free	/dev/scsi/host0/bus0/target0/lun0/part-1	
(0,32,32)     (2549,228,46)  1	1048576-20973617151	20972568576	primary  ntfs	/dev/scsi/host0/bus0/target0/lun0/part1	
(2549,228,47) (2549,254,62) -1	20973617152-20974463999	846848		unusable free	/dev/scsi/host0/bus0/target0/lun0/part-1	

The NTFS partition and the surrounding free space were created by the
Windows Vista installer. After that is an existing Linux partition.

The script performs the following basic steps:
- starting size of the partition is 2048-40964095 (1048576-20973617151)
- ntfsresize -f -i /dev/scsi/host0/bus0/target0/lun0/part1
  it greps the result for the smallest possible size for the partition
- I selected 15G as the new size
- ntfsresize -f --size 15000000000 /dev/scsi/host0/bus0/target0/lun0/part1
  this ntfs resize operation succeeds
- script calls parted_server with:
  open_dialog VIRTUAL_RESIZE_PARTITION 1048576-20973617151 15000000000
- in parted_server virtual_resize_partition calls resize_partition with
  new start and end sectors; I added a debug statement to show which start
  and end sectors it is being called with

From this call, /var/log/partman contains:
parted_server: Resizing partition with id 1048576-20973617151
parted_server: partition_with_id(1048576-20973617151)
parted_server: New size: 15000000000
parted_server: resize_partition(openfs=false)
parted_server: resize_partition start 2048; end 29298922
parted_server: try to check the file system for errors
parted_server: successfully checked

This clearly shows that resize_partition is called with correct parameters.

- resize_partition calls libparted:
  ped_disk_set_partition_geom(disk, part, constraint, start, end)
- this resize in itself is performed correctly; the next partition
  dump in /var/log/partman shows:

Partitions: #	id					length		type     fs	path	name
(0,0,0)    (0,0,62)	 -1	0-32255			32256		primary  label	/dev/scsi/host0/bus0/target0/lun0/part-1	
(0,1,0)    (1823,254,62)  1	32256-15002910719	15002878464	primary  ntfs	/dev/scsi/host0/bus0/target0/lun0/part1	
(1824,0,0) (2549,254,62) -1	15002910720-20974463999	5971553280	unusable free	/dev/scsi/host0/bus0/target0/lun0/part-1	

This shows that ped_disk_set_partition_geom does _not_ create the partition
at the requested sectors.

fdisk with the 'u' option shows the partition as:
   Device Boot      Start        End      Blocks   Id  System
/dev/sda1   *          63   29302559    14651248+   7  HPFS/NTFS

The original starting sector 2048 has been changed to 63.
Instead of the requested end sector 29298922, libparted sets it at 29302559.

- next, the original script does another ntfsresize to maximize on the
  new partition:
  ntfsresize -f /dev/scsi/host0/bus0/target0/lun0/part1
- this fails because the starting sector is now incorrect

Conclusion: either resize_partition calls the wrong libparted function, or
there is a bug in parted's ped_disk_set_partition_geom function.

Attachment: pgpFDWzMX6Y_T.pgp
Description: PGP signature


Reply to: