On 06/19/15 at 10:57am, Dave Young wrote:
On 06/19/15 at 10:50am, Minfei Huang wrote:
> On 06/19/15 at 10:17am, Dave Young wrote:
> > On 06/18/15 at 03:11pm, Minfei Huang wrote:
> > > On 06/18/15 at 02:54pm, Dave Young wrote:
> > > > On 06/18/15 at 01:50pm, Minfei Huang wrote:
> > > > > On 06/18/15 at 10:06am, Dave Young wrote:
> > > > > > On 06/15/15 at 04:33pm, Minfei Huang wrote:
> > > > > > > $ ls -l /dev/disk/by-uuid/
> > > > > > > lrwxrwxrwx. 1 root root 10 Jun 15 15:45
21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1
> > > > > > > lrwxrwxrwx. 1 root root 10 Jun 15 15:45
6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2
> > > > > > > lrwxrwxrwx. 1 root root 10 Jun 15 15:45
dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3
> > > > > > >
> > > > > > > In gereral, we can use device name to find the
filesystem UUID in
> > > > > > > /dev/disk. But it fails, if a filesystem is integrated
by seveal
> > > > > > > devices, like btrfs. Following is the structure of
btrfs.
> > > > > > >
> > > > > > > $ btrfs filesystem show /mnt/btrfs
> > > > > > > Label: none uuid:
b7ee07cd-6b28-43ec-aaed-af269bbcc0c9
> > > > > > > Total devices 3 FS bytes used 240.00KiB
> > > > > > > devid 1 size 1.00GiB used 232.25MiB path
/dev/mapper/testvg-lvtest01
> > > > > > > devid 2 size 1.00GiB used 92.88MiB path
/dev/mapper/testvg-lvtest02
> > > > > > > devid 3 size 500.00MiB used 220.25MiB path
/dev/mapper/testvg-lvtest03
> > > > > > >
> > > > > > > When we list the content of /dev/disk/by-uuid, we can
find
> > > > > > > /dev/dm-0[1] points to the corresponding UUID.
> > > > > > >
> > > > > > > $ ls -al /dev/disk/by-uuid/
> > > > > > > total 0
> > > > > > > lrwxrwxrwx. 1 root root 10 Jun 15 15:45
21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1
> > > > > > > lrwxrwxrwx. 1 root root 10 Jun 15 15:45
6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2
> > > > > > > lrwxrwxrwx. 1 root root 10 Jun 15 15:45
dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3
> > > > > > > lrwxrwxrwx. 1 root root 10 Jun 15 15:48
b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 -> ../../dm-0
> > > > > > >
> > > > > > > @@ -30,14 +30,14 @@ perror() {
> > > > > > > }
> > > > > > >
> > > > > > > get_persistent_dev() {
> > > > > > > - local i _tmp _dev
> > > > > > > + local i _tmp _dev _uuid
> > > > > > >
> > > > > > > _dev=$(udevadm info --query=name
--name="$1" 2>/dev/null)
> > > > > > > [ -z "$_dev" ] && {
> > > > > > > perror_exit "Kernel dev name of $1 is
not found."
> > > > > > > }
> > > > > > >
> > > > > > > - for i in /dev/mapper/* /dev/disk/by-uuid/*
/dev/disk/by-id/*; do
> > > > > > > + for i in /dev/mapper/* /dev/disk/by-id/*; do
> > > > > >
> > > > > > Minfei, in your test case, why it did not fall into
/dev/mapper/*?
> > > > >
> > > > > Hi, Dave.
> > > > >
> > > > > For the above testcase, the btrfs contains three devices,
/dev/dm-0,
> > > > > /dev/dm-1, /dev/dm-2. Kdump will fail to find the filesystem
UUID, once
> > > > > we pass the /dev/dm-1 or /dev/dm-2 to the function
get_persistent_dev,
> > > > > because the soft-link points to the /dev/dm-0.
> > > > >
> > > >
> > > > Is there any device mapper managed device name in directory
/dev/mappper/?
> > >
> > > In my testcase, there is only three devices which are managed by
device-mapper.
> > >
> > > [root@localhost ~]# ls -al /dev/mapper/
> > > total 0
> > > drwxr-xr-x. 2 root root 120 Jun 18 15:07 .
> > > drwxr-xr-x. 21 root root 3360 Jun 18 15:07 ..
> > > crw-------. 1 root root 10, 236 Jun 18 14:01 control
> > > lrwxrwxrwx. 1 root root 7 Jun 18 15:07 testvg-lvtest01 ->
../dm-0
> > > lrwxrwxrwx. 1 root root 7 Jun 18 15:07 testvg-lvtest02 ->
../dm-1
> > > lrwxrwxrwx. 1 root root 7 Jun 18 15:07 testvg-lvtest03 ->
../dm-2
> >
> > So what is the device in /proc/mounts, only one device like /dev/dm-0?
> >
>
> From my testing, I find that the device which show in /proc/mounts is
> always the smallest device name. For example:
>
> If there is three device to be integrated a filesystem, like /dev/vdb,
> /dev/vdc, /dev/vdd, /dev/vdb is always showed in /proc/mounts or df
> list. But I do not have enough testcases to confirm it.
>
> But the device is random in /dev/disk/by-uuid/*, if there is testcase
> like above. Maybe the UUID points to /dev/vdb for this time, but it
> changes after rebooting.
>
> > If this is the case, how does one mount the device manually, just use one
> > of them is ok? If it is right then we have no problem in our code?
> >
>
> Yes, we can use any one in the device set to mount the filesystem. like
> below.
>
> mount -t btrfs /dev/vdc /mnt/btrfs/
>
> But the device showed in /proc/mounts is /dev/vdb.
>
> > Do we need bring up the 3 dm devices in 2nd kernel?
>
> I think so, but I do not test this case via network, since the kernel
> will bring up all of the local device.
Why kdump fails during your test? Kdump kernel only bring up /dev/dm-0?
/dev/dm-1 and /dev/dm-2 are missing in your test?
Ok, I will paste the instance result to show you the problem.
The specified conf in 1st kernel:
[root@localhost tmp]# cat /etc/kdump.conf | grep -v ^#
path /mnt/btrfs/var/crash
core_collector makedumpfile -F -l --message-level 1 -d 31
default shell
force_rebuild 1
The conf generated by kdump.
[root@localhost tmp]# cat etc/kdump.conf
core_collector makedumpfile -F -l --message-level 1 -d 31
default shell
force_rebuild 1
btrfs
path /var/crash
You can find that the option btrfs misses the value in the kdump.conf
which is generated by kdump.
If the conf is correct, the value will be
"/dev/disk/by-uuid/e3d72630-fef0-4314-8f20-f4527783f375".
[root@localhost tmp]# cat etc/kdump.conf
core_collector makedumpfile -F -l --message-level 1 -d 31
default shell
force_rebuild 1
btrfs /dev/disk/by-uuid/e3d72630-fef0-4314-8f20-f4527783f375
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
path /var/crash
If they are all brought up in kdump kernel then what is the problem?
BTW, I think you should focus on one issue, maybe investigating on ipv6
first, these two issues can conflict in code...
Ok. I will hang on this patch, and continue once I have enough time.
Thanks
Minfei