On 02/17/2011 02:57 PM, Curtis Gedak wrote:
> In my testing I recall some GNU/Linux distributions as having both
> /dev/mapper and /dev/dm-# entries for the same dmraid device (and not
> symbolic links).  Hence duplicate entries might already exist, even
> without using GParted.  'Just thought you might want to know that this
> situation can arise even without the use of GParted.

Not quite.  One or other of those is a symlink.  There is only one 
actual device, so things like is it mounted checks follow the symlinks 
and all check against the same bdev.

> Many users run GParted from a Live CD or USB image so that no
> partitions are mounted and the full capabilities of GParted are
> available.  In this situation, the device naming does not matter to
> the GNU/Linux distributions on the hard disk device because the live
> image partition names disappear on reboot.

It matters if the partition is mounted, and then gparted makes a 
completely separate block device show up that you can delete, and create 
a new partition using that same space, despite the fact that the 
original partition using that space is still mounted.

> To better understand your perspective, why are you concerned that
> GParted creates devices that follow the old dmraid naming standard?

I don't care WHICH standard is followed so much as that SOME standard is 
obeyed by all components running in the system, so that the duplicate 
device problem can be avoided.  I think you have sold me though on the 
'p' only when needed method that kpartx uses.

> The long term plan would be to remove DMRaid.cc.  However to my
> knowledge (lib)parted versions that support dmraid have not been out
> for very long.  Parted 2.3 was released on 28 May 2010, so it has not
> even been out for a year.

So why can't gparted releases from this year depend on libparted 
versions also released this year?

> Parted versions 1.9.0 up to and including 2.2 have been out for longer
> but have experienced a critical problem to varying degrees.  The
> critical problem is a failure to inform the kernel of partition
> changes.  This causes grief when used with GParted.
> See:
> Problem Resizing File Systems with GParted
> http://gparted-forum.surf4.info/viewtopic.php?id=13777
> GParted contains a work-around for these earlier version,
> but it does not work 100% of the time.

This is the regression from dropping the BLKPG ioctl support and going 
back to only BLKRRPART, so re-reading failed if any partition on the 
drive was in use?  I fixed that what?  A year ago now?

> Hence if I am to change the minimum requirement of GParted to be
> libparted 2.3, then more time is needed for major GNU/Linux
> distributions to all be using at least this version or higher in the
> their currently supported releases.

Why?  Who says a distribution needs to be able to run the latest version 
of gparted, but an outdated version of libparted?  If the distribution 
can update to the latest version of gparted, then they can update parted 
as well just as easily.

> Yes, compatibility with older versions of (lib)parted is desired for
> the reasons described above.  I would suggest that this configuration
> option should automatically be set based on the (lib)parted
> version.

This could be done if desired, but really, why bother?  Why not simply 
put in the release notes that to use this latest version of gparted, you 
need a version of parted released in the last year?

> If the goal is to have better support for dmraid devices in Natty, I
> would suggest that a more recent version of GParted be used.
> A problem with the dmraid path name was fixed in GParted 0.7.1:
> https://bugzilla.gnome.org/show_bug.cgi?id=634553

Can you be a bit more specific about related fixes since 0.7.0?  Getting 
an official dev to sponsor an update to a new upstream version this late 
in the Natty cycle would require a good reason.  I am sure I can get a 
small patch in, but updating to a new upstream release requires 
justification.

> The -P argument could be dropped; however, I think your idea to scan
> the output would then be required to determine what type of partition
> name was created by dmraid (e.g., with or without the 'p').

Scanning the output of dmraid would be a better general solution for 
gparted to support multiple versions of dmraid, but is a much more 
involved change, with more potential for regressions.  Therefore, I 
think I will just drop the -P argument for now, since within the scope 
of Natty we know what version of dmraid we have and can control its 
behavior, and I might take a look at a configure option to drop the 
whole DMRaid.cc module and leave it all to libparted for Natty+1, and 
submitting upstream patches for parted and dmraid to only add the 'p' if 
the previous character is a digit instead of always.  I will try to 
coordinate with you closely so that if it is not merged upstream in time 
for Natty+1, that it will at least have your approval so I can get it 
into Natty+1 early in the cycle as a patch.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/719129

Title:
  [Natty] Gparted duplicates dmraid partition devices

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to