Ok, This is a bit speculative, if you look at (jpeg): https://bugzilla.redhat.com/attachment.cgi?id=367801 Which shows the result of running parted on an nvidia JO with a gpt partition table created by windows 7, you see 2 warnings: 1) Backup gpt table (which lives at the end of the disk) not found, and .. 2) The gpt table created on the JBOD by Windows 7 does not use the entire drive Given that (I've checked with upstream) that there are no other known cases of parted disliking windows 7 written GPT tables, I think that dmraid has gotten the size (and/or location) of the mediashield metadata wrong, thereby creating a bigger raidset then window sees (as windows has reserved more space for metadata), which leads to: 1) the gpt backup table no longer being at the end of the set (as the set is larger now) 2) parted warning there is unused space on the disk As said this is a bit speculative, but atm it is the best bet about what is going on here.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Phil, can you provide the metadata dump for this dmraid configuration using "dmraid -rD", please ? tar/bzip2 the directory+files (dmraid.nvidia/) created and attach them to this bz to allow me to look at the sizing issue Hans comments in #23 of bz#528276 Thanks, Heinz
Created attachment 406098 [details] output from dmraid -rD certainly, see attached. sda = WD 75GB raptor sdb = Seagate 750GB sdc = WD 75GB raptor sdd = Seagate 750GB sr0 = LG DVD sde = Seagate 750GB i did this to deliberately put each disk on a separate sata channel. I also included the stdout from the command in the archive.
Some more information extracted from bug 528276, as I think it is best to move all discussion of this issue to this bug for now. dmraid creates the following table for the raidset in question: [root@localhost /]# dmsetup table nvidia_eaefbedd: 0 1465149166 linear 8:16 0 nvidia_eaefbedd: 1465149166 1465149166 linear 8:48 0 nvidia_eaefbedd: 2930298332 1465149166 linear 8:64 0 Which comes down to 2146214 MiB, however windows only sees 2146086. smartctl says the disks are 1465149168 sectors, so dmraid is reserving 2 sectors per disk for raid metadata at the end of the disk. Even weirder is the dmraid -s output: [root@localhost /]# dmraid -s *** Active Set name : nvidia_eaefbedd size : 4395447168 stride : 128 type : linear status : ok subsets: 0 devs : 3 spares : 0 Notice this claims a size of 4395447168 sectors, but the mapping in the dm table has a size of 4395447498 sectors.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I've no reason to believe this has been fixed, moving to rawhide.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19