old filesystem label remaining after partition --add 'ed?

old filesystem label remaining after partition --add 'ed?

[hansbkk]

I replaced a RAID6 member drive that hadn't been fully zero'd, had the
same partitioning layout as the previous one.

The target partition had previously had an ext3 filesystem on it for
temporary moving/copying files around, with an e2label on it.

I added the partition to the array with "mdadm /dev/md_raid6a --add
/sde4", and let it rebuild, all looks good both via -D and
/proc/mdstat

Later on, I noticed that that partition still has the e2label on it? I
know my RAID1's show the label same as if it's a regular partition,
but I've always got a "bad magic" message back from checking for a
label on a RAID5/6 array member partition.

I'm assuming this is just cosmetic, but it bothers my (probably OCD)
sense of order, so I thought I'd check in here.

I don't even know a command to remove an existing filesystem other
than zeroing out the MBR/partition table - and in this case I didn't
want to disturb data in the other partitions. I supposed I could have
formatted it as ntfs or something, but that doesn't seem right.

Any advice/comments welcome, especially if anyone thinks this isn't
just a cosmetic problem.

Re: old filesystem label remaining after partition --add 'ed?

[Phil Turmel]

On 02/16/2011 12:44 AM, hansbkk@gmail.com wrote:
> I replaced a RAID6 member drive that hadn't been fully zero'd, had the
> same partitioning layout as the previous one.
> 
> The target partition had previously had an ext3 filesystem on it for
> temporary moving/copying files around, with an e2label on it.
> 
> I added the partition to the array with "mdadm /dev/md_raid6a --add
> /sde4", and let it rebuild, all looks good both via -D and
> /proc/mdstat
> 
> Later on, I noticed that that partition still has the e2label on it? I
> know my RAID1's show the label same as if it's a regular partition,
> but I've always got a "bad magic" message back from checking for a
> label on a RAID5/6 array member partition.
> 
> I'm assuming this is just cosmetic, but it bothers my (probably OCD)
> sense of order, so I thought I'd check in here.
> 
> I don't even know a command to remove an existing filesystem other
> than zeroing out the MBR/partition table - and in this case I didn't
> want to disturb data in the other partitions. I supposed I could have
> formatted it as ntfs or something, but that doesn't seem right.

I'm going to guess that your array has v1.1 metadata.  If so, a fragment of your old filesystem still exists between the end of the MD superblock and the beginning of the data area.  MD's bitmaps are supposed to live in that area, so I'm going to guess that you aren't using an internal bitmap.  An 'mdadm -E' for that partition would help.

Ext2 and friends leave space for a boot block at the beginning, so the first ext2 superblock is 1k (?) into the partition.  The blkid library knows this, so it is looking "past" your md superblock and seeing the ext2 superblock.

