6:37 a.m.
Still getting the hang of md. I had it working for several days (2
disks in RAID1 config) but after a system update and reboot, it
suddenly shows no data:
]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
[...]
sdd 8:48 0 931.5G 0 disk
└─md127 9:127 0 931.4G 0 raid1
└─md127p1 259:0 0 931.4G 0 part
sde 8:64 0 931.5G 0 disk
└─md127 9:127 0 931.4G 0 raid1
└─md127p1 259:0 0 931.4G 0 part
# mdadm --detail /dev/md127p1
/dev/md127p1:
Version : 1.2
Creation Time : Wed May 20 16:34:58 2020
Raid Level : raid1
Array Size : 976628736 (931.39 GiB 1000.07 GB)
Used Dev Size : 976630464 (931.39 GiB 1000.07 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Sun May 24 12:29:54 2020
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Consistency Policy : bitmap
Name : Bree:0 (local to host Bree)
UUID : ba979f01:7f1dbe79:24f19f68:7ba6000c
Events : 22436
Number Major Minor RaidDevice State
0 8 48 0 active sync /dev/sdd
1 8 64 1 active sync /dev/sde
# mount /dev/md127p1 /raid
# ls /raid
How is this possible? The only thing that touches the array is a borg
backup run from crontab, which I have verified is working correctly,
including just before the update and reboot this morning. It looks as
if the mount is mounting the wrong thing.
Or am I missing something very obvious?
poc
7:38 a.m.
cat /proc/mounts and verify it is mounted, ls -l /raid
Unmount it and do ls -l /raid and make sure nothing is "under" it.
An issue with the raid and/or filesystem is going to be very unlikely
to cleanly remove all files like this, typically to do this you either
need to have done a rm -rf against the files, or you would need to
have done a mkfs and rebuild the filesystem deleting everything, or
nothing was ever on that filesystem.
On Sun, May 24, 2020 at 6:38 AM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
>
> Still getting the hang of md. I had it working for several days (2
> disks in RAID1 config) but after a system update and reboot, it
> suddenly shows no data:
>
> ]# lsblk
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> [...]
> sdd 8:48 0 931.5G 0 disk
> └─md127 9:127 0 931.4G 0 raid1
> └─md127p1 259:0 0 931.4G 0 part
> sde 8:64 0 931.5G 0 disk
> └─md127 9:127 0 931.4G 0 raid1
> └─md127p1 259:0 0 931.4G 0 part
>
> # mdadm --detail /dev/md127p1
> /dev/md127p1:
> Version : 1.2
> Creation Time : Wed May 20 16:34:58 2020
> Raid Level : raid1
> Array Size : 976628736 (931.39 GiB 1000.07 GB)
> Used Dev Size : 976630464 (931.39 GiB 1000.07 GB)
> Raid Devices : 2
> Total Devices : 2
> Persistence : Superblock is persistent
>
> Intent Bitmap : Internal
>
> Update Time : Sun May 24 12:29:54 2020
> State : clean
> Active Devices : 2
> Working Devices : 2
> Failed Devices : 0
> Spare Devices : 0
>
> Consistency Policy : bitmap
>
> Name : Bree:0 (local to host Bree)
> UUID : ba979f01:7f1dbe79:24f19f68:7ba6000c
> Events : 22436
>
> Number Major Minor RaidDevice State
> 0 8 48 0 active sync /dev/sdd
> 1 8 64 1 active sync /dev/sde
> # mount /dev/md127p1 /raid
> # ls /raid
>
> How is this possible? The only thing that touches the array is a borg
> backup run from crontab, which I have verified is working correctly,
> including just before the update and reboot this morning. It looks as
> if the mount is mounting the wrong thing.
>
> Or am I missing something very obvious?
>
> poc
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
10:40 a.m.
On Sun, 2020-05-24 at 07:38 -0500, Roger Heflin wrote:
cat /proc/mounts and verify it is mounted, ls -l /raid
It isn't mounted, though the mount command didn't give an error. A look
at journalctl shows:
May 24 16:38:23 Bree kernel: EXT4-fs (md127p1): mounted filesystem with ordered data mode.
Opts: (null)
May 24 16:38:23 Bree systemd[1]: raid.mount: Unit is bound to inactive unit
dev-md0p1.device. Stopping, too.
May 24 16:38:23 Bree systemd[1]: Unmounting /raid...
So it looks like PEBKAC. What should I do?
poc
8:14 a.m.
On 2020-05-24 19:37, Patrick O'Callaghan wrote:
Still getting the hang of md. I had it working for several days (2
disks in RAID1 config) but after a system update and reboot, it
suddenly shows no data:
]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
[...]
sdd 8:48 0 931.5G 0 disk
└─md127 9:127 0 931.4G 0 raid1
└─md127p1 259:0 0 931.4G 0 part
sde 8:64 0 931.5G 0 disk
└─md127 9:127 0 931.4G 0 raid1
└─md127p1 259:0 0 931.4G 0 part
FWIW, I just created a RAID1 on a VM in the "standard" way and I see....
[egreshko@f31k ~]$ sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 50G 0 disk
└─md0 9:0 0 50G 0 raid1
sdb 8:16 0 50G 0 disk
└─md0 9:0 0 50G 0 raid1
sr0 11:0 1 1024M 0 rom
vda 252:0 0 30G 0 disk
├─vda1 252:1 0 1G 0 part /boot
└─vda2 252:2 0 29G 0 part
├─fedora_f31k-root 253:0 0 27G 0 lvm /
└─fedora_f31k-swap 253:1 0 2.1G 0 lvm [SWAP]
and it seems a bit more "sane" than your configuration.
--
The key to getting good answers is to ask good questions.
10:43 a.m.
On Sun, 2020-05-24 at 21:14 +0800, Ed Greshko wrote:
On 2020-05-24 19:37, Patrick O'Callaghan wrote:
> Still getting the hang of md. I had it working for several days (2
> disks in RAID1 config) but after a system update and reboot, it
> suddenly shows no data:
>
> ]# lsblk
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> [...]
> sdd 8:48 0 931.5G 0 disk
> └─md127 9:127 0 931.4G 0 raid1
> └─md127p1 259:0 0 931.4G 0 part
> sde 8:64 0 931.5G 0 disk
> └─md127 9:127 0 931.4G 0 raid1
> └─md127p1 259:0 0 931.4G 0 part
FWIW, I just created a RAID1 on a VM in the "standard" way and I see....
[egreshko@f31k ~]$ sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 50G 0 disk
└─md0 9:0 0 50G 0 raid1
sdb 8:16 0 50G 0 disk
└─md0 9:0 0 50G 0 raid1
sr0 11:0 1 1024M 0 rom
vda 252:0 0 30G 0 disk
├─vda1 252:1 0 1G 0 part /boot
└─vda2 252:2 0 29G 0 part
├─fedora_f31k-root 253:0 0 27G 0 lvm /
└─fedora_f31k-swap 253:1 0 2.1G 0 lvm [SWAP]
and it seems a bit more "sane" than your configuration.
Yours is using LVM, which I wanted to avoid. That may be the root of
the issue (though I've no idea why).
poc
11:27 a.m.
what does the entry in /etc/fstab look like and what filesystem is it?
On Sun, May 24, 2020 at 10:44 AM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
>
> On Sun, 2020-05-24 at 21:14 +0800, Ed Greshko wrote:
> > On 2020-05-24 19:37, Patrick O'Callaghan wrote:
> > > Still getting the hang of md. I had it working for several days (2
> > > disks in RAID1 config) but after a system update and reboot, it
> > > suddenly shows no data:
> > >
> > > ]# lsblk
> > > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> > > [...]
> > > sdd 8:48 0 931.5G 0 disk
> > > └─md127 9:127 0 931.4G 0 raid1
> > > └─md127p1 259:0 0 931.4G 0 part
> > > sde 8:64 0 931.5G 0 disk
> > > └─md127 9:127 0 931.4G 0 raid1
> > > └─md127p1 259:0 0 931.4G 0 part
> >
> > FWIW, I just created a RAID1 on a VM in the "standard" way and I
see....
> >
> > [egreshko@f31k ~]$ sudo lsblk
> > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> > sda 8:0 0 50G 0 disk
> > └─md0 9:0 0 50G 0 raid1
> > sdb 8:16 0 50G 0 disk
> > └─md0 9:0 0 50G 0 raid1
> > sr0 11:0 1 1024M 0 rom
> > vda 252:0 0 30G 0 disk
> > ├─vda1 252:1 0 1G 0 part /boot
> > └─vda2 252:2 0 29G 0 part
> > ├─fedora_f31k-root 253:0 0 27G 0 lvm /
> > └─fedora_f31k-swap 253:1 0 2.1G 0 lvm [SWAP]
> >
> > and it seems a bit more "sane" than your configuration.
>
> Yours is using LVM, which I wanted to avoid. That may be the root of
> the issue (though I've no idea why).
>
> poc
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
2:16 p.m.
On 2020-05-24 23:43, Patrick O'Callaghan wrote:
On Sun, 2020-05-24 at 21:14 +0800, Ed Greshko wrote:
> On 2020-05-24 19:37, Patrick O'Callaghan wrote:
>> Still getting the hang of md. I had it working for several days (2
>> disks in RAID1 config) but after a system update and reboot, it
>> suddenly shows no data:
>>
>> ]# lsblk
>> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
>> [...]
>> sdd 8:48 0 931.5G 0 disk
>> └─md127 9:127 0 931.4G 0 raid1
>> └─md127p1 259:0 0 931.4G 0 part
>> sde 8:64 0 931.5G 0 disk
>> └─md127 9:127 0 931.4G 0 raid1
>> └─md127p1 259:0 0 931.4G 0 part
> FWIW, I just created a RAID1 on a VM in the "standard" way and I see....
>
> [egreshko@f31k ~]$ sudo lsblk
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> sda 8:0 0 50G 0 disk
> └─md0 9:0 0 50G 0 raid1
> sdb 8:16 0 50G 0 disk
> └─md0 9:0 0 50G 0 raid1
> sr0 11:0 1 1024M 0 rom
> vda 252:0 0 30G 0 disk
> ├─vda1 252:1 0 1G 0 part /boot
> └─vda2 252:2 0 29G 0 part
> ├─fedora_f31k-root 253:0 0 27G 0 lvm /
> └─fedora_f31k-swap 253:1 0 2.1G 0 lvm [SWAP]
>
> and it seems a bit more "sane" than your configuration.
Yours is using LVM, which I wanted to avoid. That may be the root of
the issue (though I've no idea why).
?????
The RAID Array isn't using LVM.
This is just an added pair of disks, with RAID.
--
The key to getting good answers is to ask good questions.
4:20 p.m.
On Mon, 2020-05-25 at 03:16 +0800, Ed Greshko wrote:
> > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> > sda 8:0 0 50G 0 disk
> > └─md0 9:0 0 50G 0 raid1
> > sdb 8:16 0 50G 0 disk
> > └─md0 9:0 0 50G 0 raid1
> > sr0 11:0 1 1024M 0 rom
> > vda 252:0 0 30G 0 disk
> > ├─vda1 252:1 0 1G 0 part /boot
> > └─vda2 252:2 0 29G 0 part
> > ├─fedora_f31k-root 253:0 0 27G 0 lvm /
> > └─fedora_f31k-swap 253:1 0 2.1G 0 lvm [SWAP]
> > and it seems a bit more "sane" than your configuration.
> Yours is using LVM, which I wanted to avoid. That may be the root of
> the issue (though I've no idea why).
?????
The RAID Array isn't using LVM.
This is just an added pair of disks, with RAID.
Oops, I was looking at the vda[12] rather than sd[ab]
poc
4:34 p.m.
On 2020-05-25 05:20, Patrick O'Callaghan wrote:
On Mon, 2020-05-25 at 03:16 +0800, Ed Greshko wrote:
>>> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
>>> sda 8:0 0 50G 0 disk
>>> └─md0 9:0 0 50G 0 raid1
>>> sdb 8:16 0 50G 0 disk
>>> └─md0 9:0 0 50G 0 raid1
>>> sr0 11:0 1 1024M 0 rom
>>> vda 252:0 0 30G 0 disk
>>> ├─vda1 252:1 0 1G 0 part /boot
>>> └─vda2 252:2 0 29G 0 part
>>> ├─fedora_f31k-root 253:0 0 27G 0 lvm /
>>> └─fedora_f31k-swap 253:1 0 2.1G 0 lvm [SWAP]
>>> and it seems a bit more "sane" than your configuration.
>> Yours is using LVM, which I wanted to avoid. That may be the root of
>> the issue (though I've no idea why).
>
> ?????
>
>
>
> The RAID Array isn't using LVM.
>
>
>
> This is just an added pair of disks, with RAID.
Oops, I was looking at the vda[12] rather than sd[ab]
OK. All things being equal, if I were in your shoes I'd go back and redo the RAID
creation.
When the "mdadm --create" is performed and mirroring of the drives begins the
array can still
be used. You can proceed with mkfs on it simultaneous.
--
The key to getting good answers is to ask good questions.
5:39 p.m.
On Mon, 2020-05-25 at 05:34 +0800, Ed Greshko wrote:
On 2020-05-25 05:20, Patrick O'Callaghan wrote:
> On Mon, 2020-05-25 at 03:16 +0800, Ed Greshko wrote:
> > > > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> > > > sda 8:0 0 50G 0 disk
> > > > └─md0 9:0 0 50G 0 raid1
> > > > sdb 8:16 0 50G 0 disk
> > > > └─md0 9:0 0 50G 0 raid1
> > > > sr0 11:0 1 1024M 0 rom
> > > > vda 252:0 0 30G 0 disk
> > > > ├─vda1 252:1 0 1G 0 part /boot
> > > > └─vda2 252:2 0 29G 0 part
> > > > ├─fedora_f31k-root 253:0 0 27G 0 lvm /
> > > > └─fedora_f31k-swap 253:1 0 2.1G 0 lvm [SWAP]
> > > > and it seems a bit more "sane" than your configuration.
> > > Yours is using LVM, which I wanted to avoid. That may be the root of
> > > the issue (though I've no idea why).
> >
> > ?????
> >
> >
> >
> > The RAID Array isn't using LVM.
> >
> >
> >
> > This is just an added pair of disks, with RAID.
> Oops, I was looking at the vda[12] rather than sd[ab]
OK. All things being equal, if I were in your shoes I'd go back and redo the RAID
creation.
When the "mdadm --create" is performed and mirroring of the drives begins the
array can still
be used. You can proceed with mkfs on it simultaneous.
OK, I did this:
# mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sd[de]
mdadm: /dev/sdd appears to be part of a raid array:
level=raid1 devices=2 ctime=Wed May 20 16:34:58 2020
mdadm: partition table exists on /dev/sdd but will be lost or
meaningless after creating array
mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to
store '/boot' on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
--metadata=0.90
mdadm: /dev/sde appears to be part of a raid array:
level=raid1 devices=2 ctime=Wed May 20 16:34:58 2020
mdadm: partition table exists on /dev/sde but will be lost or
meaningless after creating array
Continue creating array? y
mdadm: Fail create md0 when using /sys/module/md_mod/parameters/new_array
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
And now I find:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
[...]
sdd 8:48 0 931.5G 0 disk
└─md0 9:0 0 931.4G 0 raid1
└─md0p1 259:0 0 931.4G 0 part
/run/media/poc/6cb66da2-147a-4f3c-a513-36f6164ab581
sde 8:64 0 931.5G 0 disk
└─md0 9:0 0 931.4G 0 raid1
└─md0p1 259:0 0 931.4G 0 part
/run/media/poc/6cb66da2-147a-4f3c-a513-36f6164ab581
So although the above message says the existing partition table will be
lost, for some reason I'm still getting a partition, while you
apparently didn't. I copied the --create command directly from the man
page. Is this not the "standard" way you mentioned in an earlier reply?
Finally, the /run/media/... etc. mounts now show my existing data. All
the same, the disk lights are busy and I expect them to be going all
night.
poc
6:07 p.m.
Did you originally have /dev/md0p1 in fstab and you have edited fstab
since you booted?
If so the great and amazing systemd will not be amused and will still
have a job for the old device, you will need to run systemctl
daemon-reload for it to read the fstab file as it is not smart enough
to do that itself.
On Sun, May 24, 2020 at 5:44 PM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
>
> On Mon, 2020-05-25 at 05:34 +0800, Ed Greshko wrote:
> > On 2020-05-25 05:20, Patrick O'Callaghan wrote:
> > > On Mon, 2020-05-25 at 03:16 +0800, Ed Greshko wrote:
> > > > > > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> > > > > > sda 8:0 0 50G 0 disk
> > > > > > └─md0 9:0 0 50G 0 raid1
> > > > > > sdb 8:16 0 50G 0 disk
> > > > > > └─md0 9:0 0 50G 0 raid1
> > > > > > sr0 11:0 1 1024M 0 rom
> > > > > > vda 252:0 0 30G 0 disk
> > > > > > ├─vda1 252:1 0 1G 0 part /boot
> > > > > > └─vda2 252:2 0 29G 0 part
> > > > > > ├─fedora_f31k-root 253:0 0 27G 0 lvm /
> > > > > > └─fedora_f31k-swap 253:1 0 2.1G 0 lvm [SWAP]
> > > > > > and it seems a bit more "sane" than your
configuration.
> > > > > Yours is using LVM, which I wanted to avoid. That may be the root
of
> > > > > the issue (though I've no idea why).
> > > >
> > > > ?????
> > > >
> > > >
> > > >
> > > > The RAID Array isn't using LVM.
> > > >
> > > >
> > > >
> > > > This is just an added pair of disks, with RAID.
> > > Oops, I was looking at the vda[12] rather than sd[ab]
> >
> > OK. All things being equal, if I were in your shoes I'd go back and redo
the RAID creation.
> >
> > When the "mdadm --create" is performed and mirroring of the drives
begins the array can still
> > be used. You can proceed with mkfs on it simultaneous.
>
> OK, I did this:
>
> # mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sd[de]
> mdadm: /dev/sdd appears to be part of a raid array:
> level=raid1 devices=2 ctime=Wed May 20 16:34:58 2020
> mdadm: partition table exists on /dev/sdd but will be lost or
> meaningless after creating array
> mdadm: Note: this array has metadata at the start and
> may not be suitable as a boot device. If you plan to
> store '/boot' on this device please ensure that
> your boot-loader understands md/v1.x metadata, or use
> --metadata=0.90
> mdadm: /dev/sde appears to be part of a raid array:
> level=raid1 devices=2 ctime=Wed May 20 16:34:58 2020
> mdadm: partition table exists on /dev/sde but will be lost or
> meaningless after creating array
> Continue creating array? y
> mdadm: Fail create md0 when using /sys/module/md_mod/parameters/new_array
> mdadm: Defaulting to version 1.2 metadata
> mdadm: array /dev/md0 started.
>
> And now I find:
> # lsblk
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> [...]
> sdd 8:48 0 931.5G 0 disk
> └─md0 9:0 0 931.4G 0 raid1
> └─md0p1 259:0 0 931.4G 0 part
/run/media/poc/6cb66da2-147a-4f3c-a513-36f6164ab581
> sde 8:64 0 931.5G 0 disk
> └─md0 9:0 0 931.4G 0 raid1
> └─md0p1 259:0 0 931.4G 0 part
/run/media/poc/6cb66da2-147a-4f3c-a513-36f6164ab581
>
> So although the above message says the existing partition table will be
> lost, for some reason I'm still getting a partition, while you
> apparently didn't. I copied the --create command directly from the man
> page. Is this not the "standard" way you mentioned in an earlier reply?
>
> Finally, the /run/media/... etc. mounts now show my existing data. All
> the same, the disk lights are busy and I expect them to be going all
> night.
>
> poc
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
4:29 a.m.
On Sun, 2020-05-24 at 18:07 -0500, Roger Heflin wrote:
Did you originally have /dev/md0p1 in fstab and you have edited
fstab
since you booted?
If so the great and amazing systemd will not be amused and will still
have a job for the old device, you will need to run systemctl
daemon-reload for it to read the fstab file as it is not smart enough
to do that itself.
That's ... illuminating ... I haven't come across this behaviour
before, but I now see that there is a warning to that effect in
/etc/fstab (which of course I've never noticed before now). It could
explain some of what's happened. I wonder why systemd doesn't notice
that the file has changed and reload accordingly.
poc
7:24 a.m.
On Mon, May 25, 2020, 3:29 AM Patrick O'Callaghan <pocallaghan(a)gmail.com wrote:
I wonder why systemd doesn't notice
that the file has changed and reload accordingly.
The obvious as stupid answer is because it is not designed to work that
way. The process is actually documented; see for example
systemd-fstab-generator(8).
I would guess that keeping an eye on dozens of config files to see if any
of them have changed would use a lot of system resources over time, but I
expect there are more serious and less obvious reasons why this is not done.
In fairness to systemd, it has never been possible to edit /etc/fstab and
have your changes automatically applied. It has always been necessary to
run some sort of mount command (or reboot) after modifying fstab.
--Greg
7:49 a.m.
His issue was he did the manual mount on /raid (already in fstab with
a different device) and systemd immediately unmounted it. The mount
succeeds with no error, and the umount happens so fast you are left
confused about what is going on. It did at least note it in
messages so long as you can guess the stupid action it took. This
action of systemd is pretty badly designed, since it is overriding
what had to be someone/somethings explicit action (and even if this is
documented, documenting stupidity does not make it "right", it is
still wrong).
On Mon, May 25, 2020 at 7:25 AM Greg Woods <greg(a)gregandeva.net> wrote:
>
>
>
> On Mon, May 25, 2020, 3:29 AM Patrick O'Callaghan <pocallaghan(a)gmail.com>
wrote:
>>
>> I wonder why systemd doesn't notice
>> that the file has changed and reload accordingly.
>
>
> The obvious as stupid answer is because it is not designed to work that way. The
process is actually documented; see for example systemd-fstab-generator(8).
>
> I would guess that keeping an eye on dozens of config files to see if any of them
have changed would use a lot of system resources over time, but I expect there are more
serious and less obvious reasons why this is not done.
>
> In fairness to systemd, it has never been possible to edit /etc/fstab and have your
changes automatically applied. It has always been necessary to run some sort of mount
command (or reboot) after modifying fstab.
>
> --Greg
>
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
11:24 a.m.
New subject: Raid array empty after restart - SOLVED
On Mon, 2020-05-25 at 07:49 -0500, Roger Heflin wrote:
His issue was he did the manual mount on /raid (already in fstab
with
a different device) and systemd immediately unmounted it. The mount
succeeds with no error, and the umount happens so fast you are left
confused about what is going on. It did at least note it in
messages so long as you can guess the stupid action it took. This
action of systemd is pretty badly designed, since it is overriding
what had to be someone/somethings explicit action (and even if this is
documented, documenting stupidity does not make it "right", it is
still wrong).
I *think* I've got it now. Re-creating the array made no difference
whatever, as it just left everything exactly the same apart from taking
many hours in useless resynching (why it does this is a mystery, as it
clearly knows the layout and should know that the array was already
synchronised). IOW even though I ran:
# mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sd[de]
I still ended up with /dev/md127p1 as before, and /dev/md0 wa's not
created. However by putting that into /etc/fstab and running systemctl
daemon-reload', I can now mount the array correctly. It even survives a
system reboot.
Fingers crossed, it seems to be working now.
poc
4:42 p.m.
New subject: Raid array empty after restart - SOLVED
On 2020-05-26 00:24, Patrick O'Callaghan wrote:
I still ended up with /dev/md127p1 as before, and /dev/md0 wa's
not
created.
I didn't think you would. As I mentioned in another post, you didn't start out
with a "fresh" drive. It already
had info on it that mdadm had created and then just reused. If you wanted to do a really
new set-up
you would have had to done something like "dd if=/dev/zero of=" to both of the
physical drives.
--
The key to getting good answers is to ask good questions.
5:23 p.m.
New subject: Raid array empty after restart - SOLVED
On Tue, 2020-05-26 at 05:42 +0800, Ed Greshko wrote:
On 2020-05-26 00:24, Patrick O'Callaghan wrote:
> I still ended up with /dev/md127p1 as before, and /dev/md0 wa's not
> created.
I didn't think you would. As I mentioned in another post, you didn't start out
with a "fresh" drive. It already
had info on it that mdadm had created and then just reused. If you wanted to do a really
new set-up
you would have had to done something like "dd if=/dev/zero of=" to both of the
physical drives.
Yes, I understand that. I still think the behaviour of mdadm in this
case is counter-intuitive. When I explicitly ask for the creation of an
array called /dev/md0 and the command first of all warns me that this
will (not "may") destroy the existing partition table and do I want to
proceed, then when I say yes apparently succeeds, I think I'm entitled
to think that /dev/md0 has been created, but it hasn't.
poc
11:22 p.m.
New subject: Raid array empty after restart - SOLVED
On 5/25/20 5:23 PM, Patrick O'Callaghan wrote:
Yes, I understand that. I still think the behaviour of mdadm in this
case is counter-intuitive. When I explicitly ask for the creation of an
array called /dev/md0 and the command first of all warns me that this
will (not "may") destroy the existing partition table and do I want to
proceed, then when I say yes apparently succeeds, I think I'm entitled
to think that /dev/md0 has been created, but it hasn't.
remember /dev is created at linux boot so the devices names are dynamic
(/dev/mdN)
if you want give a name to the array and a device name under /dev/md
something like:
mdadm --create /dev/md/var-even --raid-devices=2 --level=1
--name=var-even /dev/sd[ab]12
the above command uses partition number 12 type fd00 on /dev/sd[ab]
and format with:
mkfs.ext4 -L 'var-even' /dev/md/var-even
to prevent name collisions (if you mount the disk in another computer
with identical setup) find the partition uuid with:
ls -lht /dev/md/var-even
lrwxrwxrwx. 1 root root 8 May 20 21:48 /dev/md/var-even -> ../md121
and find the uuid pointing to md121 with:
ls -lht /dev/disk/by-uuid/
...
lrwxrwxrwx. 1 root root 11 May 20 21:48
2108ba12-2ee3-5067-8de4-01c454867c5a -> ../../md121
...
and use that uuid in fstab.
Gabriel
6:15 a.m.
New subject: Raid array empty after restart - SOLVED
On Mon, 2020-05-25 at 23:22 -0500, Gabriel Ramirez wrote:
On 5/25/20 5:23 PM, Patrick O'Callaghan wrote:
> Yes, I understand that. I still think the behaviour of mdadm in this
> case is counter-intuitive. When I explicitly ask for the creation of an
> array called /dev/md0 and the command first of all warns me that this
> will (not "may") destroy the existing partition table and do I want to
> proceed, then when I say yes apparently succeeds, I think I'm entitled
> to think that /dev/md0 has been created, but it hasn't.
remember /dev is created at linux boot so the devices names are dynamic
(/dev/mdN)
Yes, that's true. However I'm talking about immediately after doing the
array creation. If /dev/md0 is not a valid name because it will be
destroyed on reboot, shouldn't mdadm warn me?
if you want give a name to the array and a device name under /dev/md
something like:
mdadm --create /dev/md/var-even --raid-devices=2 --level=1
--name=var-even /dev/sd[ab]12
the above command uses partition number 12 type fd00 on /dev/sd[ab]
and format with:
mkfs.ext4 -L 'var-even' /dev/md/var-even
to prevent name collisions (if you mount the disk in another computer
with identical setup) find the partition uuid with:
ls -lht /dev/md/var-even
lrwxrwxrwx. 1 root root 8 May 20 21:48 /dev/md/var-even -> ../md121
and find the uuid pointing to md121 with:
ls -lht /dev/disk/by-uuid/
...
lrwxrwxrwx. 1 root root 11 May 20 21:48
2108ba12-2ee3-5067-8de4-01c454867c5a -> ../../md121
...
and use that uuid in fstab.
Thanks. I'll bear that in mind if the existing /dev/md127p1 suddenly
disappears.
poc
9:32 a.m.
New subject: Raid array empty after restart - SOLVED
If you want the name to stay the same then create a file in
/etc/mdadm.conf with something like this in it:
# mdadm.conf written out by anaconda
MAILADDR root
AUTO +imsm +1.x -all
ARRAY /dev/md13 metadata=1.2 level=raid6 num-devices=7
name=localhost.localdomain:11 UUID=a54550f7:da200f3e:90606715:06691490
POLICY domain=all action=re-add
On Tue, May 26, 2020 at 6:16 AM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
>
> On Mon, 2020-05-25 at 23:22 -0500, Gabriel Ramirez wrote:
> > On 5/25/20 5:23 PM, Patrick O'Callaghan wrote:
> > > Yes, I understand that. I still think the behaviour of mdadm in this
> > > case is counter-intuitive. When I explicitly ask for the creation of an
> > > array called /dev/md0 and the command first of all warns me that this
> > > will (not "may") destroy the existing partition table and do I
want to
> > > proceed, then when I say yes apparently succeeds, I think I'm entitled
> > > to think that /dev/md0 has been created, but it hasn't.
> >
> > remember /dev is created at linux boot so the devices names are dynamic
> > (/dev/mdN)
>
> Yes, that's true. However I'm talking about immediately after doing the
> array creation. If /dev/md0 is not a valid name because it will be
> destroyed on reboot, shouldn't mdadm warn me?
>
> > if you want give a name to the array and a device name under /dev/md
> > something like:
> >
> > mdadm --create /dev/md/var-even --raid-devices=2 --level=1
> > --name=var-even /dev/sd[ab]12
> >
> > the above command uses partition number 12 type fd00 on /dev/sd[ab]
> >
> > and format with:
> >
> > mkfs.ext4 -L 'var-even' /dev/md/var-even
> >
> > to prevent name collisions (if you mount the disk in another computer
> > with identical setup) find the partition uuid with:
> >
> > ls -lht /dev/md/var-even
> > lrwxrwxrwx. 1 root root 8 May 20 21:48 /dev/md/var-even -> ../md121
> >
> > and find the uuid pointing to md121 with:
> >
> > ls -lht /dev/disk/by-uuid/
> >
> > ...
> >
> > lrwxrwxrwx. 1 root root 11 May 20 21:48
> > 2108ba12-2ee3-5067-8de4-01c454867c5a -> ../../md121
> >
> > ...
> >
> > and use that uuid in fstab.
>
> Thanks. I'll bear that in mind if the existing /dev/md127p1 suddenly
> disappears.
>
> poc
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
11 a.m.
New subject: Raid array empty after restart - SOLVED
On Tue, 2020-05-26 at 09:32 -0500, Roger Heflin wrote:
If you want the name to stay the same then create a file in
/etc/mdadm.conf with something like this in it:
# mdadm.conf written out by anaconda
MAILADDR root
AUTO +imsm +1.x -all
ARRAY /dev/md13 metadata=1.2 level=raid6 num-devices=7
name=localhost.localdomain:11 UUID=a54550f7:da200f3e:90606715:06691490
POLICY domain=all action=re-add
Thanks.
poc
1:07 p.m.
New subject: Raid array empty after restart - SOLVED
On 5/26/20 4:15 AM, Patrick O'Callaghan wrote:
On Mon, 2020-05-25 at 23:22 -0500, Gabriel Ramirez wrote:
> On 5/25/20 5:23 PM, Patrick O'Callaghan wrote:
>> Yes, I understand that. I still think the behaviour of mdadm in this
>> case is counter-intuitive. When I explicitly ask for the creation of an
>> array called /dev/md0 and the command first of all warns me that this
>> will (not "may") destroy the existing partition table and do I want to
>> proceed, then when I say yes apparently succeeds, I think I'm entitled
>> to think that /dev/md0 has been created, but it hasn't.
>
> remember /dev is created at linux boot so the devices names are dynamic
> (/dev/mdN)
Yes, that's true. However I'm talking about immediately after doing the
array creation. If /dev/md0 is not a valid name because it will be
destroyed on reboot, shouldn't mdadm warn me?
I think there's a suggested number in the raid metadata, but it's not
necessarily used. What would happen if you added two raid arrays with
the same number?
If you run "mdadm -E /dev/sdh1" where "sdh1" is a raid member, you can
see the metadata. There's a line with "Name : hostname:0" and I think
the ":0" part is the md number. But this raid array is actually at
md127. I have another one with :126 which is at md126.
However, you shouldn't be using /dev/md* in your fstab anyway, you
should be using the filesystem UUID.
4:18 p.m.
New subject: Raid array empty after restart - SOLVED
On Tue, 2020-05-26 at 11:07 -0700, Samuel Sieb wrote:
On 5/26/20 4:15 AM, Patrick O'Callaghan wrote:
> On Mon, 2020-05-25 at 23:22 -0500, Gabriel Ramirez wrote:
> > On 5/25/20 5:23 PM, Patrick O'Callaghan wrote:
> > > Yes, I understand that. I still think the behaviour of mdadm in this
> > > case is counter-intuitive. When I explicitly ask for the creation of an
> > > array called /dev/md0 and the command first of all warns me that this
> > > will (not "may") destroy the existing partition table and do I
want to
> > > proceed, then when I say yes apparently succeeds, I think I'm
entitled
> > > to think that /dev/md0 has been created, but it hasn't.
> >
> > remember /dev is created at linux boot so the devices names are dynamic
> > (/dev/mdN)
>
> Yes, that's true. However I'm talking about immediately after doing the
> array creation. If /dev/md0 is not a valid name because it will be
> destroyed on reboot, shouldn't mdadm warn me?
I think there's a suggested number in the raid metadata, but it's not
necessarily used. What would happen if you added two raid arrays with
the same number?
If you run "mdadm -E /dev/sdh1" where "sdh1" is a raid member, you
can
see the metadata. There's a line with "Name : hostname:0" and I think
the ":0" part is the md number. But this raid array is actually at
md127. I have another one with :126 which is at md126.
However, you shouldn't be using /dev/md* in your fstab anyway, you
should be using the filesystem UUID.
I'm doing that now in fact, and it seems to be stable.
poc
10:24 a.m.
On Mon, 2020-05-25 at 06:24 -0600, Greg Woods wrote:
I would guess that keeping an eye on dozens of config files to see
if
any of them have changed would use a lot of system resources over
time, but I expect there are more serious and less obvious reasons
why this is not done.
On a gigaHertz PC with gigabytes of RAM?
--
uname -rsvp
Linux 3.10.0-1127.8.2.el7.x86_64 #1 SMP Tue May 12 16:57:42 UTC 2020 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
11:31 a.m.
On Mon, 2020-05-25 at 06:24 -0600, Greg Woods wrote:
In fairness to systemd, it has never been possible to edit /etc/fstab
and
have your changes automatically applied. It has always been necessary to
run some sort of mount command (or reboot) after modifying fstab.
Which is what I thought I was doing:
* Modify /etc/fstab
* Run mount
* Mount doesn't give an error, but doesn't mount the correct
filesystem.
Requiring the systemctl-reload is a significant departure from
traditional semantics. I understand that it's been around for a while,
but it's nonetheless disconcerting to find that something so basic and
well-understood has changed.
Surely the mount command could notice that /etc/fstab had changed since
systemd last read it and poke it to do the reload?
poc
7:24 a.m.
I had a bug submitted on a RHEL contract 2-3 years ago about it. I
get emails each quarter saying they are still evaluating it. I am not
holding my breath.
The reload could have bad effects since it might shuffle things around
if fstab changed that really only could happen on a reboot, the only
real solution I saw was that once it is clear someone/something else
mounted something remove the systemd rule for the mount that it
happened to.
On Mon, May 25, 2020 at 4:29 AM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
>
> On Sun, 2020-05-24 at 18:07 -0500, Roger Heflin wrote:
> > Did you originally have /dev/md0p1 in fstab and you have edited fstab
> >
> > since you booted?
> >
> >
> >
> > If so the great and amazing systemd will not be amused and will still
> >
> > have a job for the old device, you will need to run systemctl
> >
> > daemon-reload for it to read the fstab file as it is not smart enough
> >
> > to do that itself.
>
> That's ... illuminating ... I haven't come across this behaviour
> before, but I now see that there is a warning to that effect in
> /etc/fstab (which of course I've never noticed before now). It could
> explain some of what's happened. I wonder why systemd doesn't notice
> that the file has changed and reload accordingly.
>
> poc
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
6:09 p.m.
On 2020-05-25 06:39, Patrick O'Callaghan wrote:
On Mon, 2020-05-25 at 05:34 +0800, Ed Greshko wrote:
> On 2020-05-25 05:20, Patrick O'Callaghan wrote:
>> On Mon, 2020-05-25 at 03:16 +0800, Ed Greshko wrote:
>>>>> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
>>>>> sda 8:0 0 50G 0 disk
>>>>> └─md0 9:0 0 50G 0 raid1
>>>>> sdb 8:16 0 50G 0 disk
>>>>> └─md0 9:0 0 50G 0 raid1
>>>>> sr0 11:0 1 1024M 0 rom
>>>>> vda 252:0 0 30G 0 disk
>>>>> ├─vda1 252:1 0 1G 0 part /boot
>>>>> └─vda2 252:2 0 29G 0 part
>>>>> ├─fedora_f31k-root 253:0 0 27G 0 lvm /
>>>>> └─fedora_f31k-swap 253:1 0 2.1G 0 lvm [SWAP]
>>>>> and it seems a bit more "sane" than your configuration.
>>>> Yours is using LVM, which I wanted to avoid. That may be the root of
>>>> the issue (though I've no idea why).
>>> ?????
>>>
>>>
>>>
>>> The RAID Array isn't using LVM.
>>>
>>>
>>>
>>> This is just an added pair of disks, with RAID.
>> Oops, I was looking at the vda[12] rather than sd[ab]
> OK. All things being equal, if I were in your shoes I'd go back and redo the
RAID creation.
>
> When the "mdadm --create" is performed and mirroring of the drives begins
the array can still
> be used. You can proceed with mkfs on it simultaneous.
OK, I did this:
# mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sd[de]
mdadm: /dev/sdd appears to be part of a raid array:
level=raid1 devices=2 ctime=Wed May 20 16:34:58 2020
mdadm: partition table exists on /dev/sdd but will be lost or
meaningless after creating array
mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to
store '/boot' on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
--metadata=0.90
mdadm: /dev/sde appears to be part of a raid array:
level=raid1 devices=2 ctime=Wed May 20 16:34:58 2020
mdadm: partition table exists on /dev/sde but will be lost or
meaningless after creating array
Continue creating array? y
mdadm: Fail create md0 when using /sys/module/md_mod/parameters/new_array
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
And now I find:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
[...]
sdd 8:48 0 931.5G 0 disk
└─md0 9:0 0 931.4G 0 raid1
└─md0p1 259:0 0 931.4G 0 part
/run/media/poc/6cb66da2-147a-4f3c-a513-36f6164ab581
sde 8:64 0 931.5G 0 disk
└─md0 9:0 0 931.4G 0 raid1
└─md0p1 259:0 0 931.4G 0 part
/run/media/poc/6cb66da2-147a-4f3c-a513-36f6164ab581
So although the above message says the existing partition table will be
lost, for some reason I'm still getting a partition, while you
apparently didn't. I copied the --create command directly from the man
page. Is this not the "standard" way you mentioned in an earlier reply?
Finally, the /run/media/... etc. mounts now show my existing data. All
the same, the disk lights are busy and I expect them to be going all
night.
Well, I had 2 totally clean disks to start with.
I see I should not have used the word "redo". What I was meaning to convey is
that I'd destroy
the existing ARRAY and start all over again.
I did...
mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda /dev/sdb
followed by
mkfs.ext4 -F /dev/md0
--
The key to getting good answers is to ask good questions.
6:22 p.m.
On 5/24/20 3:39 PM, Patrick O'Callaghan wrote:
So although the above message says the existing partition table will
be
lost, for some reason I'm still getting a partition, while you
apparently didn't. I copied the --create command directly from the man
page. Is this not the "standard" way you mentioned in an earlier reply?
That message is a little misleading. What happened was you created an
array out of disks with existing data on them. Only the superblock gets
rewritten, the rest of the drive just gets resynced, not erased. So
your existing partition table is still there.
Finally, the /run/media/... etc. mounts now show my existing data.
All
the same, the disk lights are busy and I expect them to be going all
night.
Yes, all the data that was on it before is still there and it's going to
do a full resync again like it did the first time you created the array.
The partition was detected by udev and your desktop environment
auto-mounted it for you.
4:25 a.m.
On Sun, 2020-05-24 at 16:22 -0700, Samuel Sieb wrote:
On 5/24/20 3:39 PM, Patrick O'Callaghan wrote:
> So although the above message says the existing partition table will be
> lost, for some reason I'm still getting a partition, while you
> apparently didn't. I copied the --create command directly from the man
> page. Is this not the "standard" way you mentioned in an earlier reply?
That message is a little misleading. What happened was you created an
array out of disks with existing data on them. Only the superblock gets
rewritten, the rest of the drive just gets resynced, not erased. So
your existing partition table is still there.
More than a little misleading. I'd call the message downright wrong.
I'll consider reporting it to BZ.
poc
1:03 p.m.
On 5/25/20 2:25 AM, Patrick O'Callaghan wrote:
On Sun, 2020-05-24 at 16:22 -0700, Samuel Sieb wrote:
> On 5/24/20 3:39 PM, Patrick O'Callaghan wrote:
>
>> So although the above message says the existing partition table will be
>> lost, for some reason I'm still getting a partition, while you
>> apparently didn't. I copied the --create command directly from the man
>> page. Is this not the "standard" way you mentioned in an earlier
reply?
>
>
> That message is a little misleading. What happened was you created an
>
> array out of disks with existing data on them. Only the superblock gets
>
> rewritten, the rest of the drive just gets resynced, not erased. So
>
> your existing partition table is still there.
More than a little misleading. I'd call the message downright wrong.
I'll consider reporting it to BZ.
It depends on which drive has the partition table and which drive gets
cloned to. For example, you have one blank drive and one with a
partition table. If the blank one get cloned to the other, then the
partition table gets wiped out. If it goes the other way, then your
raid has a partition table. But even in that case, depending on where
the raid metadata goes and other factors, it could mess up the table or
have it point to the wrong place. It's best to just assume that the
partition table will be invalid even if it appears to still be there.
Unless you're really sure about what you're doing, you should always
reinitialize a newly created raid array, not trusting the existing data.
4:22 p.m.
On Mon, 2020-05-25 at 11:03 -0700, Samuel Sieb wrote:
On 5/25/20 2:25 AM, Patrick O'Callaghan wrote:
> On Sun, 2020-05-24 at 16:22 -0700, Samuel Sieb wrote:
> > On 5/24/20 3:39 PM, Patrick O'Callaghan wrote:
> >
> > > So although the above message says the existing partition table will be
> > > lost, for some reason I'm still getting a partition, while you
> > > apparently didn't. I copied the --create command directly from the
man
> > > page. Is this not the "standard" way you mentioned in an earlier
reply?
> >
> > That message is a little misleading. What happened was you created an
> >
> > array out of disks with existing data on them. Only the superblock gets
> >
> > rewritten, the rest of the drive just gets resynced, not erased. So
> >
> > your existing partition table is still there.
>
> More than a little misleading. I'd call the message downright wrong.
> I'll consider reporting it to BZ.
It depends on which drive has the partition table and which drive gets
cloned to. For example, you have one blank drive and one with a
partition table. If the blank one get cloned to the other, then the
partition table gets wiped out. If it goes the other way, then your
raid has a partition table. But even in that case, depending on where
the raid metadata goes and other factors, it could mess up the table or
have it point to the wrong place. It's best to just assume that the
partition table will be invalid even if it appears to still be there.
Unless you're really sure about what you're doing, you should always
reinitialize a newly created raid array, not trusting the existing data.
That decision was taken by mdadm without input from me, i.e. it's the
default. I see there is an "--assume-clean" option which would possibly
have skipped that step, though the man page doesn't recommend it unless
you know what you're doing, which I clearly don't. All the same, saying
"the partition table *will* be lost or meaningless after creating
array" is certainly wrong.
poc
5:43 p.m.
On 5/25/20 2:22 PM, Patrick O'Callaghan wrote:
On Mon, 2020-05-25 at 11:03 -0700, Samuel Sieb wrote:
> On 5/25/20 2:25 AM, Patrick O'Callaghan wrote:
>> On Sun, 2020-05-24 at 16:22 -0700, Samuel Sieb wrote:
>>> On 5/24/20 3:39 PM, Patrick O'Callaghan wrote:
>>>
>>>> So although the above message says the existing partition table will be
>>>> lost, for some reason I'm still getting a partition, while you
>>>> apparently didn't. I copied the --create command directly from the
man
>>>> page. Is this not the "standard" way you mentioned in an
earlier reply?
>>>
>>> That message is a little misleading. What happened was you created an
>>>
>>> array out of disks with existing data on them. Only the superblock gets
>>>
>>> rewritten, the rest of the drive just gets resynced, not erased. So
>>>
>>> your existing partition table is still there.
>>
>> More than a little misleading. I'd call the message downright wrong.
>> I'll consider reporting it to BZ.
>
> It depends on which drive has the partition table and which drive gets
> cloned to. For example, you have one blank drive and one with a
> partition table. If the blank one get cloned to the other, then the
> partition table gets wiped out. If it goes the other way, then your
> raid has a partition table. But even in that case, depending on where
> the raid metadata goes and other factors, it could mess up the table or
> have it point to the wrong place. It's best to just assume that the
> partition table will be invalid even if it appears to still be there.
> Unless you're really sure about what you're doing, you should always
> reinitialize a newly created raid array, not trusting the existing data.
That decision was taken by mdadm without input from me, i.e. it's the
default. I see there is an "--assume-clean" option which would possibly
have skipped that step, though the man page doesn't recommend it unless
you know what you're doing, which I clearly don't. All the same, saying
"the partition table *will* be lost or meaningless after creating
array" is certainly wrong.
It's not wrong. You were in a very special case where you are
recreating the same raid from two drives that were in exactly the same
configuration. In any other case, the partition table would be
overwritten or would be invalid. You probably could have even used the
"--assume-clean" option to avoid the resync.
6:09 a.m.
On Mon, 2020-05-25 at 15:43 -0700, Samuel Sieb wrote:
> That decision was taken by mdadm without input from me, i.e.
it's the
> default. I see there is an "--assume-clean" option which would possibly
> have skipped that step, though the man page doesn't recommend it unless
> you know what you're doing, which I clearly don't. All the same, saying
> "the partition table *will* be lost or meaningless after creating
> array" is certainly wrong.
It's not wrong. You were in a very special case where you are
recreating the same raid from two drives that were in exactly the same
configuration. In any other case, the partition table would be
overwritten or would be invalid. You probably could have even used the
"--assume-clean" option to avoid the resync.
Certainly it's a special case, but the message is still wrong to state
that something will happen when it won't. As I said, mdadm has detected
the existence of an array, and knows (or can easily discover) what its
parameters are, and therefore know that the new creation will not
change them.
poc
8:18 a.m.
On 2020-05-24 19:37, Patrick O'Callaghan wrote:
Still getting the hang of md. I had it working for several days (2
disks in RAID1 config) but after a system update and reboot, it
suddenly shows no data:
Oh, you did make a /etc/mdadm.conf?
--
The key to getting good answers is to ask good questions.
10:41 a.m.
On Sun, 2020-05-24 at 21:18 +0800, Ed Greshko wrote:
On 2020-05-24 19:37, Patrick O'Callaghan wrote:
> Still getting the hang of md. I had it working for several days (2
> disks in RAID1 config) but after a system update and reboot, it
> suddenly shows no data:
Oh, you did make a /etc/mdadm.conf?
No, I assumed the defaults would be reasonable.
poc
8:40 a.m.
On 2020-05-24 21:37, Patrick O'Callaghan wrote:
Still getting the hang of md. I had it working for several days (2
disks in RAID1 config) but after a system update and reboot, it
A system update or a system upgrade?
suddenly shows no data:
]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
[...]
sdd 8:48 0 931.5G 0 disk
└─md127 9:127 0 931.4G 0 raid1
└─md127p1 259:0 0 931.4G 0 part
sde 8:64 0 931.5G 0 disk
└─md127 9:127 0 931.4G 0 raid1
└─md127p1 259:0 0 931.4G 0 part
# mdadm --detail /dev/md127p1
/dev/md127p1:
Version : 1.2
Creation Time : Wed May 20 16:34:58 2020
Raid Level : raid1
Array Size : 976628736 (931.39 GiB 1000.07 GB)
Used Dev Size : 976630464 (931.39 GiB 1000.07 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Sun May 24 12:29:54 2020
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Consistency Policy : bitmap
Name : Bree:0 (local to host Bree)
UUID : ba979f01:7f1dbe79:24f19f68:7ba6000c
Events : 22436
Number Major Minor RaidDevice State
0 8 48 0 active sync /dev/sdd
1 8 64 1 active sync /dev/sde
# mount /dev/md127p1 /raid
# ls /raid
How is this possible? The only thing that touches the array is a borg
backup run from crontab, which I have verified is working correctly,
including just before the update and reboot this morning. It looks as
if the mount is mounting the wrong thing.
Or am I missing something very obvious?
poc
I would suggest that md is happy and the array is runnig (cat /proc/mdstat).
But I would check the logs to see if the 'mount' had anything to say.
--
Eyal at Home (fedora(a)eyal.emu.id.au)
10:42 a.m.
On Sun, 2020-05-24 at 23:40 +1000, fedora(a)eyal.emu.id.au wrote:
On 2020-05-24 21:37, Patrick O'Callaghan wrote:
> Still getting the hang of md. I had it working for several days (2
> disks in RAID1 config) but after a system update and reboot, it
A system update or a system upgrade?
Update. I was already on F32 when I started doing all this.
poc
11:37 a.m.
On 2020-05-24 13:37, Patrick O'Callaghan wrote:
sdd 8:48 0 931.5G 0 disk
└─md127 9:127 0 931.4G 0 raid1
└─md127p1 259:0 0 931.4G 0 part
sde 8:64 0 931.5G 0 disk
└─md127 9:127 0 931.4G 0 raid1
└─md127p1 259:0 0 931.4G 0 part
# mdadm --detail /dev/md127p1
/dev/md127p1:
Version : 1.2
Creation Time : Wed May 20 16:34:58 2020
Raid Level : raid1
Array Size : 976628736 (931.39 GiB 1000.07 GB)
Used Dev Size : 976630464 (931.39 GiB 1000.07 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
There is something strange here.
You have created md127 as a RAID1 of sdd and sde.
Then you have md127p1, so have you partitioned your RAID?
And then you are asking details for md127p1 (which could be your filesystem),
while your RAID is instead md127.
This is an unusual configuration.
Generally you partition the disks: sdd1 sde1, then create a RAID of of them: md127,
then you format and mount md127.
You may have messed up something: maybe you have formatted both md127 and md127p1?
Regards.
--
Roberto Ragusa mail at robertoragusa.it
12:19 p.m.
On Sun, 2020-05-24 at 18:37 +0200, Roberto Ragusa wrote:
On 2020-05-24 13:37, Patrick O'Callaghan wrote:
> sdd 8:48 0 931.5G 0 disk
> └─md127 9:127 0 931.4G 0 raid1
> └─md127p1 259:0 0 931.4G 0 part
> sde 8:64 0 931.5G 0 disk
> └─md127 9:127 0 931.4G 0 raid1
> └─md127p1 259:0 0 931.4G 0 part
>
> # mdadm --detail /dev/md127p1
> /dev/md127p1:
> Version : 1.2
> Creation Time : Wed May 20 16:34:58 2020
> Raid Level : raid1
> Array Size : 976628736 (931.39 GiB 1000.07 GB)
> Used Dev Size : 976630464 (931.39 GiB 1000.07 GB)
> Raid Devices : 2
> Total Devices : 2
> Persistence : Superblock is persistent
There is something strange here.
You have created md127 as a RAID1 of sdd and sde.
Then you have md127p1, so have you partitioned your RAID?
And then you are asking details for md127p1 (which could be your filesystem),
while your RAID is instead md127.
IIRC I created the RAID1 array (which took hours), then formatted the
resulting /dev/md127 (using gparted) as a single ext4 partition.
This is an unusual configuration.
Generally you partition the disks: sdd1 sde1, then create a RAID of of them: md127,
then you format and mount md127.
So clearly the other way around.
You may have messed up something: maybe you have formatted both md127
and md127p1?
I don't think so, but I guess it's possible. What I can't understand is
why everything appeared to be working before I rebooted.
I'm OK with doing it again if need be, but I don't find all this in any
way obvious.
poc
12:29 p.m.
Am 24.05.2020 um 19:19 schrieb Patrick O'Callaghan:
On Sun, 2020-05-24 at 18:37 +0200, Roberto Ragusa wrote:
> On 2020-05-24 13:37, Patrick O'Callaghan wrote:
>
>> sdd 8:48 0 931.5G 0 disk
>> └─md127 9:127 0 931.4G 0 raid1
>> └─md127p1 259:0 0 931.4G 0 part
>> sde 8:64 0 931.5G 0 disk
>> └─md127 9:127 0 931.4G 0 raid1
>> └─md127p1 259:0 0 931.4G 0 part
>>
>> # mdadm --detail /dev/md127p1
>> /dev/md127p1:
>> Version : 1.2
>> Creation Time : Wed May 20 16:34:58 2020
>> Raid Level : raid1
>> Array Size : 976628736 (931.39 GiB 1000.07 GB)
>> Used Dev Size : 976630464 (931.39 GiB 1000.07 GB)
>> Raid Devices : 2
>> Total Devices : 2
>> Persistence : Superblock is persistent
> There is something strange here.
> You have created md127 as a RAID1 of sdd and sde.
> Then you have md127p1, so have you partitioned your RAID?
> And then you are asking details for md127p1 (which could be your filesystem),
> while your RAID is instead md127.
IIRC I created the RAID1 array (which took hours), then formatted the
resulting /dev/md127 (using gparted) as a single ext4 partition.
> This is an unusual configuration.
> Generally you partition the disks: sdd1 sde1, then create a RAID of of them: md127,
> then you format and mount md127.
That's called partitioned RAID. Makes it easier if you need to replace
an array member.
So clearly the other way around.
> You may have messed up something: maybe you have formatted both md127 and md127p1?
I don't think so, but I guess it's possible. What I can't understand is
why everything appeared to be working before I rebooted.
Perfectly valid as a RAID setup. I am just not sure the anaconda
installer supports it. Last time I tried it (admitted with CentOS 7) I
couldn't do it that way.
I'm OK with doing it again if need be, but I don't find all
this in any
way obvious.
poc
Alexander
12:34 p.m.
On Sun, 2020-05-24 at 19:29 +0200, Alexander Dalloz wrote:
> > Generally you partition the disks: sdd1 sde1, then create a
RAID of of them: md127,
> > then you format and mount md127.
That's called partitioned RAID. Makes it easier if you need to replace
an array member.
> So clearly the other way around.
> > You may have messed up something: maybe you have formatted both md127 and
md127p1?
> I don't think so, but I guess it's possible. What I can't understand is
> why everything appeared to be working before I rebooted.
Just to repeat, in case it got lost in the thread, this is what shows
up in the journal:
May 24 18:12:31 Bree kernel: EXT4-fs (md127p1): mounted filesystem with ordered data mode.
Opts: (null)
May 24 18:12:31 Bree systemd[1]: raid.mount: Unit is bound to inactive unit
dev-md0p1.device. Stopping, too.
May 24 18:12:31 Bree systemd[1]: Unmounting /raid...
The part I don't get is:
"Unit is bound to inactive unit dev-md0p1.device"
poc
1:58 p.m.
You need to show fstab. Systemd owns raid and its entry is not working.
It will overrule you and unmount anything you put there since it thinks it
owns it.
On Sun, May 24, 2020, 12:36 PM Patrick O'Callaghan <pocallaghan(a)gmail.com>
wrote:
On Sun, 2020-05-24 at 19:29 +0200, Alexander Dalloz wrote:
> > > Generally you partition the disks: sdd1 sde1, then create a RAID of
of them: md127,
> > > then you format and mount md127.
>
>
> That's called partitioned RAID. Makes it easier if you need to replace
>
> an array member.
>
>
>
> > So clearly the other way around.
> > > You may have messed up something: maybe you have formatted both
md127 and md127p1?
> > I don't think so, but I guess it's possible. What I can't
understand is
> > why everything appeared to be working before I rebooted.
Just to repeat, in case it got lost in the thread, this is what shows
up in the journal:
May 24 18:12:31 Bree kernel: EXT4-fs (md127p1): mounted filesystem with
ordered data mode. Opts: (null)
May 24 18:12:31 Bree systemd[1]: raid.mount: Unit is bound to inactive
unit dev-md0p1.device. Stopping, too.
May 24 18:12:31 Bree systemd[1]: Unmounting /raid...
The part I don't get is:
"Unit is bound to inactive unit dev-md0p1.device"
poc
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
4:23 p.m.
On Sun, 2020-05-24 at 13:58 -0500, Roger Heflin wrote:
You need to show fstab. Systemd owns raid and its entry is not
working.
It will overrule you and unmount anything you put there since it thinks it
owns it.
I thought I'd quoted that somewhere. Anyway, here's the line:
/dev/md127p1 /raid ext4 defaults 0
0
poc
7:48 a.m.
I've never done full disk RAID1. Always, done it with partitions.
fdisk -l /dev/sda (and /dev/sdb) looks like this:
Disklabel type: gpt
Device Start End Sectors Size Type
/dev/sda1 2048 97722367 97720320 46.6G Linux RAID
/dev/sda2 97722368 99809279 2086912 1019M Linux RAID
/dev/sda3 99809280 101040127 1230848 601M Linux RAID
/dev/sda4 101040128 3907028991 3805988864 1.8T Linux RAID
mdadm:
# -l = level
# -n = raid-devices
# -e = metadata
# -b = bitmap
mdadm -C /dev/md127 --homehost=myserver.example.com -n 2 -l 1 -e 1.2 -b internal /dev/sda1
/dev/sdb1
cat /proc/mdstat:
Personalities : [raid1]
md127 : active raid1 sdb2[1] sda2[0]
1042432 blocks super 1.2 [2/2] [UU]
bitmap: 0/1 pages [0KB], 65536KB chunk
mdadm --detail /dev/md127:
UUID : e00525a0:a3a5bfc8:ebe4587b:8489d910
mdadm.conf (use the UUID from mdadm --detail):
ARRAY /dev/md/boot level=raid1 num-devices=2 UUID=e00525a0:a3a5bfc8:ebe4587b:8489d910
You don't need to wait for the sync to complete.
format the partition:
$ mkfs.xfs -L BOOT /dev/md127
# get uuid
$ xfs_admin -u /dev/md127
UUID = 9385d42a-d661-494c-ba1d-b3cad4420b77
# get label
$ xfs_admin -l /dev/md127
label = "BOOT"
fstab (use the UUID from xfs admin -u):
# device mount type options dump fsck
# point pgm order
#LABEL=BOOT /dev/md127
UUID=9385d42a-d661-494c-ba1d-b3cad4420b77 /boot xfs defaults 0
0
Instead of UUID, can use /dev/md127
df:
Filesystem Size Used Avail Use% Mounted on
/dev/md125 1.8T 279G 1.5T 16% /
/dev/md127 1013M 317M 696M 32% /boot
/dev/md21 931G 40G 892G 5% /ssd
/dev/md124 600M 8.5M 592M 2% /boot/efi
/dev/md32 9.1T 1.5T 7.6T 17% /lan
/dev/md42 9.1T 399G 8.7T 5% /bacula
Hope this helps,
Bill
On 5/24/2020 7:37 AM, Patrick O'Callaghan wrote:
Still getting the hang of md. I had it working for several days (2
disks in RAID1 config) but after a system update and reboot, it
suddenly shows no data:
]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
[...]
sdd 8:48 0 931.5G 0 disk
└─md127 9:127 0 931.4G 0 raid1
└─md127p1 259:0 0 931.4G 0 part
sde 8:64 0 931.5G 0 disk
└─md127 9:127 0 931.4G 0 raid1
└─md127p1 259:0 0 931.4G 0 part
# mdadm --detail /dev/md127p1
/dev/md127p1:
Version : 1.2
Creation Time : Wed May 20 16:34:58 2020
Raid Level : raid1
Array Size : 976628736 (931.39 GiB 1000.07 GB)
Used Dev Size : 976630464 (931.39 GiB 1000.07 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Sun May 24 12:29:54 2020
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Consistency Policy : bitmap
Name : Bree:0 (local to host Bree)
UUID : ba979f01:7f1dbe79:24f19f68:7ba6000c
Events : 22436
Number Major Minor RaidDevice State
0 8 48 0 active sync /dev/sdd
1 8 64 1 active sync /dev/sde
# mount /dev/md127p1 /raid
# ls /raid
How is this possible? The only thing that touches the array is a borg
backup run from crontab, which I have verified is working correctly,
including just before the update and reboot this morning. It looks as
if the mount is mounting the wrong thing.
Or am I missing something very obvious?
poc
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
1430
days inactive
1433
days old
44 comments
11 participants
participants (11)
-
Alexander Dalloz -
Bill Shirley -
Ed Greshko -
fedora＠eyal.emu.id.au -
Gabriel Ramirez -
Greg Woods -
Patrick O'Callaghan -
Roberto Ragusa -
Roger Heflin -
Samuel Sieb -
Tim