This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

The reason that is was assigned to device-mapper is that the exact same thing happens if you use a simple linear device.  Whatever is causing the corruption is not in any multipath specific code.

Unfortunately, it's also not consistently reproduceable, but I have hit this multiple times with both a multipath device, and simple linear device.

Here's how I reproduced it.

# dmsetup create test --table "0 563214336 linear 8:16 0"
# parted /dev/mapper/test -s "mklabel gpt"
# parted /dev/mapper/test -s "mkpart primary ext2 0M 256M"
# parted /dev/mapper/test -s "mkpart primary ext2 256M 512M"
# mke2fs -t ext2 /dev/mapper/testp1 -L TEST1
# mke2fs -t ext2 /dev/mapper/testp2 -L TEST2
# findfs LABEL=TEST1

#THIS WORKS#

# parted /dev/mapper/test -s "mkpart primary ext2 512M -1"
# findfs LABEL=TEST1

#HERE IT FAILS. NOT ONLY THAT, THE FILESYSTEM IS NOW UNMOUNTABLE#

The only problem is that after reproducing it about three or four times, using both a multipath device, and a linear device, it stopped reproducing.  I haven't been able to hit it since, and I have no clue what the difference is.

Is it still reproducible, when you add "udevadm settle" between commands?

And are there any messages from device-mapper in syslog? (like device is busy etc)

(In reply to comment #7)
> Is it still reproducible, when you add "udevadm settle" between commands?    

In RHEV-H, we do run udevadm settle after each of the parted commands.  We still see this problem.

This issue is a blocker for RHEL 6 since it is causing a blocker in RHEV-H 6.  I've tried to work around the issue to no avail.

(In reply to comment #6)
> Here's how I reproduced it.
> 
> # dmsetup create test --table "0 563214336 linear 8:16 0"
> # parted /dev/mapper/test -s "mklabel gpt"

In RHEV-H, we're using msdos, not gpt.  Not sure if it matters, but that is a difference from what we're running.

Seems I am able to reproduce it (sometimes). This is probably bug in parted, I see that even after creating second parititon, "parted print" cannot see filesystem on the first partition. (blkid -p still see it though)

Anyway, there is clear data corruption.

(In reply to comment #6)
> # parted /dev/mapper/test -s "mkpart primary ext2 0M 256M"
produces
Warning: The resulting partition is not properly aligned for best performance

changing this to aligned offset
parted /dev/mapper/test -s "mkpart primary ext2 4M 256M"

fixes the problem. strange...

I am quite confused - parted do not see fs, after flush it see it again.

+ dmsetup create test --table '0 312500000 linear /dev/sdh 0'
+ parted /dev/mapper/test -s 'mklabel gpt'
+ parted /dev/mapper/test -s 'mkpart primary ext2 0M 256M'
Warning: The resulting partition is not properly aligned for best performance.
+ mke2fs -t ext2 /dev/mapper/testp1 -L TEST1
mke2fs 1.41.12 (17-May-2010)
Filesystem label=TEST1
...

+ parted /dev/mapper/test print
...
Number  Start   End    Size   File system  Name     Flags
 1      17.4kB  256MB  256MB               primary

* NO FS *

# parted /dev/mapper/test print
...
Number  Start   End    Size   File system  Name     Flags
 1      17.4kB  256MB  256MB               primary

# echo 3 > /proc/sys/vm/drop_caches

* FLUSH CACHE *

# parted /dev/mapper/test print
...
Number  Start   End    Size   File system  Name     Flags
 1      17.4kB  256MB  256MB  ext2         primary

and ext2 here again...

to be exact, proper 1MiB alignment is this, 1024k seems not to work properly...
mkpart primary ext2 2048s 256M

(In reply to comment #18)
> to be exact, proper 1MiB alignment is this, 1024k seems not to work properly...
> mkpart primary ext2 2048s 256M    

Hmm 1024k should work just fine really. What do the device mapper
/sys/block/dm-#/queue/*_io_size attributes look like ?

(In reply to comment #19)
> (In reply to comment #18)
> > to be exact, proper 1MiB alignment is this, 1024k seems not to work properly...
> > mkpart primary ext2 2048s 256M    
> 
> Hmm 1024k should work just fine really. What do the device mapper
> /sys/block/dm-#/queue/*_io_size attributes look like ?    

Duh never mind parted's cmdline uses 1000 as k size instead of 1024, how nice.

All this come to his commit:
http://git.debian.org/?p=parted/parted.git;a=commitdiff;h=2a6936fab4d4499a4b812dd330d3db50549029e0

"I've checked with two independend storage subsystem kernel
developers, and /dev/sda and /dev/sda#, guarantee cache coherency
now-a-days.  So there is no need to do this for 2.6, which also
eliminates the need to call _flush_cache() on device open at all."

Didn't you forgot about DM? :-)

Well, I think DM _should_ guarantee cache coherency on the whole device stack
(we should probably have separate bug here), apparently there is 
problem:
- we have one mapping over the whole device (multipath or linear) and partition mappings over that
- while mkfs operates on partition device, parted accesses directly to underlying device

Because in example the device is misaligned and GPT/part table write requires aligned write and so the real aligned write exceeds to partition mapping.

And it seems to use old cached data before fs was created, overwriting mkfs-ed partition data.
(The real corruption happends in ped_device_write() when writing part table with new partition.)

Created attachment 439001 [details]
Proposed workaround for parted

This workaround reintroduce flush-cache for changed DM device on open which seems to be enough to fix this problem.

mbroz' patch which fixes this is in parted-2.1-10.el6, moving to modified.

I've verified that the new parted does not break installs with both mdraid and dmraid bios raid set installs. Using both auto and custom partitioning.

Retried this on RHEV-H again with updated parted and still end up with: 

...
Number  Start   End    Size  Type     File system  Name     Flags
 1      512B  256MB   256MB  primary 
 2      257M  512MB   255MB  primary     ext2

(if you have new reproducer please paste it here - it works for me - both for gpt and msdos partition)

Do you have on that system installed udisks package?

If so, can you remove it and try to reproduce it?

RHEV-H does not have udisks installed.
I tried a new spin of RHEV-H this morning and I'm not seeing the corruption anymore.  I'm hitting another issue but it doesn't appear to be related at this point. 

My install machine is an IBM Server using multipathed luns on an HP MSA for the storage device.

*** Bug 613754 has been marked as a duplicate of this bug. ***

moving to verified based on comment 33

Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.