A careful dd of the right sectors should knock it out.  (You're going to verify all this first, I hope.)

Phil

Re: old filesystem label remaining after partition --add 'ed?

[hansbkk]

On Wed, Feb 16, 2011 at 11:52 PM, Phil Turmel <philip@turmel.org> wrote:
> Ext2 and friends leave space for a boot block at the beginning, so the first ext2 superblock is 1k (?) into the partition.  The blkid library knows this, so it is looking "past" your md superblock and seeing the ext2 superblock.
>
> A careful dd of the right sectors should knock it out.  (You're going to verify all this first, I hope.)

No thanks, if it's not causing a problem 'll just leave it alone.

>> I replaced a RAID6 member drive that hadn't been fully zero'd, had the
>> same partitioning layout as the previous one.
>>
>> The target partition had previously had an ext3 filesystem on it for
>> temporary moving/copying files around, with an e2label on it.
>>
>> I added the partition to the array with "mdadm /dev/md_raid6a --add
>> /sde4", and let it rebuild, all looks good both via -D and
>> /proc/mdstat
>>
>> Later on, I noticed that that partition still has the e2label on it? I
>> know my RAID1's show the label same as if it's a regular partition,
>> but I've always got a "bad magic" message back from checking for a
>> label on a RAID5/6 array member partition.
>>
>> I'm assuming this is just cosmetic, but it bothers my (probably OCD)
>> sense of order, so I thought I'd check in here.
>>
>> I don't even know a command to remove an existing filesystem other
>> than zeroing out the MBR/partition table - and in this case I didn't
>> want to disturb data in the other partitions. I supposed I could have
>> formatted it as ntfs or something, but that doesn't seem right.
>
> I'm going to guess that your array has v1.1 metadata.  If so, a fragment of your old filesystem still exists between the end of the MD superblock and the beginning of the data area.  MD's bitmaps are supposed to live in that area, so I'm going to guess that you aren't using an internal bitmap.  An 'mdadm -E' for that partition would help.

Well, got something strange there. First here's a -D on the array:

When I originally created the array (using sysresccd) I spec'd v1.2
metadata. However the production filer OS uses mdadm v2.6.4, so it
might have got downgraded in later recovery operations?

[root@sannas01 ~]# mdadm -D /dev/md_raid6a
/dev/md_raid6a:
        Version : 01.02.03
  Creation Time : Wed Dec 22 08:21:09 2010
     Raid Level : raid6
     Array Size : 7199998976 (6866.45 GiB 7372.80 GB)
  Used Dev Size : 3599999488 (1716.61 GiB 1843.20 GB)
   Raid Devices : 6
  Total Devices : 7
Preferred Minor : 125
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Thu Feb 17 04:02:19 2011
          State : active
 Active Devices : 6
Working Devices : 7
 Failed Devices : 0
  Spare Devices : 1

     Chunk Size : 256K

           Name : sannas01:raid6a
           UUID : 628ddb50:a718c3dc:bd53d3e3:51eb73ca
         Events : 235750

    Number   Major   Minor   RaidDevice State
       0       8        4        0      active sync   /dev/sda4
       6       8       20        1      active sync   /dev/sdb4
       2       8       36        2      active sync   /dev/sdc4
       3       8       52        3      active sync   /dev/sdd4
       7       8       68        4      active sync   /dev/sde4
       5       8       84        5      active sync   /dev/sdf4

       8       8      164        -      spare   /dev/sdk4


When I do an -E on *any* of the members I get:

[root@sannas01 ~]# mdadm -E /dev/sde4
/dev/sde4:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 628ddb50:a718c3dc:bd53d3e3:51eb73ca
           Name : sannas01:raid6a
  Creation Time : Wed Dec 22 08:21:09 2010
     Raid Level : raid6
   Raid Devices : 6

 Avail Dev Size : 3599999729 (1716.61 GiB 1843.20 GB)
     Array Size : 14399997952 (6866.45 GiB 7372.80 GB)
  Used Dev Size : 3599999488 (1716.61 GiB 1843.20 GB)
    Data Offset : 272 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : b8deffce:73f5296e:b9f17f4d:7373900c

Internal Bitmap : 2 sectors from superblock
    Update Time : Thu Feb 17 14:19:59 2011
       Checksum : 6c94eb57 - correct
         Events : 235750

     Chunk Size : 256K

    Array Slot : 7 (0, failed, 2, 3, failed, 5, 1, 4, empty, failed,
failed, fled, failed, failed, failed, failed, failed, failed, failed,
failed, failed, fled, failed, failed, failed, failed, failed, failed,
failed, failed, failed, fled, failed, failed, failed, failed, failed,
failed, failed, failed, failed, fled, failed, failed, failed, failed,
failed, failed, failed, failed, failed, fled, failed, failed, failed,
failed, failed, failed, failed, failed, failed, fled, failed, failed,
failed, failed, failed, failed, failed, failed, failed, f

with many many more - note the "fled"s mixed in with the "failed"'s.

I wasn't worried before but I am now - should I be?

In case it means anything (sde's the recent replacement):

[root@sannas01 ~]# e2label /dev/sdd4
e2label: Bad magic number in super-block while trying to open /dev/sdd4
Couldn't find valid filesystem superblock.

[root@sannas01 ~]# e2label /dev/sde4
tmp-hita

Re: old filesystem label remaining after partition --add 'ed?

[Phil Turmel]

On 02/17/2011 02:50 AM, hansbkk@gmail.com wrote:
> On Wed, Feb 16, 2011 at 11:52 PM, Phil Turmel <philip@turmel.org> wrote:
>> Ext2 and friends leave space for a boot block at the beginning, so the first ext2 superblock is 1k (?) into the partition.  The blkid library knows this, so it is looking "past" your md superblock and seeing the ext2 superblock.
>>
>> A careful dd of the right sectors should knock it out.  (You're going to verify all this first, I hope.)
> 
> No thanks, if it's not causing a problem 'll just leave it alone.
> 

Actually, I guessed wrong.  You have v1.2 meta-data.

>>> I replaced a RAID6 member drive that hadn't been fully zero'd, had the
>>> same partitioning layout as the previous one.
>>>
>>> The target partition had previously had an ext3 filesystem on it for
>>> temporary moving/copying files around, with an e2label on it.
>>>
>>> I added the partition to the array with "mdadm /dev/md_raid6a --add
>>> /sde4", and let it rebuild, all looks good both via -D and
>>> /proc/mdstat
>>>
>>> Later on, I noticed that that partition still has the e2label on it? I
>>> know my RAID1's show the label same as if it's a regular partition,
>>> but I've always got a "bad magic" message back from checking for a
>>> label on a RAID5/6 array member partition.
>>>
>>> I'm assuming this is just cosmetic, but it bothers my (probably OCD)
>>> sense of order, so I thought I'd check in here.
>>>
>>> I don't even know a command to remove an existing filesystem other
>>> than zeroing out the MBR/partition table - and in this case I didn't
>>> want to disturb data in the other partitions. I supposed I could have
>>> formatted it as ntfs or something, but that doesn't seem right.
>>
>> I'm going to guess that your array has v1.1 metadata.  If so, a fragment of your old filesystem still exists between the end of the MD superblock and the beginning of the data area.  MD's bitmaps are supposed to live in that area, so I'm going to guess that you aren't using an internal bitmap.  An 'mdadm -E' for that partition would help.
> 
> Well, got something strange there. First here's a -D on the array:
> 
> When I originally created the array (using sysresccd) I spec'd v1.2
> metadata. However the production filer OS uses mdadm v2.6.4, so it
> might have got downgraded in later recovery operations?
>
> [root@sannas01 ~]# mdadm -D /dev/md_raid6a
> /dev/md_raid6a:
>         Version : 01.02.03
>   Creation Time : Wed Dec 22 08:21:09 2010
>      Raid Level : raid6
>      Array Size : 7199998976 (6866.45 GiB 7372.80 GB)
>   Used Dev Size : 3599999488 (1716.61 GiB 1843.20 GB)
>    Raid Devices : 6
>   Total Devices : 7
> Preferred Minor : 125
>     Persistence : Superblock is persistent
> 
>   Intent Bitmap : Internal
> 
>     Update Time : Thu Feb 17 04:02:19 2011
>           State : active
>  Active Devices : 6
> Working Devices : 7
>  Failed Devices : 0
>   Spare Devices : 1
> 
>      Chunk Size : 256K
> 
>            Name : sannas01:raid6a
>            UUID : 628ddb50:a718c3dc:bd53d3e3:51eb73ca
>          Events : 235750
> 
>     Number   Major   Minor   RaidDevice State
>        0       8        4        0      active sync   /dev/sda4
>        6       8       20        1      active sync   /dev/sdb4
>        2       8       36        2      active sync   /dev/sdc4
>        3       8       52        3      active sync   /dev/sdd4
>        7       8       68        4      active sync   /dev/sde4
>        5       8       84        5      active sync   /dev/sdf4
> 
>        8       8      164        -      spare   /dev/sdk4
> 
> 
> When I do an -E on *any* of the members I get:
> 
> [root@sannas01 ~]# mdadm -E /dev/sde4
> /dev/sde4:
>           Magic : a92b4efc
>         Version : 1.2
>     Feature Map : 0x1
>      Array UUID : 628ddb50:a718c3dc:bd53d3e3:51eb73ca
>            Name : sannas01:raid6a
>   Creation Time : Wed Dec 22 08:21:09 2010
>      Raid Level : raid6
>    Raid Devices : 6
> 
>  Avail Dev Size : 3599999729 (1716.61 GiB 1843.20 GB)
>      Array Size : 14399997952 (6866.45 GiB 7372.80 GB)
>   Used Dev Size : 3599999488 (1716.61 GiB 1843.20 GB)
>     Data Offset : 272 sectors
>    Super Offset : 8 sectors
>           State : clean
>     Device UUID : b8deffce:73f5296e:b9f17f4d:7373900c

You do indeed have v1.2 metadata, which is 4k from the start of the device (8 sectors).  The ext superblock was undisturbed at 1k.  DD zeros into the first eight sectors to clear the old fs superblock.

> Internal Bitmap : 2 sectors from superblock
>     Update Time : Thu Feb 17 14:19:59 2011
>        Checksum : 6c94eb57 - correct
>          Events : 235750
> 
>      Chunk Size : 256K
> 
>     Array Slot : 7 (0, failed, 2, 3, failed, 5, 1, 4, empty, failed,
> failed, fled, failed, failed, failed, failed, failed, failed, failed,
> failed, failed, fled, failed, failed, failed, failed, failed, failed,
> failed, failed, failed, fled, failed, failed, failed, failed, failed,
> failed, failed, failed, failed, fled, failed, failed, failed, failed,
> failed, failed, failed, failed, failed, fled, failed, failed, failed,
> failed, failed, failed, failed, failed, failed, fled, failed, failed,
> failed, failed, failed, failed, failed, failed, failed, f
> 
> with many many more - note the "fled"s mixed in with the "failed"'s.
> 
> I wasn't worried before but I am now - should I be?

I have no idea.  Never seen this one.  Grep the source for 'fled' ?  Or wait for Neil to come online in eight hours or so...

> In case it means anything (sde's the recent replacement):
> 
> [root@sannas01 ~]# e2label /dev/sdd4
> e2label: Bad magic number in super-block while trying to open /dev/sdd4
> Couldn't find valid filesystem superblock.
> 
> [root@sannas01 ~]# e2label /dev/sde4
> tmp-hita

As you've noted, just a nuisance, not a crisis.

Phil